Úzke miesta v databáze súborov – ako sa im vyhnúť (z nedávnych skúseností). Súborové spomalenia – ako sa vyhnúť (z nedávnych skúseností) Súborová verzia spomaľuje 1C 8.3 cez sieť

2. Vlastnosti programu. Často, dokonca aj pri optimálnom nastavení, 1C pracuje veľmi pomaly. Výkon klesá obzvlášť prudko, keď počet súčasne pracujúcich s databázou presiahne 4-5 používateľov.

Kto ste v spoločnosti?

Riešenie problému s pomalou prevádzkou 1C závisí od toho, kto ste v spoločnosti. Ak ste technik, čítajte ďalej. Ak ste riaditeľ alebo účtovník, kliknite na špeciálny odkaz ↓

Šírka pásma siete

S jednou informačnou bázou (IS) spravidla nepracuje jeden, ale viacero používateľov. Zároveň prebieha neustála výmena údajov medzi počítačom, na ktorom je nainštalovaný klient 1C, a počítačom, na ktorom sa nachádza informačná bezpečnosť. Objem týchto údajov je pomerne významný. Často nastáva situácia, keď lokálna sieť pracujúca rýchlosťou 100 Mbit/s, čo je najbežnejšia rýchlosť, jednoducho nezvláda záťaž. A opäť sa používateľ sťažuje na pomalý program.

Každý z týchto faktorov samostatne už výrazne znižuje rýchlosť programu, no najnepríjemnejšie je, že sa tieto veci zvyčajne sčítavajú.

Teraz sa pozrime na niekoľko riešení problému nízkej rýchlosti 1C a ich nákladov na príklade lokálnej siete 10 stredne veľkých počítačov.

Riešenie jedna. Modernizácia infraštruktúry

Toto je možno najzreteľnejšie riešenie. Vypočítajme si jeho minimálne náklady.

Minimálne pre každý počítač potrebujeme 2 GB RAM, čo stojí v priemere 1 500 rubľov, sieťová karta podporujúca rýchlosť 1 Gbit/s stojí asi 700 rubľov. Okrem toho budete potrebovať aspoň 1 smerovač, ktorý podporuje rýchlosť 1 Gbit/s, čo bude stáť približne 4 000 rubľov. Celkové náklady - 26 000 rubľov za vybavenie, s výnimkou práce.

V zásade sa rýchlosť môže výrazne zvýšiť, ale teraz už nie je možné kupovať lacné počítače do kancelárie. Toto riešenie navyše nie je použiteľné pre tých, ktorí využívajú Wi-Fi alebo chcú pracovať cez internet – v ich prípade môže byť rýchlosť siete aj desiatky krát nižšia. Vzniká myšlienka: „Nie je možné implementovať celý program na jednom výkonnom serveri, aby sa počítač používateľa nezúčastňoval zložitých výpočtov, ale slúžil iba na prenos obrazu? Potom môžete pracovať aj na veľmi slabých počítačoch, dokonca aj na sieťach s nízkou šírkou pásma. Prirodzene, takéto riešenia existujú.

Riešenie dva. Terminálový server

Veľkú popularitu si získal už v dňoch 1C 7. Je implementovaný na serverovej verzii Windows a dobre zvláda našu úlohu. Má to však svoje úskalia, a to náklady na licencie.

Samotný operačný systém bude stáť asi 40 000 rubľov. Okrem toho budeme pre každého, kto plánuje pracovať v 1C, potrebovať licenciu Windows Server CAL, ktorá stojí asi 1 700 rubľov, a licenciu CAL na služby Windows Remote Desktop Services, ktorá stojí asi 5 900 rubľov.

Po vypočítaní nákladov na sieť 10 počítačov skončíme so 116 000 rubľov. len na jednu licenciu. Pridajte k tomu náklady na samotný server (najmenej 40 000 rubľov) a náklady na implementačné práce, ale aj bez toho sa cena za licencie ukázala ako pôsobivá.

Riešenie tri. Služba 1C Enterprise

1C vyvinula vlastné riešenie tohto problému, ktoré môže výrazne zvýšiť rýchlosť programu. Ale je tu aj nuansa.

Faktom je, že náklady na takéto riešenie sa pohybujú od 50 000 do 80 000 rubľov v závislosti od vydania. Pre spoločnosť do 15 používateľov sa to ukazuje ako dosť drahé. Veľké nádeje sa vkladali do „podnikového miniservera 1C“, ktorý je podľa spoločnosti 1C zameraný na malé podniky a stojí okolo 10 000 - 15 000 rubľov.

Keď sa však dostal do predaja, tento produkt bol veľkým sklamaním. Faktom je, že maximálny počet používateľov, s ktorými bolo možné miniserver používať, bol iba 5.

Ako napísal jeden programátor 1C na fóre: „Stále nie je jasné, prečo si 1C vybral práve 5 spojení! Problémy začínajú len so 4 používateľmi, ale s piatimi to všetko končí. Ak chcete pripojiť šiestu osobu, zaplaťte ďalších 50 tisíc. Mohli by sme urobiť aspoň 10 spojení...“

Samozrejme, aj miniserver si našiel svojho konzumenta. Pre firmy, kde s 1C pracuje 5 a viac ľudí, sa však jednoduché a lacné riešenie neobjavilo.

Okrem vyššie popísaných metód zrýchlenia programu existuje ešte jedna, ktorá je ideálna pre segment 5 - 15 používateľov, a to webový prístup pre 1C v režime súborov.

Riešenie štyri. Webový prístup pre 1C v režime súborov

Princíp fungovania je nasledovný: na počítači je nainštalovaná ďalšia rola webového servera, na ktorom je zverejnená informačná bezpečnosť.

