Výběr 1c se po několika operacích zablokuje. Co dělat, když program zamrzne? Rozdíl mezi nezbytnými a nepotřebnými zámky

Důvodů, proč program zamrzne, může být několik:

Tento článek pojednává o hlavních faktorech: když 1C zpomalí, 1C zamrzne a 1C pracuje pomalu. Data byla připravena na základě dlouholetých zkušeností společnosti SoftPoint s optimalizací velkých IT systémů postavených na kombinaci 1C + MS SQL.

Pro začátek stojí za zmínku mýtus, že 1C není určeno pro současnou práci velkého počtu uživatelů, aktivně podporovaných uživateli fóra, kteří v těchto příspěvcích nacházejí ujištění a důvod nechat vše tak, jak to je. S dostatkem trpělivosti a znalostí můžete systém přiblížit libovolnému počtu uživatelů. Pomalý provoz a zamrzání 1C již nebude problém.

Z praxe: Nejjednodušší způsob optimalizace je 1C v7.7 (optimalizace 1C 8.1, 1C 8.2, 1C 8.3 je složitější úkol, protože se aplikace skládá ze 3 odkazů). Přivedení až 400 současných uživatelů je poměrně typický projekt. Do 1500 je již obtížné a vyžaduje tvrdou práci.

Druhý mýtus: Chcete-li zlepšit výkon 1C a zbavit se zamrznutí 1C, musíte nainstalovat výkonnější server. Zpravidla je u optimalizačních projektů v 95 % případů možné dosáhnout přijatelného výkonu buď zcela bez upgradu, nebo aktualizací menší části zařízení, například přidáním RAM. Je třeba poznamenat, že zařízení musí být stále založené na serveru, zejména diskový subsystém. Zastaralý diskový subsystém je jen jedním z důvodů, proč 1C funguje pomalu.

Hlavním omezením při práci s více uživateli v 1C je uzamykací mechanismus. Je to blokování v 1C, a ne serverové vybavení, co obvykle brání velkému počtu lidí pracovat v databázi. Chcete-li tento problém překonat, musíte tvrdě pracovat a změnit logiku zamykání v 1C - snížit je z tabulkových na řádkové. Pak například zaúčtováním dokladu zablokujete pouze jeden a ne všechny doklady v systému.

Obrázek 1. Blokovací fronta 1C v monitorovacím systému PerfExpert s informacemi o uživatelích 1C, konfiguračním modulu a specifickým řádkem kódu v tomto modulu.

Změna uzamykacího mechanismu 1C je velmi složitá technologie. Ne každý takový trik dokáže a pro něj zbývá jediná cesta – optimalizace struktury a zrychlení doby provádění operací. Faktem je, že blokování v 1C a doba provádění operací jsou vysoce vzájemně propojené ukazatele. Pokud například operace zaúčtování dokladu trvá 15 sekund, pak při velkém počtu uživatelů je vysoká pravděpodobnost, že se během přenosu někdo jiný pokusí doklad zaúčtovat a bude čekat v blokování. Pokud prodloužíte dobu provádění alespoň na 1 sekundu, blokování 1C pro tuto operaci se výrazně sníží.

Nebezpečnější z hlediska blokování jsou skupinové zpracování, které může trvat dlouho a zároveň způsobit 1C blokaci. Jakékoli zpracování, které mění data, například obnovení posloupnosti nebo dávkového zpracování dokumentů, uzamkne tabulky a zabrání ostatním uživatelům zaúčtovat dokumenty. Přirozeně, čím rychleji jsou tato zpracování provedena, tím kratší je doba blokování a tím to bude pro uživatele jednodušší.

Těžké sestavy, které provádějí operace pouze pro čtení, mohou být také nebezpečné z hlediska zamykání, i když by se zdálo, že data nezamykají. Takové zprávy ovlivňují intenzitu blokování v 1C a zpomalují další operace v systému. To znamená, že pokud je sestava velmi obtížná a zabírá většinu prostředků serveru, může se ukázat, že před spuštěním sestavy byly stejné operace prováděny po dobu 1 sekundy a během provádění sestavy byly prováděny po dobu 15 sekund. . S rostoucí dobou provádění operací se přirozeně zvyšuje i intenzita blokování.

Obrázek 2. Načtení funkčního serveru z hlediska konfiguračních modulů od všech uživatelů. Každý modul má svou vlastní barvu. Existuje jasná nerovnováha v zátěži vytvořené z 1C.