Prirodzene by to mal byť buď najvýkonnejší počítač v sieti, alebo samostatný stroj určený na túto úlohu. Potom môžete pracovať s 1C v režime webového servera. Všetky náročné operácie budú vykonávané na strane servera a prevádzka prenášaná cez sieť bude minimalizovaná, rovnako ako zaťaženie klientskeho počítača.

Preto aj veľmi slabé stroje môžu byť použité na prácu v 1C a šírka pásma siete nie je kritická. Naše testy ukázali, že cez mobilný internet môžete pohodlne pracovať aj na lacnom tablete bez nepohodlia.

Táto možnosť je z hľadiska prevádzkovej rýchlosti nižšia ako podnikový server 1C, ale tento rozdiel je prakticky neviditeľný až pre 15 až 20 používateľov. Mimochodom, na implementáciu webového servera môžete použiť IIS (pre Windows) a Apache (pre Linux) a obe tieto riešenia sú zadarmo!

Napriek zjavným výhodám si tento spôsob optimalizácie prevádzky 1C nezískal veľkú popularitu.

Nemôžem to povedať s istotou, ale s najväčšou pravdepodobnosťou je to spôsobené dvoma dôvodmi:

• Dosť slabý popis v technickej dokumentácii
• Nachádza sa na križovatke zodpovednosti správcu systému a programátora 1C

Zvyčajne, keď sa správca systému obráti na problém s nízkou rýchlosťou, navrhne inováciu infraštruktúry alebo terminálového servera; ak je kontaktovaný špecialista 1C, ponúkne sa mu podnikový server 1C. Ak teda vo vašej spoločnosti „ruka v ruke“ pracujú špecialista zodpovedný za infraštruktúru a špecialista zodpovedný za 1C, môžete bezpečne používať riešenie založené na webovom serveri.

Zrýchlime 1C. Na diaľku, rýchlo a bez vašej účasti

Vieme, ako zrýchliť 1Ski bez toho, aby sme rušili zákazníka. Ponoríme sa do problému, urobíme svoju prácu a odchádzame. Ak chcete, aby program fungoval normálne, kontaktujte nás. Prídeme na to.

Zanechajte žiadosť a získajte bezplatnú konzultáciu o urýchlení programu.

Optimalizácia 1C a rýchlosť práce v mnohých ohľadoch závisia od práce so zámkami, dotazmi a indexmi. Pokúsime sa odpovedať na otázku „ako urýchliť prácu 1C“ (otázku, ako urýchliť spustenie 1C, zvážime v inom článku) a vyhnúť sa sťažnostiam používateľov na „dlhé spracovanie dokumentov“, ktoré nevyhnutne ovplyvňuje obchodné procesy.

Časť 3. Výkon 1C

Zámky v 1C 8.3: vyhľadávanie a eliminácia v kóde, prenos do spravovaných zámkov

Zámky sú súčasťou mechanizmu ACID. Pozrime sa na jeho koncept, prezentovaný vo forme zjednodušeného diagramu, na príklade SQL SERVER

V automatickom režime sú zámky riadené samotným DBMS. Súčasne sa na serveri MS SQL objavili vedľajšie efekty, ako napríklad zamykanie prázdnych tabuliek a rozsahov hraničných údajov (úroveň serializácie), čo spôsobilo ďalšie problémy pri práci viacerých používateľov. Na vyriešenie týchto problémov spoločnosť 1C vytvorila riadené zámky.

1C ovládané zámky

Uzamykací mechanizmus bol presunutý na server 1C a na úrovni DBMS bola izolácia znížená na minimum. Na MS SQL bola úroveň izolácie znížená na Read Committed so zdieľaným uzamykacím mechanizmom na platforme 8.2 a mechanizmom na správu verzií na platforme 8.3 (tzv. Read Committed Snapshot Isolation). Presnejšie, ide o rovnomennú vlastnosť databázy a dva prevádzkové režimy Read Committed, ktoré závisia od tohto parametra.

Na poslednej úrovni izolácie (RCSI) mechanizmus umožnil nepretínať transakcie čítania a zápisu na rovnakých zdrojoch na serveri DBMS. Všetku hlavnú prácu prevzala blokovacia služba 1C, ktorá na základe natívnych metadát určuje, či povoliť alebo nepovoliť transakcie na server DBMS, aby nedošlo k narušeniu obchodnej logiky. Problémy so zamykaním prázdnych tabuliek a rozsahov hraníc sú minulosťou.

DBMS	Typ zámku	Úroveň izolácie transakcií	Čítať mimo transakcie
Automatické zámky
Databáza súborov	Tabuľky	Serializovateľné	Špinavé čítanie
MS SQL Server	Príspevky		Špinavé čítanie
IBM DB2	Príspevky	Opakovateľné čítanie alebo serializovateľné	Špinavé čítanie
PostgreSQL	Tabuľky	Serializovateľné	Dôsledné čítanie
Oracle Database	Tabuľky	Serializovateľné	Dôsledné čítanie
Riadené zámky
Databáza súborov	Tabuľky	Serializovateľné	Špinavé čítanie
MS SQL Server 2000	Príspevky	Prečítajte si Odovzdané	Špinavé čítanie
MS SQL Server 2005 a vyšší		Prečítajte si Committed Snapshot	Dôsledné čítanie
IBM DB2 pred verziou 9.7	Príspevky	Prečítajte si Odovzdané	Špinavé čítanie
IBM DB2 verzia 9.7 a vyššia	Príspevky	Prečítajte si Odovzdané	Dôsledné čítanie
PostgreSQL	Príspevky	Prečítajte si Odovzdané	Dôsledné čítanie
Oracle Database	Príspevky	Prečítajte si Odovzdané	Dôsledné čítanie

Ak chcete zistiť, v akom režime uzamknutia je databáza programu 1C, musíte v kontexte požadovanej databázy spustiť nasledujúcu požiadavku od SSMS:

1C zámky. Používateľ nebude čakať na zámky, 1C sa zrýchli, ak budete dodržiavať určité pravidlá:

• Trvanie transakcií by sa malo čo najviac skrátiť. Vykonanie zdĺhavých výpočtov v transakcii v 100% prípadov povedie k zablokovaniu pri práci na systéme OLTP.
• Odpadajú dlhé externé operácie v rámci transakcie, napríklad odosielanie a prijímanie potvrdení e-mailom, práca so súborovým systémom a ďalšie dodatočné akcie. Všetky operácie musia byť umiestnené v odložených krátkych úlohách.
• Dopyty sú optimalizované na maximum.
• Indexy by sa mali vytvárať len podľa potreby, aby sa zabezpečil optimálny výkon dotazov v rámci aplikácie.
• Zahrnutie často aktualizovaných stĺpcov v klastrovanom indexe bolo minimalizované. Aktualizácie stĺpca/stĺpcov kľúča klastrovaného indexu vyžadujú uzamknutie klastrovaného indexu aj všetkých indexov bez klastrov (pretože ich riadok lokátora obsahuje kľúč klastrovaného indexu).
• Tam, kde je to možné, sa vytvorí krycí index a použije sa na skrátenie času získavania údajov.
• Použitie najnižšej úrovne izolácie transakcií, ktorá si bude vyžadovať prepnutie do režimu riadeného uzamykania.

Nástroje na diagnostiku blokád:

• Technologický časopis;
• Centrum riadenia výkonu z nástrojov 1C;
• cloudové služby Gilev;

Nižšie je uvedený príklad monitorovania systému pomocou služby Gilev. Celková doba blokovania je ~15 hodín. Viac ako 400 aktívnych používateľov. Po vykonaní rozhodnutí a optimalizácii sú časové limity kratšie ako minúta a počet blokovaní sa znížil ~ 670-krát.

bol:

Sa stal:

V situácii, keď „všetko visí a trvá to dlho“ a monitorovacie služby nie sú nakonfigurované alebo sa vôbec nepoužívajú, musíte si pamätať na Paretov princíp, musíte sa zamerať na kód.

V automatickom režime je možné prítomnosť zámkov na serveri zistiť pomocou systémovej procedúry v kontexte požadovanej databázy. Táto uložená procedúra vám umožňuje určiť, v akom režime zámky fungujú, ich stav, typ atď.:

Po dokončení postupu pre 1C môžete získať vizuálne informácie o tom, čo sa momentálne deje na serveri, berúc do úvahy špecifiká tabuliek 1C:

Fragment 1

//Zamknutie v zmysle 1C SELECT * FROM dbo.ReturnLockName1C(DEFAULT,DEFAULT) as t Kde TableName1C NIE JE NULL ORDER BY t.Resource

Použitie tohto mechanizmu umožňuje získať úplné informácie o aktuálnych zámkoch. Ak zostava obsahuje iba S-zámky, problémom môže byť dlhotrvajúci dopyt alebo dotazy. Ak chcete zistiť príčinu a miesto ich výskytu v kóde, môžete použiť rôzne cesty: použiť objekty DMO servera SQL (ale nezabudnite, že údaje z nich sa po reštarte servera resetujú) alebo konfigurujte zberač údajov, ukladanie monitorovacích údajov do tabuliek na určitý čas. Hlavná vec je získať texty problematických žiadostí.

Použitie SQL Server DMO Objects

Zobrazujeme dátum spustenia servera, aby sme pochopili relevantnosť údajov. Balíček sme rozdelili podľa hodnotenia čítania (fyzické, logické, zaťaženie procesora). V tomto prípade sa použijú kmeňové dáta zo sys.dm_exec_query_stats. Text požiadavky preložíme do výrazov 1C. Ak z textu požiadavky pochopíte kontext hovoru, potom už zostáva len pozrieť sa na plán požiadavky, nájsť problematických operátorov a pochopiť, čo sa dá robiť.

Fragment 2

//čas spustenia SELECT sqlserver_start_time FROM sys.dm_os_sys_info; //Najčastejšie požiadavky na fyzické čítanie SELECT TOP (50) (total_physical_reads) AS Total_physical_reading,

Identifikácia problematických dopytov v dôsledku zberu údajov pomocou zberača údajov

Pomocou tohto nástroja môžete zoradiť údaje podľa potrebných parametrov, ako je zaťaženie procesora, trvanie, logické I/O, operácie fyzického čítania, čo vám umožňuje uložiť kompletnú štatistiku pre ďalšiu analýzu aj napriek reštartu SQL servera.

Po zhromaždení problematických požiadaviek serverom bez monitorovania treťou stranou môžete prijaté údaje zoradiť podľa potrebných parametrov.

Ďalej zapnutím technologického denníka a uvedením v nastaveniach „hľadať podľa reťazca“ a časti požiadavky, na ktorú sa zaručene stretne, môžete zistiť, odkiaľ bola problematická požiadavka volaná. Ak má server niekoľko databáz alebo je známe meno používateľa, oplatí sa pridať ďalšie polia pre filter, aby sa znížilo zaťaženie servera pri zhromažďovaní protokolu procesov.

Príklad problematickej požiadavky a príklad založenia technologického denníka:

Optimalizácia dotazu ako príležitosť na zrýchlenie 1C 8.3

Dôsledky neoptimálnych dopytov sa môžu prejaviť v podobe zdĺhavého spracovania dokumentov, bolestne dlhého generovania reportov, zamrznutia systému a iných nepríjemných udalostí.

Pri práci so žiadosťami NEMÔŽETE:

• Spojiť tabuľky s poddotazmi;
• Spojte bežné stoly s virtuálnymi;
• Použite logické "ALEBO" v podmienkach;
• Použite poddotazy v podmienkach spojenia;
• Prijímajte údaje cez bodku z polí zloženého typu bez kľúčového slova „Express“.

Pri práci so žiadosťami MÔŽETE:

• Vytvárajte indexy pre podmienky dotazu, pole spájania, agregácie a triedenia;
• Filtrovanie virtuálnych tabuliek musí byť vykonané pomocou parametrov výberu.

Používanie indexov a ich vplyv na kvalitu výkonu systému

O indexoch, potrebe ich používania a vplyve na kvalitu fungovania systému sa toho popísalo veľa. Pokúsme sa pochopiť zložitosť „dizajnu“ indexov, aplikačných možností a výhod oproti bežným tabuľkám.

Indexovanie je dôležitou súčasťou jadra DBMS. Chýbajúce indexy, alebo naopak ich nadmerný počet, ovplyvňujú rýchlosť vyhľadávania, úpravy, pridávania a odstraňovania údajov. Pozrime sa na indexovanie na príklade najbežnejšieho Microsoft DBMS.

Pre všeobecné pochopenie toho, ako to funguje, sa pozrime na detaily mechanizmu ukladania údajov, ktorý zvyčajne predstavujeme vo forme tabuľky (napríklad Excel).

Jednotkou fyzického úložiska dát je stránka – 8 KB modul, ktorý patrí len jednému objektu (napríklad tabuľke alebo indexu). Strana je najmenšia jednotka na čítanie a písanie. Stránky sa zhromažďujú do rozsahov. Rozsah pozostáva z 8 po sebe nasledujúcich strán. Stránky rozsahu môžu patriť jednému alebo viacerým objektom. Keď stránky patria viacerým objektom, rozsah sa nazýva „zmiešaný“.

Jeho obsah si môžete pozrieť nižšie:

Teraz, keď máme predstavu o tom, ako funguje disková jednotka, povedzme si viac o tabuľkách a indexoch.

V predvolenom nastavení, ak nepoužívate špeciálne príkazy T-SQL, prázdna tabuľka sa vytvorí ako "hromada" - jednoduchý súbor stránok a rozsahov.Údaje v halde nemajú žiadne logické usporiadanie. Motor SQL Server sleduje vlastníctvo stránky a rozsahu konkrétneho objektu pomocou špeciálnych systémových stránok nazývaných Index Allocation Maps. Každá tabuľka alebo index má aspoň jednu stránku IAM, ktorá sa nazýva „prvá stránka IAM“.

Po vytvorení bežnej tabuľky je teda štandardne výsledkom chaotické usporiadanie údajov. Stav tabuľky môžete zobraziť pomocou nasledujúceho postupu:

Hlavné indexy používané platformou 1C

Fragment 3

Mýty a realita:

Mýtus prvý: klastrované indexy a dátová tabuľka sú dve rôzne entity, uložené oddelene od seba.

Mýtus druhý: v jednej tabuľke môže byť veľa zoskupených indexov.

Stiahol som si program na optimalizáciu DBMS. Vytvorené odporúčané indexy. Rýchlosť odberu vzoriek sa zvýšila o 50 %. Zmena a pridávanie údajov sa spomalilo 7-krát.

Clustered (clustered) index

Klastrované indexy sú množinou stránok, ktoré triedia a ukladajú riadky údajov v tabuľkách alebo zobrazeniach na základe ich kľúčových hodnôt – stĺpcov zahrnutých v definícii indexu. Tento typ indexu má obmedzenie na 16 stĺpcov a 900 bajtov. Pre každý stôl existuje len jeden zhlukovaný index, pretože dátové riadky možno triediť iba v jednom poradí. Vytvorenie klastrovaného indexu prebieha reorganizáciou tabuľky, a nie kopírovaním údajov, čo umožňuje, aby bola tabuľka uložená ako vyvážený strom.

Fragment 4

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID("Trace Data")

Nezhlukovaný index

Neklastrované indexy majú štruktúru oddelenú od údajových riadkov. Neklastrovaný index obsahuje hodnoty klastrovaného indexového kľúča a každý záznam obsahuje klastrovaný indexový kľúč (nie RID, pretože tabuľky 1C až na zriedkavé výnimky nepoužívajú haldy).

Nekľúčové stĺpce môžete pridať na úroveň listu neklastrovaného indexu a obísť existujúci limit indexového kľúča (900 bajtov a 16 kľúčových stĺpcov) spustením plne indexovaných dotazov.

Po pridaní indexu bez klastrov sa údaje skopírovali a objavil sa ďalší objekt:

Fragment 5

SELECT NAME, TYPE, TYPE_DESC FROM sys.indexes WHERE object_id = OBJECT_ID("Trace Data")

Schéma zoskupeného indexu po jeho získaní z haldy vo forme vyváženého stromu:

Schéma neklastrovaného indexu odvodeného z klastrovanej tabuľky (všimnite si, že stĺpec lokátora riadkov má klastrovaný indexový kľúč):

Vplyv indexov na výkon dotazov

Pomocou indexu optimalizátor dotazov prehľadá kľúčové stĺpce v indexe, nájde miesto, kde sú uložené riadky dotazu, a odtiaľ získa zodpovedajúce riadky. Vyhľadávanie v indexe je oveľa rýchlejšie ako vyhľadávanie v tabuľke, pretože na rozdiel od tabuľky index často obsahuje menej stĺpcov na riadok a riadky sú zoradené v poradí.

Vytváranie viacerých indexov vedie k tomu, že rýchlosť vzorkovania sa zvyšuje a rýchlosť zápisu počas modifikácie sa výrazne znižuje. Ak chcete tento problém vyriešiť, musíte najskôr odstrániť nepotrebné indexy alebo ich najskôr uzamknúť bez toho, aby ste ich odstránili, čo vám v prípade potreby umožní jednoducho ich povoliť.