Základním pravidlem pro optimalizaci je, že zpracování dokumentů by mělo zabrat minimum času a provádět pouze nezbytné operace. Například výpočty registru se často používají při zpracování účtování bez zadání podmínek filtrování. V tomto případě musíte pro registry určit filtry, které vám umožní získat nejlepší selektivitu, aniž byste zapomněli, že podle podmínek filtrování musí mít registr příslušné indexy.

Kromě spouštění těžkých reportů může neoptimální nastavení MS SQL a MS Windows zpomalit dobu provádění operací a tím zvýšit intenzitu blokování 1C. Tento problém se vyskytuje u 95 % klientů. Je třeba poznamenat, že se jedná o servery seriózních organizací, na jejich podpoře a konfiguraci se podílejí celá oddělení vysoce kvalifikovaných správců.

Hlavním důvodem nesprávné konfigurace serveru je strach administrátorů cokoliv změnit na běžícím serveru a pravidlo „Nejlepší je nepřítel dobrého“. Pokud správce změní nastavení serveru a začnou problémy, všechen hněv úřadů se vylije na neopatrného správce. Proto je pro něj výhodnější nechat vše tak, jak je, a neudělat jediný krok bez příkazu od nadřízených, než experimentovat na vlastní odpovědnost.

Druhým důvodem je nedostatek jasných informací o problémech s optimalizací sítě. Existuje spousta názorů, které si často zcela protiřečí. Každý názor věnovaný optimalizaci má své odpůrce a fanatiky, kteří ho budou hájit. Výsledkem je, že internet a fóra spíše zamění nastavení serveru, než že pomohou. V situaci takové nejistoty má administrátor ještě menší chuť cokoliv měnit na serveru, který nějak funguje.

Na první pohled je obrázek jasný - musíte optimalizovat vše, co zpomaluje provoz serveru 1C. Představme si ale sebe na místě takového optimalizátoru – řekněme, že máme 1C 8.1 8.2 8.3 UPP a současně pracuje 50 uživatelů. Jednoho strašného dne si uživatelé začnou stěžovat, že 1C je pomalé, a musíme tento problém vyřešit.

Nejprve se podíváme na to, co se děje na serveru – co když nějaký zvlášť nezávislý antivirus provádí úplnou kontrolu systému. Kontrola ukazuje, že je vše v pořádku – server je zatížen na 100 %, a to pouze procesem sqlservr.

Z praxe: jeden z mladších administrátorů z vlastní iniciativy zapnul na serveru automatickou aktualizaci, Windows a SQL se vesele aktualizovaly a po aktualizaci začalo masivní zpomalení práce uživatelů 1C, nebo 1C prostě zamrzlo.

Dalším krokem je kontrola, které programy načítají MS SQL. Kontrola ukazuje, že zátěž je generována přibližně 20 připojeními aplikačního serveru.

Z praxe: program, který promptně aktualizuje data na webu, se dostal do smyčky a místo aktualizace jednou za 4 hodiny to dělal nepřetržitě, bez přestávek, silně zatěžoval server a blokoval data.

Další analýza situace naráží na velké potíže. Již jsme zjistili, že zátěž pochází přímo z 1C, ale jak můžeme pochopit, co přesně uživatelé dělají? Nebo alespoň kdo jsou. Je dobré, když je v organizaci 10 uživatelů 1C, pak je můžete projít a zjistit, co teď dělají, ale v našem případě je jich padesát a jsou rozptýleni po několika budovách.

V příkladu, který zvažujeme, není situace ještě složitá. Představte si, že zpomalení nebylo dnes, ale včera. Dnes se situace neopakuje, vše je v pořádku, ale musíte přijít na to, proč včera operátoři nemohli pracovat (stěžovali si samozřejmě až před odjezdem z domova, protože rádi celý den chatují, protože nic nefunguje víc než práce ) . Tento případ zdůrazňuje potřebu serverového logovacího systému, který bude vždy uchovávat historii hlavních parametrů provozu serveru a ze kterého lze obnovit sled událostí.

Logovací systém je prostě nepostradatelný nástroj při optimalizaci systému. Pokud k tomu přidáte možnost online zobrazení aktuálního stavu, získáte systém sledování stavu serveru. Každý projekt optimalizace začíná shromažďováním statistik o stavu serveru k identifikaci úzkých míst.