Upozorňujeme, že klastrovaný index nemožno za žiadnych okolností zablokovať, pretože tým sa zablokuje prístup k údajom tabuľky. Týka sa to iba indexov, ktoré ste si sami vytvorili prostredníctvom T-SQL. Dôvod vytvárania indexov pomocou T-SQL, ktorý obchádza 1C:Enterprise, je spojený predovšetkým s obmedzenými možnosťami platformy 1C, pokiaľ ide o manipuláciu s indexmi a zahrnutie ďalších polí do vytvoreného indexu.

Príkaz T-SQL, ktorý vykonáva akciu uzamknutia indexu:

//Zamknutie samostatného indexu v tabuľke -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 DISABLE; //Zahrňte požadovaný index -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 REBUILD;

Okrem vyššie uvedených krokov je dôležité vytvoriť skupinu súborov na fyzickom disku, ktorý nebude obsahovať aktuálne databázové súbory, a presunúť tam indexy bez klastrov. Zrýchli sa tak úprava údajov paralelizáciou ich záznamu.

Určenie, ktoré indexy sú potrebné alebo nepotrebné na urýchlenie dopytov

Štandardne 1C vytvára určitú základnú sadu indexov. Často ich jednoducho nie je dosť. SQL Server má mechanizmy, ktoré vám umožňujú na základe vášho pracovného zaťaženia pochopiť, aké potrebné sú vaše existujúce indexy.

Poradca pre ladenie databázového stroja analyzuje databázy a poskytuje odporúčania na optimalizáciu výkonu dotazov. Môže sa použiť na výber a vytvorenie optimálnych sád indexov bez toho, aby ste mali odbornú úroveň pochopenia návrhu databázy alebo interných procesov servera SQL Server. Nástroj Database Engine Configuration Assistant vám umožňuje vykonávať nasledujúce úlohy:

• Riešenie problémov s výkonom konkrétneho problematického dotazu;
• Nakonfigurujte veľkú množinu dotazov v jednej alebo viacerých databázach.

DMO (dynamic management objects), ktoré zahŕňajú dynamické manažérske pohľady a dynamické riadiace funkcie. Napríklad príkaz T-SQL môže získať všetky indexy, ktoré neboli použité od posledného spustenia servera.

Fragment 6