Když jsme začali pracovat v oblasti optimalizace, vyzkoušeli jsme mnoho serverových monitorovacích systémů, bohužel se nám nepodařilo najít něco, co by tento problém vyřešilo na patřičné úrovni, a tak jsme si museli systém vytvořit sami. Výsledkem byl unikátní produkt PerfExpert, který umožnil automatizovat a zefektivnit procesy optimalizace IT systémů. Program se vyznačuje těsnou integrací s 1C, absencí jakékoli znatelné dodatečné zátěže a opakovaně prokázanou vhodností pro praktické použití v bojových situacích.

Vrátíme-li se k našemu příkladu, nejpravděpodobnější výsledek je: Administrátor říká: "Na vině jsou programátoři, kteří napsali konfiguraci." Programátoři odpověděli: "Všechno je pro nás napsáno dobře - je to server, který nefunguje." A vozík, jak se říká, tam pořád je. V důsledku toho se 1C zpomaluje, zamrzá nebo pracuje pomalu.

V každém případě pro vyřešení problémů s výkonem 1C doporučujeme nejprve zakoupit a používat sledování výkonu PerfExpert , umožní vám to činit správná manažerská rozhodnutí a ušetřit peníze. Produkt je vhodný jak pro malé informační systémy 1C:Enterprise - do 50 uživatelů, tak pro systémy - od 1000 uživatelů. Od července 2015 sledování výkonu PerfExpert obdržel certifikát 1C: Compatible, prošel testováním v Microsoft a pomáhá řešit problémy s výkonem nejen pro systémy 1C, ale i pro další informační systémy založené na MS SQL Server (Axapta, CRM Dynamics, Doc Vision a další).

Pokud se vám informace líbily, doporučujeme další kroky:

- Pokud chcete samostatně řešit technické problémy výkonu 1C (1C 7.7, 1C 8.1, 1C 8.2,1C 8.3) a další informační systémy, pak je tu pro vás unikátní seznam technických článků v našem Almanachu (Blokování a uváznutí, velká zátěž CPU a disků, údržba databáze a ladění indexů jsou jen malou částí technických materiálů, které tam najdete).
.
- Pokud byste chtěli prodiskutovat problémy s výkonem s naším odborníkem nebo si objednat řešení monitorování výkonu PerfExpert, poté zanechte požadavek a my vás budeme co nejdříve kontaktovat.

Pokud některý program přestal reagovat, nereaguje ani na myš, ani na klávesnici a možná se dokonce objeví hláška „program neodpovídá“, tomu se říká zamrzlý program.

Někdy se stane, že vám zamrzlý program nepřekáží v práci, ale někdy se naopak kvůli jednomu zamrzlému programu může zpomalit práce celého OS, v každém případě je třeba problém vyřešit, něco se musí Hotovo.

Co nedělat:

1) Vytáhněte zástrčku ze zásuvky- to je největší chyba, kterou můžete v této situaci udělat. Náhlý výpadek proudu je pro váš počítač velmi stresující. Tato položka také zahrnuje vypnutí počítače pomocí tlačítka start na systémové jednotce a jeho vypnutí stisknutím vypínače napájení. Podstata těchto metod je stejná, zastavíte dodávku elektřiny.

2) Stiskněte tlačítko reset– toto tlačítko se nachází na přední straně systémové jednotky a slouží k vynucení restartu. Mělo by se stlačovat pouze v těch nejbeznadějnějších situacích, kdy jiné metody nepomáhají.

3) Dělejte zbytečné pohyby– pokud se váš operační systém začal zpomalovat kvůli zamrzlému programu, pak jakákoli zbytečná akce situaci jen zhorší. Zbytečnými akcemi mám na mysli pokusy o restartování zamrzlého programu (toto v žádném případě neprovádějte), spouštění dalších programů, otevírání nabídky start nebo jiné nabídky. Pokud je situace obzvláště kritická, neměli byste jen pohybovat myší, protože kurzor může zamrznout a bude obtížnější problém vyřešit.

4) Počkejte velmi dlouho– zpravidla stačí počkat pět minut, abyste pochopili, že program zamrzl, pokud máte slabý počítač, dejte mu 15–20 minut.

5) Buďte nervózní– kopnutí do systémové jednotky nebo bouchnutí klávesnice o stůl věci nepomůže. Tento bod jsem konkrétně napsal, protože to lidé z neznámých důvodů občas dělají (asi kvůli naší minulosti, kdy nechtěla fungovat trubková televize, většinou do ní udeřili rukou a pomohlo to). Počítač není trubková televize, takže do něj nebijte.

Co je třeba udělat

Musíte zkusit zavřít program, pokud nepomůže kliknutí na křížek v pravém horním rohu a kombinace alt + f4, musíte provést následující:

Stisknutím kombinace kláves otevřete správce úloh:

Pro Windows xp „Ctrl + Alt + Del“.

Pro Windows 7 "Ctrl + Shift + Esc".

Ve správci úloh přejděte na kartu „Aplikace“, pokud je váš program zobrazen v části úloh, vyberte jej a klikněte na tlačítko „Ukončit úlohu“. Pokud okamžitě nereaguje, nemusíte toto tlačítko znovu mačkat, stačí chvíli počkat. Po chvíli se zobrazí okno s upozorněním, že data mohou být ztracena, budete muset kliknout na tlačítko „Dokončit nyní“. Příklad viz snímek obrazovky (dokončil jsem pracovní program, takže váš text bude jiný, ale princip je stejný).

Pokud nemůžete program ukončit tímto způsobem, klikněte pravým tlačítkem myši na zmrazený program a z rozbalovací nabídky vyberte „Přejít na proces“. Automaticky se dostanete na kartu „Procesy“, požadovaný proces již bude zvýrazněn, stačí kliknout na tlačítko „Ukončit proces“.

Pokud se zmrazený program na kartě „Aplikace“ nezobrazuje, musíte přejít na kartu „Procesy“, najít proces zmrazeného programu a ukončit jej. Nejjednodušší způsob, jak hledat proces, je podle názvu, můžete také hledat podle stupně zatížení procesoru, obvykle je toto procento velké.

1) podívejte se na množství paměti přidělené rphostem na serveru 1C. Pokud máte x32 verzi serveru, může proces využívat maximálně 1,75 GB RAM
Pokud není dostatek paměti, server nemůže přijímat nová připojení nebo přestane reagovat, když aktuální relace vyžaduje další paměť
www.viva64.com/ru/k/0036
2) Podívejte se na nastavení „Nastavení pracovního serveru“ nastavení může být nesprávné. Měl jsem tento problém a server neustále zamrzal. Moje nastavení jsou připojena. Serveru je přiděleno 11 GB.
3) Mohou nastat problémy s nastavením Postgressql.

Poskytněte vlastnosti vašeho serveru, velikosti databáze, konfigurace Postgressql. Bez informací těžko říct.

Moje konfigurace PostgreSQL: https://drive.google.com/file/d/0B2qGCc-vzEVDMERVW...
Tato konfigurace je vybrána pro dostupné množství paměti RAM.
PostgreSQL nainstalovaný na Linuxu, 3 GB RAM, 3 CPU jádra.
Server 1C8: 11 GB RAM, 5 CPU jader
4 databáze, každá přibližně 1 GB (nahráno do dt)

Poskytněte všechny vlastnosti vašeho serveru: 1C8 server a databáze, fyzický nebo virtuální, operační systém, množství RAM na každém serveru, jaký typ CPU, kolik RAM zabírají rphost procesy, kolik jich je? Používáte pole RAID?

Dříve jsem sám PostgreSQL používal, ale během procesu jsem narazil na problémy při provozování databáze na PostgreSQL a nedávno jsem přešel na MS SQL.

Váš server není pro tyto databáze špatný. Abyste mohli PostgreSQL používat, musíte velmi dobře rozumět jeho konfiguraci. Když jsou databáze malé, mnoho konfiguračních chyb je odpuštěno. Když jsme teprve začínali implementovat 1C + PostgreSQL, měli jsme také velmi časté problémy s provozem databáze (docházelo k častému zamrzání, fungovala pomalu). PostgreSQL se lépe používá na Linuxu, ne na Windows. Já sám nejsem databázový specialista na nastavení databázového serveru, najali jsme si specialistu z 1Sbit a ten nám to nastavil a pak už nebyly s provozem žádné problémy.

Rada:
Máte velké databáze, nešetřete, najměte si databázového specialistu, který vám to nastaví. Jeden člověk nemůže být odborníkem na všechno.

1) jak dlouho jste zkontrolovali samotnou databázi a přeindexovali ji? VAKUUM a REINDEX
2) před jak dlouhou dobou jste testovali a opravovali databázi pomocí nástrojů 1C?
3) je soubor protokolu databáze umístěn na samostatném pevném disku?
4) Je HDD hodně zatížený?

Zvažte přechod na MS Sql, který často nevyžaduje „prakticky“ žádnou konfiguraci a je jednodušší. Na rozdíl od PostgreSQL je MS Sql připraven k práci ihned po vybalení, ale PostgreSQL je třeba nakonfigurovat.

Pokud máte nějaké dotazy, pište, třeba vám pomůžu s něčím na Skype: tisartisar

Najměte si specialistu na nastavení databáze

Proč jsme přešli na MS SQL:
Používáme konfiguraci UT a při uzavírání měsíce se občas vyskytly chyby, které nebylo možné vyřešit. Pokud jste převedli databázi do souborového režimu a začali uzavírat měsíc, pak se vše uzavřelo normálně, stejná databáze byla načtena na PostgreSQL server při výpočtu nákladů, došlo k chybám. Tehdy jsme byli v závěrečných měsících kvůli plovoucím chybám o půl roku pozadu. Vytvořili jsme testovací databázi na MS SQL a měsíc, který nešlo uzavřít na PostgreSQL na MS SQL, byl uzavřen. Na PostgreSQL také nefunguje správně zaokrouhlování cen v ceníku. Ve skutečnosti je podporováno spuštění 1C na PostgreSQL, ale stále se doporučuje používat MS SQL.
Z tohoto důvodu bylo rozhodnuto přejít na MS SQL, protože... stabilita provozu 1C je dražší.

Jsem rád, že jsem mohl pomoci, prosím, kontaktujte mě, pokud máte nějaké dotazy nebo problémy.

1) kolik paměti je přiděleno serveru MS SQL? toto se konfiguruje v samotném MS SQL serveru.
2) Pravidelně testujte databázi pomocí 1C
3) článek o tom, jak nastavit zálohování a údržbu. To je důležité a je třeba to dělat pravidelně. Dělám to každý den. Podívejte se na všechny 3 části průvodce.

V poslední době si uživatelé a správci stále častěji začínají stěžovat, že nové konfigurace 1C vyvinuté na základě spravované aplikace fungují pomalu, v některých případech až nepřijatelně pomalu. Je jasné, že nové konfigurace obsahují nové funkce a schopnosti, a proto jsou náročnější na zdroje, ale většina uživatelů nechápe, co primárně ovlivňuje provoz 1C v režimu souborů. Pokusme se tuto mezeru napravit.

V tom našem jsme se již dotkli vlivu výkonu diskového subsystému na rychlost 1C, ale tato studie se týkala lokálního použití aplikace na samostatném PC nebo terminálovém serveru. Většina malých implementací přitom zahrnuje práci se souborovou databází po síti, kde se jako server používá jedno z PC uživatele, nebo dedikovaný souborový server založený na běžném, nejčastěji také levném počítači.

Malá studie zdrojů v ruském jazyce na 1C ukázala, že se tomuto problému pečlivě vyhýbáme, pokud nastanou problémy, obvykle se doporučuje přepnout do režimu klient-server nebo terminál. Také se stalo téměř obecně akceptováno, že konfigurace na spravované aplikaci fungují mnohem pomaleji než obvykle. Argumenty jsou zpravidla „železné“: „Účetnictví 2.0 právě letělo a „trojka“ se sotva pohnula V těchto slovech je samozřejmě něco pravdy, takže to zkusme přijít na kloub.

Spotřeba zdrojů, první pohled

Před zahájením této studie jsme si stanovili dva cíle: zjistit, zda jsou konfigurace založené na spravovaných aplikacích ve skutečnosti pomalejší než konvenční konfigurace, a které konkrétní prostředky mají primární dopad na výkon.

Pro testování jsme vzali dva virtuální stroje se systémem Windows Server 2012 R2 a Windows 8.1, v tomto pořadí, a dali jsme jim 2 jádra hostitelského Core i5-4670 a 2 GB RAM, což odpovídá přibližně průměrnému kancelářskému stroji. Server byl umístěn na poli RAID 0 po dvou a klient byl umístěn na podobném poli univerzálních disků.

Jako experimentální základnu jsme vybrali několik konfigurací verze Accounting 2.0 2.0.64.12 , který byl poté aktualizován na 3.0.38.52 , byly všechny konfigurace spuštěny na platformě 8.3.5.1443 .

První věc, která přitahuje pozornost, je zvětšená velikost informační základny Trojky, která se výrazně rozrostla, a také mnohem větší chuť k RAM:

Jsme připraveni slyšet obvyklé: „proč to přidali k těm třem“, ale nespěchejme. Na rozdíl od uživatelů verzí klient-server, které vyžadují více či méně kvalifikovaného správce, uživatelé verzí souborů jen zřídka myslí na údržbu databází. Také zaměstnanci specializovaných firem, které tyto databáze obsluhují (čti aktualizují), na to jen zřídka myslí.