WITH vl as (SELECT OBJECT_NAME(I.object_id) AS objectname, I.name AS indexname, I.index_id AS indexid FROM sys.indexes AS I INNER JOIN sys.objects AS O ON O.object_id = I.object_id WHERE I.object_id > 100 AND I.type_desc = "NEZAHRNUTÉ" A I.index_id NIE JE VSTUP (SELECT S.index_id FROM sys.dm_db_index_usage_stats AS S WHERE S.object_id=I.object_id AND I.index_id=S.index_id AND database_id = DB_ID("database_name '))) SELECT objectname,T1.NameTable1C, indexid, indexname FROM vl OUTER APPLY dbo.ReturnTableName1C(objectname) as T1 ORDER BY objectname, indexname;

Pokyny, ktoré možno použiť na vytvorenie potrebných indexov odporúčaných jadrom DBMS:

Fragment 7

SELECT T1.NameTable1C ako Table_Name_1C, "CREATE INDEX" + "ON"
Optimalizátor dotazov pri generovaní plánu vykonávania dotazov identifikuje potrebu vytvorenia chýbajúceho indexu. Tieto informácie ukladá do XML ShowPlan. Pretože plány dotazov sú hashované a inštrukcie sú uložené (až do nasledujúceho reštartu servera), potom môžu byť získané, spracované a pripravené inštrukcie na vytvorenie potrebných indexov pre akýkoľvek plán vykonávania v cache. Je potrebné venovať pozornosť frekvencii vykonávania dotazu: čím je vyššia, tým relevantnejšie sú výsledky dotazu a podľa toho aj zhromaždené ukazovatele. Ak bol dotaz vykonaný raz, jeho výsledky nie sú také orientačné.

Fragment 8

CROSS APPLY query_plan.nodes('//StmtSimple") AS stmt(stmt_xml) WHERE stmt_xml.exist("QueryPlan/Missinglndexes") = 1) VYBERTE TOP 30 DatabaseName ako Database_Name, TableName ako Table_Name, T1C_CoMelumCTablee ako T1C_ComelumC ns ako Comparison_columns, include_columns ako Columns_to_include,

Fragment 9

POUŽÍVAJTE [Database_name] VYTVORTE NEZAHRNUTÝ INDEX NA .[_Document497] ([_Fld12771_TYPE],[_Fld12771_RTRef]) INCLUDE ([_Date_Time],[_Fld12771_RRRef],[72RRFld]GO17,[72RRFld]127 Niektoré funkcie indexovania podľa súhrnných polí a triediacich polí.

Vytvorenie indexu v stĺpcoch špecifikovaných v klauzule ORDER BY pomáha optimalizátoru dotazov rýchlo usporiadať množinu výsledkov, pretože hodnoty stĺpcov sú v indexe zoradené vopred. Interná implementácia mechanizmu GROUP BY tiež najskôr triedi hodnoty stĺpcov, aby rýchlo zoskupila požadované údaje.

Pri použití štandardných odporúčaní sa oplatí skontrolovať výsledok pred a po optimalizácii. Uveďme príklad použitia logického spojenia „OR“ a jeho alternatívu (na vyriešenie problému pomocou štandardných odporúčaní) - techniku ​​​​zmeny dotazu pomocou syntaxe „UNITE ALL“.

Samotná požiadavka 1C s „ALEBO“:

VYBERTE kód, názov, prepojenie z adresára. Protistrany AKO Protistrany WHERE Protistrany. Kód = "000000004" ALEBO Protistrany. Kód = "0074853" ALEBO Protistrany. Kód = "000000024" ALEBO Protistrany. Kód = "0000024" ALEBO Protistrany = "000024" ALEBO Protistrany. 0074742" ALEBO Protistrany.Kód = "000000104";

Úprava dotazu pomocou „UNITE ALL“:

SELECT Code, Name, Link FROM Directory. Protistrany AKO protistrany WHERE Protistrany. Code = "000000004" COMBINE ALL SELECT Code, Name, Link FROM Directory. Protistrany AKO protistrany WHERE Protistrany. Code = "0074853" COMBINE ALL SELECT Code, Name Z Adresára. Protistrany AKO Protistrany WHERE Protistrany. Kód = "000000024" KOMBINOVAŤ VŠETKY VYBERTE kód, názov, prepojenie z adresára. Protistrany AKO protistrany WHERE

Aktuálny plán dopytov (pre jednoduché zobrazenie a porovnanie výkonu, dopyty zachytené a spustené v SSMS):

V tomto prípade po optimalizácii klesol výkon na polovicu z dôvodu opakovaného použitia operátora Key Lookup, ktorý je vždy sprevádzaný operátorom Nested Loops. Preto by ste pri používaní schémy optimalizácie dotazov mali merať cieľový čas pred a po použití vylepšení. Tento príklad je uvedený na účely „dôveruj, ale preveruj“, pretože medzi typickými odporúčaniami a praktickými problémami môže byť nesúlad.

Ako zrýchliť prácu v 1C: Účtovníctvo 8.3 (edícia 3.0) alebo zakázať rutinné úlohy a úlohy na pozadí

2019-01-15T13:28:19+00:00

Tí z vás, ktorí už prešli na nové vydanie 1C: Accounting 8.3 (edícia 3.0), si všimli, že je pomalšie ako 2. Nejaké zvláštne spomalenia, nekonečné úlohy na pozadí niekoľkokrát denne, o ktorých vykonanie ju bez nášho vedomia nikto nežiadal.

Moji účtovníci mi hneď po prechode povedali, že nové vydanie 1C: Accounting 3.0 je v porovnaní s predchádzajúcimi úplne pomalé! A je jednoducho nemožné pracovať.

Začal som sa tým zaoberať a veľmi skoro som zistil, že hlavnou príčinou zamrznutia a následnej nespokojnosti používateľov sú rutinné úlohy a úlohy na pozadí, z ktorých mnohé sú štandardne povolené, hoci pre drvivú väčšinu účtovníkov nie sú potrebné.

Prečo napríklad potrebujeme spúšťať úlohu „Extrahovanie textu“ stokrát denne, ak nevykonávame fulltextové (účtovníci, neľakajte sa) vo všetkých objektoch v našej databáze.

Alebo prečo neustále sťahovať menové kurzy, ak nemáme menové transakcie alebo ich robíme príležitostne (a predtým môžeme sami kliknúť na tlačidlo sťahovania kurzov).

To isté platí pre neustály pokus spoločnosti 1C pripojiť sa na stránku a kontrolovať a aktualizovať bankové klasifikátory. Prečo? Ja sám stlačím tlačidlo na aktualizáciu klasifikátorov, ak nenájdem správnu banku podľa jej BIC.

Ako to urobiť krok za krokom nižšie.

1. Prejdite do časti „Správa“ a na paneli akcií vyberte „Údržba“ ():

2. V okne, ktoré sa otvorí, nájdite a vyberte „Rutinné úlohy a úlohy na pozadí“:

3. Otvorte každú úlohu, ktorá má v stĺpci „Zapnuté“ hodnotu „Zapnuté“. je tam daw.

4. Zrušte začiarknutie políčka „Povolené“ a kliknite na tlačidlo „Uložiť a zatvoriť“.

5. Urobte to s každou zo zahrnutých úloh a užite si nové vydanie. Celkovo je to podľa mňa oveľa lepšie ako dvojka.

Platforma zároveň povolí niektoré z naplánovaných úloh, ktoré ste zakázali.

Systém 1C je dnes jedným z hlavných nástrojov na riadenie malých a stredných podnikov. Prístup k programu majú spravidla všetci zamestnanci organizácie. Ak teda 1C začne spomaľovať alebo pracovať pomaly, výrazne to ovplyvňuje podnikanie. Pozrime sa, ako si môžete urýchliť a optimalizovať prácu v 1C sami.

Optimalizácia pomocou aktualizácie 1C

Nové verzie 1C vždy fungujú úspešnejšie a rýchlejšie, takže je nevyhnutné sledovať aktualizácie. Odporúča sa aktualizovať svoje účtovné záznamy čo najčastejšie. Najmä vtedy, keď sú uvoľnené verzie regulovaného výkazníctva.

Mnoho ľudí už dlho využíva možnosť automatickej aktualizácie programu. Aj keď sa tento problém dá ľahko vyriešiť manuálne pre 1C Enterprise 8.3, aktualizácia nespôsobí žiadne problémy.

Prvým krokom je stiahnutie najnovšej verzie platformy, ktorú práve používate. A to buď pomocou ITS disku, alebo cez webové rozhranie, kde poskytujú nepretržitú podporu používateľom programu ako 1c Enterprise 8.3, ktorého aktualizácia konfigurácie je poskytovaná aj oficiálne.

V druhom prípade sa archív s aktualizačnými údajmi stiahne samostatne. Je rozbalený v ľubovoľnom priečinku, ktorý sa považuje za najvhodnejší pre používateľa. Potom musíte spustiť súbor .exe. V ďalšom okne stačí kliknúť na tlačidlo „Ďalej“.

Zobrazí sa ďalšia stránka. Na ňom používateľ vyberie cestu, v ktorej sa inštalácia dokončí. Tento krok sa však odporúča iba pokročilým vlastníkom osobných počítačov. Predvolené funkcie zvyčajne postačujú na vyriešenie väčšiny problémov. Štandardne je v tomto prípade určený jeden priečinok, kde sú nainštalované všetky aktualizácie naraz. Je to oveľa pohodlnejšie, ako keď sú konečné cesty iné. Jednoducho niekoľkokrát klikneme na tlačidlá „Ďalej“ v programe 1c Enterprise 8.3, ktorého konfigurácia by sa mala rýchlo aktualizovať.

Zostáva len posledné tlačidlo, ktoré ponúka „Inštalovať“.

Ako zrýchliť 1C, ak je platforma pomalá

Problémy najčastejšie vyplývajú zo skutočnosti, že v jednej z fáz klesá koncentrácia pozornosti interpreta. Tu je dôležité zvoliť správnu schému aktualizácie, len v tomto prípade nenarazíme na problém, keď pri aktualizácii zamrzne 1c.

Aktualizácia verzie 7.7

Existuje niekoľko typov konfigurácie. V závislosti od toho sa zvolí priebeh ďalších akcií.

• Štandardné – v tomto prípade sa predpokladá, že aktualizácia sa vykonáva aj pre regulované výkazníctvo.
• Typické priemyselné konfigurácie do značnej miery pripomínajú predchádzajúce možnosti. Je dôležité, aby ste si vopred prečítali pokyny poskytnuté vývojárom. V opačnom prípade nebudete môcť zistiť, prečo 1C 8.3 počas aktualizácie zlyhá.
• Upravený štandard – používateľ má vždy možnosť sám upraviť aplikáciu tak, aby vyhovovala aktuálnym potrebám. Ďalšou možnosťou rozšírenia funkcionality je prechod na nové platformy. Napríklad verzia 8.

O verzii 8.0 a 8.1

V súčasnosti sa už platforma 8.0 sťahuje z podpory. Nový štandardný vývoj bude fungovať iba pri použití najnovších verzií. Musíte si len pamätať, že všetky prechodné vydania sú dokončené bez zlyhania. V opačnom prípade existuje vysoká pravdepodobnosť straty informácií. Alebo narazíte na situáciu, keď 1c zamrzne pri aktualizácii konfigurácie.

Možnosť je možná, keď sa implementuje nová štandardná konfigurácia a potom sa do nej prenesú zvyšky zo starých informačných databáz.

Pokiaľ ide o verziu 8.1, môžete ju aktualizovať niekoľkými spôsobmi:

1. ručne;
2. v automatickom režime;
3. kontaktovanie špecialistov zo spoločností poskytujúcich služby v tejto oblasti.

Práca s neštandardnými alebo upravenými verziami

Na začiatku sa akákoľvek konfigurácia vzťahuje na štandardný vývoj. Prestáva ním byť, ak sa v podniku vykonajú určité zmeny. Napríklad počas inštalácie. Medzi neštandardnými konfiguráciami vynikajú dve triedy:

1. zmenené;
2. vytvorené od nuly, berúc do úvahy potreby konkrétneho podniku.

Niekedy je medzi používateľmi aktívne distribuovaná konfigurácia druhej triedy. Potom sa to považuje za typické. Ide len o to, že výrobca sa nepovažuje za samotný 1C, ale za spoločnosť, ktorá vytvorila novú verziu.

Konfigurácie je možné aktualizovať pomocou nasledujúcich akcií:

• Oprava chyby.
• Rozšírenie funkčnosti.
• Zlepšenie.
• Zmena v 1C 8.3, konfigurácia sa neaktualizuje v prípade chýb údržby.

Proces inštalácie môže trvať rôzny čas v závislosti od rýchlosti internetu, pri ktorej ho práve používate. V samostatnom okne si používateľ vyberie, či sa má aktualizovať po dokončení práce alebo ihneď. Pri poslednej možnosti sa musíte uistiť, že s aplikáciou nepracuje nikto iný. Samotný proces zahŕňa použitie exkluzívneho režimu v rámci aplikácie 1c Enterprise 8.3, posledná aktualizácia nie je výnimkou.

• Musíme si uvedomiť, že nie všetky verzie vydania môžu byť vhodné pre aktuálnu konfiguráciu.
• Ak sa aktualizácie nevykonávali dlhší čas, možno budete musieť stiahnuť niekoľko súborov alebo archívov naraz.
• V zozname je ľahké pochopiť, ktorá verzia 1C Enterprise 8.3 je potrebná, aktualizáciu vyberie používateľ.

Po dokončení procesu je možné zatvoriť samotný konfigurátor. Tento režim sa najčastejšie používa, ak je potrebná aktualizácia. Je to pohodlné a automatizuje takmer celý proces. Pri prvom spustení sa môže zobraziť hlásenie, že platforma je zastaraná. A že sa to v súčasnosti neodporúča používať.

Ďalšie dôvody brzdenia

Ak je program aktualizovaný správne a bez chýb, 1C sa však stále spomaľuje, dôvod môže byť nasledujúci:

• Antivírus - ak je správne nakonfigurovaný, žiadny antivírus nebude zasahovať do systému, ak však použijete výrobné nastavenia, výkon 1C sa môže znížiť o 5–10%. Váš antivírus môžete optimalizovať pomocou dodatočných nastavení odstránením režimu na pozadí (ak je to absolútne nevyhnutné).
• Parametre počítača – často nedostatočne výkonné počítače vedú k výraznému poklesu výkonu 1C. Osobitná pozornosť sa musí venovať grafickej karte, operačnému systému a procesoru.

Takéto metódy výrazne optimalizujú a zrýchlia prácu v 1C pre akúkoľvek spoločnosť alebo podnik, po čom sa výkon programu výrazne zvýši.

Ako zvýšiť rýchlosť a jednoduchosť používania v 1C

Symptómy a anamnéza pacienta:

Práca viacerých používateľov v sieti s rovnakým súborom (databázou) zahŕňa mechanizmus blokovania siete. To núti systém strácať drahocenný čas identifikáciou otvorených relácií nahrávania a zodpovedajúcim riešením konfliktov.

Hlavné znaky blokovania:

• rýchla užívateľská práca s databázou cez sieť v exkluzívnom režime a extrémne pomalá, keď pracuje viacero užívateľov súčasne
• rýchla používateľská skúsenosť s lokálnou databázou na serveri a pomalá práca cez sieť
• prístupy k súborovému systému sú tesne pod 10 MB/s

Dostal som teda za úlohu zabezpečiť, aby v 1C mohli súčasne pracovať až traja používatelia! Smiešne, nie?

Zabudol som na všetky vtipy, keď som videl, s čím som sa musel potýkať: „server“ v podobe obyčajného kancelárskeho počítača a dvoch notebookov.

Šťastie by bolo neúplné, nebyť úžasných operačných systémov – Windows 7 na počítači a na jednom notebooku, Windows 8 na druhom.

Pri pokuse o súčasné odosielanie dokumentov na prenosných počítačoch sa jeden zasekol asi na minútu a druhý sa zrútil z 1C s chybovým textom „nepodarilo sa zamknúť stôl...“.

Spustenie 1C na notebooku je samostatná show, ktorá trvala cca 3 minúty!

Na mnohých zdrojoch som narazil na radu, ako prejsť na prácu v terminálovom prístupe. Bohužiaľ, Windows 7 vám neumožňuje zmeniť sa na terminálový server pomocou štandardných nástrojov - existuje maximálne jedno aktívne pripojenie. V tomto prípade sa zostávajúce relácie neukončia; môžete sa znova pripojiť pod iným používateľom - „vyhodiť“ predchádzajúceho používateľa, ale bez ukončenia jeho relácie. Preto by ste mali preniesť 1C na serverový OS, kde neexistujú žiadne takéto obmedzenia. Klient na vlastné riziko vyriešil problém pomocou nástroja tretej strany Windows7_SP1_RDPhack.

Tým sa však dobrodružstvá neskončili. Aj v koncovom spoji dochádzalo k výrazným meškaniam. Opäť mi pomohli všemocné vyhľadávače. Nižšie sú uvedené tipy na zrýchlenie súboru 1C, ktoré som postupoval:

1. Zakázať použitie sieťového protokolu IPv6, nakonfigurujte adresovanie na „starej“ IPv4.

2. Pridajte procesy 1C k výnimkám brány firewall systému Windows, ako aj k výnimkám antivírusu, alebo ich úplne zakážte (rizikovejšie, ale jednoduchý test ukázal zvýšenie rýchlosti opätovný prenos dokumentov, keď je antivírus Avast vypnutý faktor!)

3. Začnite indexovať fulltextové vyhľadávanie v 1C alebo ho úplne vypnite

4. Spustite testovanie a opravu databázy pomocou pomôcky ChDbfl

5. V konfigurácii spustite položku Check Configuration (ak konfigurácia nie je štandardná, môže to byť užitočné). Na základe výsledkov kontroly konfigurácie sa magicky zmenšil takmer o tretinu. V skutočnosti som sa neponoril do toho, čo presne aktualizovali prichádzajúci programátori predo mnou, ale skutočnosť je zrejmá.

6. Vypnite nepotrebné funkčné možnosti.

7. Nastavte používateľské práva. (Táto aj predchádzajúca rada sa mi zdali hlúpe, kým som nepozoroval vykresľovanie spravovaných formulárov pri otváraní zoznamu dokumentov. Čím menej zbytočné v spravovanom rozhraní, tým to spravidla funguje rýchlejšie)

8. Začnite prepočítavať súčty a obnovovať postupnosť (výrazný nárast môže nastať len vtedy, ak súčty neboli dlho obnovené)

9. V nastaveniach zoznamu databáz zadajte "Rýchlosť pripojenia - nízka" (neprinieslo to veľa výsledkov, okrem toho, že obrazy podsystémov boli vypnuté :))

Po dokončení všetkých týchto krokov začala databáza súborov 1C pracovať oveľa rýchlejšie. Začal sa spúšťať maximálne za 10 sekúnd a rýchlosť prenosu dokumentov sa zvýšila v priemere 12-krát.

Možno vám tento krátky článok bude užitočný, ak zrazu potrebujete zrýchliť databázu súborov 1C.

P.S: Ale spustenie súboru 1C pomocou sieťového prístupu k zdieľanému priečinku je stále nereálne, pretože... Aj ten najrýchlejší SSD, RAM a procesor sa dostanú do zablokovania siete a práca viac ako jedného používateľa bude prakticky nemožná. Hovoríme konkrétne o konfigurácii UT 11.1. Vlastnoručne napísané malé konfigurácie môžu fungovať pomerne rýchlo aj vo verzii súboru.

Dodatky z komentárov na zverejnenie:

Defragmentácia disku so základňou súboru

Konvolúcia databáza (môže byť užitočná, ak je databáza veľká, napríklad niekoľko rokov). Databáza klienta bola pomerne mladá, takže redukcia bola nepraktická.

Aktualizácia hardvéru - rýchlejší pevný disk, nový prepínač, procesor atď.

Nainštalujte na webový server, prístup pomocou tenkého klienta. Tu sú názory rozdelené. Niektorí hovoria, že je to mnohokrát rýchlejšie, iní hovoria, že nie je zaznamenané žiadne zrýchlenie.