Mezitím je informační základna 1C plnohodnotným DBMS vlastního formátu, který také vyžaduje údržbu, a k tomu dokonce existuje nástroj tzv. Testování a opravy informační báze. Možná ten název hrál krutý vtip, z čehož jaksi vyplývá, že se jedná o nástroj pro řešení problémů, ale problémem je také nízký výkon a restrukturalizace a reindexace spolu s kompresí tabulek jsou dobře známé nástroje pro optimalizaci databází pro každého správce DBMS. . Zkontrolujeme?

Po aplikaci vybraných akcí databáze prudce „zhubla“, stala se ještě menší než „dvojka“, kterou nikdo nikdy neoptimalizoval, a mírně se snížila i spotřeba RAM.

Následně po načtení nových klasifikátorů a adresářů, vytvoření indexů atp. velikost základny se obecně zvětší, „tři“ základny jsou větší než „dvě“ základny. To však není důležitější, pokud se druhá verze spokojila se 150-200 MB RAM, pak nová edice potřebuje půl gigabajtu a s touto hodnotou je třeba počítat při plánování potřebných prostředků pro práci s programem.

Síť

Šířka pásma sítě je jedním z nejdůležitějších parametrů pro síťové aplikace, zejména jako 1C v režimu souborů, které přesouvají značné množství dat po síti. Většina sítí malých podniků je postavena na základě levného 100 Mbit/s zařízení, proto jsme začali testovat porovnáním ukazatelů výkonu 1C v sítích 100 Mbit/s a 1 Gbit/s.

Co se stane, když spustíte databázi souborů 1C přes síť? Klient stahuje poměrně velké množství informací do dočasných složek, zejména pokud se jedná o první „studený“ start. Při rychlosti 100 Mbit/s se očekává, že naběhneme proti šířce kanálu a stahování může trvat značnou dobu, v našem případě asi 40 sekund (náklady na rozdělení grafu jsou 4 sekundy).

Druhé spuštění je rychlejší, protože některá data jsou uložena v mezipaměti a zůstávají tam až do restartu. Přechod na gigabitovou síť může výrazně urychlit načítání programů, „studených“ i „horkých“, přičemž je respektován poměr hodnot. Proto jsme se rozhodli vyjádřit výsledek v relativních hodnotách, přičemž největší hodnotu každého měření jsme považovali za 100 %:

Jak můžete vidět z grafů, Accounting 2.0 se načítá při jakékoli rychlosti sítě dvakrát rychleji, přechod ze 100 Mbit/s na 1 Gbit/s umožňuje čtyřnásobně zrychlit dobu stahování. V tomto režimu není žádný rozdíl mezi optimalizovanými a neoptimalizovanými databázemi „trojky“.

Ověřili jsme také vliv rychlosti sítě na provoz v těžkých režimech, například při skupinových přenosech. Výsledek je také vyjádřen v relativních hodnotách:

Zde je to zajímavější, optimalizovaný základ „trojky“ v síti 100 Mbit/s pracuje stejnou rychlostí jako „dvojka“ a neoptimalizovaný vykazuje dvakrát horší výsledky. Na gigabitu zůstávají poměry stejné, neoptimalizovaná „trojka“ je také o polovinu pomalejší než „dvojka“ a optimalizovaná zaostává o třetinu. Přechod na 1 Gbit/s také umožňuje zkrátit dobu provádění třikrát u edice 2.0 a o polovinu u edice 3.0.

Abychom vyhodnotili dopad rychlosti sítě na každodenní práci, použili jsme Měření výkonu, provádějící sekvenci předem určených akcí v každé databázi.

Ve skutečnosti pro každodenní úkoly není propustnost sítě překážkou, neoptimalizovaná „trojka“ je pouze o 20 % pomalejší než „dvojka“ a po optimalizaci se ukazuje, že je přibližně stejně rychlejší – výhody práce v režimu tenkého klienta jsou evidentní. Přechod na 1 Gbit/s nedává optimalizovanému základu žádné výhody a neoptimalizovaný a oba začnou pracovat rychleji a vykazují mezi sebou malý rozdíl.

Z provedených testů je zřejmé, že síť není pro nové konfigurace úzkým hrdlem a spravovaná aplikace běží ještě rychleji než obvykle. Přechod na 1 Gbit/s můžete doporučit i v případě, že jsou pro vás kritické náročné úlohy a rychlost načítání databáze, v ostatních případech vám nové konfigurace umožní efektivně pracovat i v pomalých 100 Mbit/s sítích.

Proč je tedy 1C pomalé? Podíváme se na to dále.

Serverový diskový subsystém a SSD

V předchozím článku jsme dosáhli zvýšení výkonu 1C umístěním databází na SSD. Možná je výkon diskového subsystému serveru nedostatečný? Měřili jsme výkon diskového serveru při skupinovém běhu ve dvou databázích najednou a dostali jsme poměrně optimistický výsledek.

Přes relativně velký počet vstupně/výstupních operací za sekundu (IOPS) - 913 nepřesáhla délka fronty 1,84, což je na dvoudiskové pole velmi dobrý výsledek. Na základě toho můžeme vyslovit předpoklad, že pro běžný provoz 8-10 síťových klientů v těžkých režimech bude stačit zrcadlo z běžných disků.

Je tedy na serveru potřeba SSD? Na tuto otázku nejlépe odpoví testování, které jsme provedli obdobnou metodou, síťové připojení je všude 1 Gbit/s, výsledek je vyjádřen i v relativních hodnotách.

Začněme rychlostí načítání databáze.

Někomu se to může zdát překvapivé, ale SSD na serveru nemá vliv na rychlost načítání databáze. Hlavním limitujícím faktorem je zde, jak ukázal předchozí test, propustnost sítě a výkon klienta.

Pojďme k předělání:

Již výše jsme poznamenali, že výkon disku je zcela dostačující i pro práci v těžkých režimech, takže rychlost SSD také není ovlivněna, kromě neoptimalizovaného základu, který na SSD dohnal ten optimalizovaný. Ve skutečnosti to opět potvrzuje, že optimalizační operace organizují informace v databázi, snižují počet náhodných I/O operací a zvyšují rychlost přístupu k nim.

V každodenních úkolech je obrázek podobný:

Z SSD těží pouze neoptimalizovaná databáze. SSD si samozřejmě můžete pořídit, ale mnohem lepší by bylo myslet na včasnou údržbu databáze. Nezapomeňte také na defragmentaci sekce s infobázemi na serveru.

Klientský diskový subsystém a SSD

Analyzovali jsme vliv SSD na rychlost provozu lokálně instalovaného 1C, mnoho z toho, co bylo řečeno, platí také pro práci v síťovém režimu. Ve skutečnosti 1C poměrně aktivně využívá diskové prostředky, a to i pro úkoly na pozadí a rutinní úkoly. Na obrázku níže můžete vidět, jak Accounting 3.0 celkem aktivně přistupuje k disku asi 40 sekund po načtení.

Ale zároveň byste si měli uvědomit, že pro pracovní stanici, kde se aktivně pracuje s jednou nebo dvěma informačními databázemi, jsou výkonové zdroje běžného sériově vyráběného HDD zcela dostatečné. Nákup SSD může urychlit některé procesy, ale radikálního zrychlení při každodenní práci nezaznamenáte, protože například stahování bude omezeno šířkou pásma sítě.

Pomalý pevný disk může zpomalit některé operace, ale sám o sobě nemůže způsobit zpomalení programu.

RAM

Navzdory skutečnosti, že RAM je nyní obscénně levná, mnoho pracovních stanic nadále pracuje s množstvím paměti, která byla nainstalována při nákupu. Tady číhají první problémy. Na základě skutečnosti, že průměrná „trojka“ vyžaduje asi 500 MB paměti, můžeme předpokládat, že celková velikost RAM 1 GB nebude pro práci s programem stačit.

Snížili jsme systémovou paměť na 1 GB a spustili dvě informační databáze.

Na první pohled není vše tak špatné, program krotil své choutky a dobře se vešel do dostupné paměti, ale nezapomínejme, že potřeba provozních dat se nezměnila, takže kam se poděl? Podstatou této operace, která je uložena na disk, mezipaměť, swap atd., je, že data, která nejsou v tuto chvíli potřebná, jsou odesílána z rychlé paměti RAM, jejíž množství nestačí, do zpomalené paměti disku.

kam to vede? Podívejme se, jak jsou systémové prostředky využívány v těžkých operacích, například spusťte skupinový retransfer ve dvou databázích najednou. Nejprve na systému s 2 GB RAM:

Jak vidíme, systém aktivně využívá síť pro příjem dat a aktivita procesoru pro jejich zpracování je během zpracování nevýznamná, ale není omezujícím faktorem;

Nyní zmenšíme paměť na 1 GB:

Situace se radikálně mění, hlavní zátěž nyní padá na pevný disk, procesor i síť jsou nečinné a čekají, až systém načte potřebná data z disku do paměti a pošle tam nepotřebná data.

Přitom i subjektivní práce se dvěma otevřenými databázemi na systému s 1 GB paměti se ukázala jako krajně nepohodlná, adresáře a časopisy se otevíraly s výrazným zpožděním a aktivním přístupem na disk. Například otevření deníku Prodej zboží a služeb trvalo asi 20 sekund a celou tu dobu bylo doprovázeno vysokou aktivitou disku (zvýrazněno červenou čarou).

Abychom objektivně vyhodnotili vliv paměti RAM na výkon konfigurací založených na spravované aplikaci, provedli jsme tři měření: rychlost načítání první databáze, rychlost načítání druhé databáze a opětovné spuštění skupiny v jedné z databází. . Obě databáze jsou zcela totožné a vznikly zkopírováním optimalizované databáze. Výsledek je vyjádřen v relativních jednotkách.

Výsledek mluví za vše: pokud se doba načítání prodlouží zhruba o třetinu, což je ještě celkem snesitelné, tak se čas na provádění operací v databázi prodlouží třikrát, o nějaké pohodlné práci v takových podmínkách není třeba mluvit. Mimochodem, to je případ, kdy nákup SSD může situaci zlepšit, ale mnohem jednodušší (a levnější) je řešit příčinu, ne následky a stačí koupit správné množství RAM.

Nedostatek paměti RAM je hlavním důvodem, proč se práce s novými konfiguracemi 1C ukazuje jako nepohodlná. Konfigurace s 2 GB paměti na desce by měly být považovány za minimálně vhodné. Zároveň mějte na paměti, že v našem případě byly vytvořeny „skleníkové“ podmínky: čistý systém, běžel pouze 1C a správce úloh. V reálu je na pracovním počítači zpravidla otevřený prohlížeč, kancelářský balík, běží antivir atd. atd., takže vycházejte z potřeby 500 MB na databázi plus nějakou rezervu, aby při těžkých operacích se nesetkáte s nedostatkem paměti a prudkým poklesem produktivity.

procesor

Bez nadsázky lze centrální procesor nazvat srdcem počítače, protože je to on, kdo nakonec zpracovává všechny výpočty. Abychom vyhodnotili jeho roli, provedli jsme další sadu testů, stejnou jako u RAM, snížili jsme počet jader dostupných pro virtuální stroj ze dvou na jedno a test byl proveden dvakrát s velikostí paměti 1 GB a 2 GB.

Výsledek se ukázal být docela zajímavý a nečekaný: výkonnější procesor docela efektivně převzal zátěž při nedostatku zdrojů, zbytek času bez jakýchkoli hmatatelných výhod. 1C Enterprise (v souborovém režimu) lze jen stěží nazvat aplikací, která aktivně využívá prostředky procesoru, je spíše nenáročná. A ve ztížených podmínkách není procesor zatěžován ani tak samotným výpočtem dat aplikace, ale obsluhou režijních nákladů: dodatečné vstupně/výstupní operace atd.

závěry

Proč je tedy 1C pomalé? Za prvé je to nedostatek paměti RAM, hlavní zátěž v tomto případě padá na pevný disk a procesor. A pokud nezáří výkonem, jak je tomu obvykle v kancelářských konfiguracích, dostaneme situaci popsanou na začátku článku - „dvojka“ fungovala dobře, ale „trojka“ je bohapustě pomalá.

Na druhém místě je výkon sítě, pomalý 100 Mbit/s kanál se může stát skutečným úzkým hrdlem, ale zároveň je režim tenkého klienta schopen udržet poměrně pohodlnou úroveň provozu i na pomalých kanálech.

Pak byste měli věnovat pozornost diskové jednotce; nákup SSD pravděpodobně nebude dobrou investicí, ale výměna jednotky za modernější by byl dobrý nápad. Rozdíl mezi generacemi pevných disků lze posoudit z následujícího materiálu: .

A nakonec procesor. Rychlejší model samozřejmě nebude zbytečný, ale nemá smysl zvyšovat jeho výkon, pokud se tento počítač nepoužívá pro náročné operace: skupinové zpracování, těžké sestavy, uzávěrka na konci měsíce atd.

Doufáme, že vám tento materiál pomůže rychle pochopit otázku „proč je 1C pomalý“ a vyřešit ji co nejefektivněji a bez dalších nákladů.

• Štítky: