1s 8.3 windows xp funguje pomalu. Tipy pro automatizaci. Deaktivace účtování provozních dávek

23.03.2024

V poslední době si uživatelé a správci stále více 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řikrát 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 vyrobené z běžných disků.

Je tedy na serveru potřeba SSD? Na tuto otázku nejlépe odpoví testování, které jsme prováděli podobnou 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. 1C skutečně 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:

Pro zobrazení prosím povolte JavaScript

Hlavním účelem psaní tohoto článku je vyhnout se opakování zjevných nuancí pro ty administrátory (a programátory), kteří ještě nezískali zkušenosti s 1C.

Sekundárním cílem je, že pokud budu mít nějaké nedostatky, Infostart mě na to nejrychleji upozorní.

Test V. Gileva se již stal jakýmsi „de facto“ standardem. Autor na svém webu dal celkem jasná doporučení, ale já jen uvedu nějaké výsledky a vyjádřím se k nejpravděpodobnějším chybám. Výsledky testů na vašem zařízení se samozřejmě mohou lišit, toto je pouze vodítko pro to, co by mělo být a o co se můžete snažit. Okamžitě bych rád poznamenal, že změny je třeba provádět krok za krokem a po každém kroku zkontrolovat, jaký výsledek přinesl.

Na Infostartu jsou podobné články, odkazy na ně dám do příslušných sekcí (pokud mi něco chybí, navrhněte mě prosím v komentářích, doplním). Předpokládejme tedy, že vaše 1C je pomalé. Jak diagnostikovat problém a jak pochopit, kdo je na vině, správce nebo programátor?

Počáteční údaje:

Testovaný počítač, hlavní pokusný králík: HP DL180G6, osazený 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Pro srovnání Core i3-2100 vykazuje srovnatelné výsledky v jednovláknovém testu. Zařízení, které jsem záměrně zvolil, nebylo nejnovější, s moderním vybavením jsou výsledky znatelně lepší.

Pro testování samostatných serverů 1C a SQL Server SQL: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Pro testování 10Gbit sítě byly použity adaptéry Intel 520-DA2.

Verze souboru. (databáze je na serveru ve sdílené složce, klienti se připojují přes síť, protokol CIFS/SMB). Algoritmus krok za krokem:

0. Přidejte testovací databázi Gilev na souborový server do stejné složky jako hlavní databáze. Připojíme se z klientského počítače a spustíme test. Výsledek si pamatujeme.

Rozumí se, že i pro staré počítače před 10 lety (Pentium na patici 775 ) doba od kliknutí na zástupce 1C:Enterprise do zobrazení databázového okna by měla uplynout méně než minutu. ( Celeron = pomalý).

Pokud máte počítač horší než Pentium zásuvka 775 s 1 GB RAM, pak s vámi sympatizuji a bude pro vás obtížné dosáhnout pohodlné práce na 1C 8.2 ve verzi souboru. Přemýšlejte buď o upgradu (je nejvyšší čas), nebo o přechodu na terminálový (nebo webový, v případě tenkých klientů a spravovaných formulářů) server.

Pokud počítač není o nic horší, pak můžete správce kopnout. Minimálně zkontrolujte fungování sítě, antiviru a ovladače ochrany HASP.

Pokud Gilevův test v této fázi ukázal 30 „papoušků“ nebo více, ale pracovní základna 1C stále funguje pomalu, měly by být otázky směřovány na programátora.

1. Jako vodítko k tomu, kolik dokáže klientský počítač „zmáčknout“, zkontrolujeme provoz pouze tohoto počítače bez sítě. Testovací databázi nainstalujeme na lokální počítač (na velmi rychlý disk). Pokud klientský počítač nemá normální SSD, vytvoří se ramdisk. Prozatím nejjednodušší a bezplatný je Ramdisk enterprise.

K testování verze 8.2 stačí 256 MB ramdisk a! Nejdůležitější. Po restartu počítače při spuštěném ramdisku by na něm mělo být volných 100-200 MB. Bez ramdisku by tedy pro normální provoz mělo být 300-400 MB volné paměti.

Pro testování verze 8.3 stačí 256 MB ramdisk, ale potřebujete více volné RAM.

Při testování je potřeba se podívat na vytížení procesoru. V případě blízkém ideálu (ramdisk) místní soubor 1c při běhu načte 1 jádro procesoru. Pokud tedy během testování není jádro procesoru plně zatíženo, hledejte slabá místa. Trochu emotivní, ale obecně správný, je popsán vliv procesoru na chod 1C. Jen pro informaci, i na moderních Core i3 s vysokými frekvencemi jsou čísla 70-80 docela realistická.

Nejčastější chyby v této fázi.

a) Nesprávně nakonfigurovaný antivirus. Antivirů je mnoho, nastavení u každého je jiné, řeknu jen, že při správné konfiguraci web ani Kaspersky 1C neruší. Při výchozím nastavení lze odebrat přibližně 3-5 papoušků (10-15%).

b) Režim výkonu. Z nějakého důvodu tomu málokdo věnuje pozornost, ale efekt je nejvýraznější. Pokud potřebujete rychlost, musíte to udělat na klientských i serverových počítačích. (Gilev má dobrý popis. Jedinou výhradou je, že na některých základních deskách, pokud vypnete Intel SpeedStep, nemůžete zapnout TurboBoost).

Zkrátka při běhu 1C se hodně čeká na odezvu ostatních zařízení (disk, síť atd.). Pokud je během čekání na odezvu povolen režim výkonu, procesor sníží frekvenci. Ze zařízení přichází odezva, 1C (procesor) musí pracovat, ale první hodinové cykly jsou na snížené frekvenci, pak se frekvence zvyšuje - a 1C opět čeká na odezvu zařízení. A tak - mnoho setkrát za sekundu.

Režim výkonu můžete (a nejlépe) povolit na dvou místech:

Přes BIOS. Zakázat režimy C1, C1E, Intel C-state (C2, C3, C4). V různých bios se nazývají různě, ale význam je stejný. Hledání trvá dlouho, je vyžadován restart, ale pokud to uděláte jednou, můžete na to zapomenout. Pokud v BIOSu uděláte vše správně, rychlost se zvýší. Na některých základních deskách můžete nakonfigurovat nastavení systému BIOS tak, aby režim výkonu systému Windows nehrál roli. (Příklady nastavení systému BIOS od společnosti Gilev). Tato nastavení se týkají hlavně serverových procesorů nebo „pokročilých“ BIOSů, pokud jste to nenašli a NEMÁTE Xeon, nevadí.

Ovládací panel - Napájení - Vysoký výkon. Mínus - pokud počítač nebyl delší dobu v servisu, bude vydávat hlasitější hluk ventilátoru, více se zahřívat a spotřebovávat více energie. Jedná se o výkonnostní poplatek.

Jak zkontrolovat, zda je režim povolen. Spusťte správce úloh - výkon - sledování prostředků - CPU. Čekáme, až bude procesor ničím zaneprázdněn.

Toto jsou výchozí nastavení.

Ve stavu C BIOSu zahrnuta,

režim vyvážené spotřeby energie

Ve stavu C BIOSu zahrnuta, režim vysokého výkonu

Pro Pentium a Core se můžete zastavit tam,

Z Xeonu se ještě dá vymáčknout trochu „papoušků“.

Ve stavu C BIOSu vypnutý, režim vysokého výkonu.

Pokud nepoužíváte Turbo boost, tak by to mělo vypadat takto

server vyladěný na výkon

A teď ta čísla. Připomenu: Intel Xeon 5650, ramdisk. V prvním případě test ukazuje 23,26, v posledním - 49,5. Rozdíl je téměř dvojnásobný. Čísla se mohou lišit, ale poměr zůstává pro Intel Core v podstatě stejný.

Vážení administrátoři, můžete 1C kritizovat, jak chcete, ale pokud koncoví uživatelé potřebují rychlost, musíte povolit režim vysokého výkonu.

c) Turbo Boost. Nejprve musíte pochopit, zda například váš procesor tuto funkci podporuje. Pokud to podporuje, tak stále můžete zcela legálně získat nějaký výkon. (Nechci se dotknout otázek přetaktování frekvence, zejména serverů, dělejte to na vlastní nebezpečí a riziko. Souhlasím však s tím, že zvýšení rychlosti sběrnice ze 133 na 166 poskytuje velmi znatelné zvýšení rychlosti i rozptylu tepla)

Jak zapnout turbo boost je napsáno například . Ale! Pro 1C existují určité nuance (ne nejzřetelnější). Potíž je v tom, že maximální účinek turbo boostu nastává, když je zapnutý C-stav. A dostaneme něco takového:

Vezměte prosím na vědomí, že násobič je maximální, rychlost jádra je krásná a výkon je vysoký. Ale co se stane jako výsledek s 1s?

	Faktor	Rychlost jádra (frekvence), GHz	CPU-Z Single Thread	Gilev Ramdisk test verze souboru	Gilev Ramdisk test klient-server
Bez Turbo boost
C-stav vypnutý, Turbo boost				53.19	40,32
C-stav zapnutý, Turbo boost			1080	53,13	23,04

Ale nakonec se ukazuje, že podle testů výkonu CPU je napřed verze s násobitelem 23, podle Gilevových testů v souborové verzi je výkon s násobitelem 22 a 23 stejný, ale v klient-server verze - verze s násobičem 23 je strašná strašná strašná (i když je C -stav nastaven na úroveň 7, je stále pomalejší než s vypnutým C-stavem). Doporučení proto zní, abyste si obě možnosti sami prověřili a vybrali si tu nejlepší. Každopádně rozdíl mezi 49,5 a 53 papoušky je dost výrazný, hlavně bez větší námahy.

Závěr – turbo boost musí být zapnutý. Připomínám, že nestačí povolit v BIOSu položku Turbo boost, je potřeba se podívat i na další nastavení (BIOS: QPI L0s, L1 - zakázat, vyžadovat scrubbing - zakázat, Intel SpeedStep - povolit, Turbo boost - povolit Ovládací panely - Možnosti napájení - Vysoký výkon). A ještě bych (i pro verzi souboru) volil možnost, kdy je c-state vypnutý, i když je násobič menší. Dopadne to nějak takhle...

Poněkud kontroverzním bodem je frekvence pamětí. Například se ukázalo, že frekvence paměti má velmi silný vliv. Moje testy takovou závislost neodhalily. Nebudu porovnávat DDR 2/3/4, ukážu výsledky změny frekvence v rámci stejné čáry. Paměť je stejná, ale v BIOSu jsme nuceni nastavit nižší frekvence.

A výsledky testů. 1C 8.2.19.83, pro verzi souboru místní ramdisk, pro klient-server 1C a SQL na jednom počítači, Sdílená paměť. Turbo boost je v obou verzích zakázán. 8.3 ukazuje srovnatelné výsledky.

Rozdíl je v rámci chyby měření. Konkrétně jsem vytáhl screenshoty CPU-Z, abych ukázal, že se změnou frekvence se mění i další parametry, stejná CAS Latency a RAS to CAS Delay, což neutralizuje změnu frekvence. Rozdíl bude při fyzické změně paměťových modulů, z pomalejších na rychlejší, ale ani tam nejsou čísla nijak zvlášť významná.

2. Když máme vytříděný procesor a paměť klientského počítače, přejdeme na další velmi důležité místo - síť. O ladění sítě bylo napsáno mnoho knih, existují články o Infostartu ( a dalších), ale zde se tomuto tématu nebudu věnovat. Před zahájením testování 1C se prosím ujistěte, že iperf mezi dvěma počítači ukazuje celou šířku pásma (pro 1 Gbit karty - tedy alespoň 850 Mbit, nebo ještě lépe 950-980), že byla dodržena Gilevova rada. Pak - nejjednodušší test provozu bude, kupodivu, zkopírování jednoho velkého souboru (5-10 gigabajtů) přes síť. Nepřímým znakem běžného provozu na 1Gbit síti bude průměrná rychlost kopírování 100 MB/s, dobrý provoz - 120 MB/sec. Upozorňuji na skutečnost, že slabým místem (včetně) může být zatížení procesoru. SMB Protokol na Linuxu je dost špatně paralelizovaný a za provozu může celkem snadno „sežrat“ jedno jádro procesoru a nespotřebovat další.

A dál. Ve výchozím nastavení funguje klient Windows nejlépe s Windows serverem (nebo dokonce pracovní stanicí Windows) a protokolem SMB/CIFS, linuxový klient (debian, ubuntu se na ostatní nedívalo) funguje lépe s linuxem a NFS ( funguje to i s SMB, ale na NFS jsou papoušci vyšší). To, že se při lineárním kopírování Windows Linux server na NFS zkopíruje do jednoho streamu rychleji, nic neznamená. Ladění Debianu pro 1C je téma na samostatný článek, ještě na to nejsem připravený, i když můžu říct, že v souborové verzi jsem dostal ještě o něco lepší výkon než Win verze na stejném vybavení, ale s postgresem s nad 50 uživatelů Pořád mám všechno velmi špatné.

Nejdůležitější , které „vypálení“ správci znají, ale začátečníci neberou v úvahu. Existuje mnoho způsobů, jak nastavit cestu k databázi 1c. Můžete udělat \\server\share, můžete udělat \\192.168.0.1\share, můžete net use z: \\192.168.0.1\share (a v některých případech bude tato metoda také fungovat, ale ne vždy) a pak určete jednotku Z Zdá se, že všechny tyto cesty směřují na stejné místo, ale pro 1C existuje pouze jedna cesta, která poskytuje normální výkon celkem spolehlivě. Takže toto je to, co musíte udělat správně:

Na příkazovém řádku (nebo v zásadách nebo cokoli, co se vám hodí) - použijte DriveLetter: \\server\share. Příklad: net use m:\\server\bases. Konkrétně zdůrazňuji NE IP adresu, jmenovitě název server. Pokud se název serveru nezobrazuje, přidejte jej do DNS na serveru nebo lokálně do souboru hosts. Ale adresa musí být na jméno. Podle toho na cestě do databáze přistupte na tento disk (viz obrázek).

A teď na číslech ukážu, proč je to ta rada. Počáteční údaje: Intel X520-DA2, Intel 362, Intel 350, karty Realtek 8169 OS Win 2008 R2, Win 7, Debian 8. Nejnovější ovladače, aktualizace. Před testováním jsem se ujistil, že Iperf poskytuje plnou šířku pásma (kromě 10 Gbit karet dokázal vymáčknout pouze 7,2 Gbit, uvidím později, testovací server ještě není správně nakonfigurován). Disky jsou různé, ale všude je SSD (speciálně jsem na testování vložil jediný disk, není zatížen ničím jiným) nebo raid z SSD. Rychlost 100 Mbit byla získána omezením nastavení adaptéru Intel 362 Mezi 1 Gbit měděným Intel 350 a 1 Gbit optickým Intel X520-DA2 (získaným omezením rychlosti adaptéru) nebyl žádný rozdíl. Maximální výkon, turbo boost je vypnutý (jen pro srovnatelnost výsledků, turbo boost pro dobré výsledky přidává o něco méně než 10%, pro špatné výsledky to nemusí mít vůbec žádný efekt). Verze 1C 8.2.19.86, 8.3.6.2076. Neuvádím všechna čísla, ale jen ta nejzajímavější, abyste měli s čím porovnávat.

	Win 2008 - Win 2008 kontakt přes ip adresu	Win 2008 - Win 2008 Volání jménem	Win 2008 - Win 2008 Kontakt podle IP adresy	Win 2008 - Win 2008 Volání jménem	Win 2008 - Win 7 Volání jménem	Win 2008 - Debian Volání jménem	Win 2008 - Win 2008 Kontakt podle IP adresy	Win 2008 - Win 2008 Volání jménem
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1C 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

Závěry (z tabulky a z osobní zkušenosti. Platí pouze pro verzi souboru):

Po síti můžete získat docela normální čísla pro práci, pokud je tato síť správně nakonfigurována a cesta je správně zadána v 1C. I první Core i3 umí vyrobit klidně 40+ papoušků, což je docela dobré a nejsou to jen papoušci, v reálné práci je rozdíl také znát. Ale! Omezením při práci s více (více než 10) uživateli již nebude síť, zde stále stačí 1 Gbit, ale blokování při víceuživatelské práci (Gilev).

Platforma 1C 8.3 je mnohonásobně náročnější na správnou konfiguraci sítě. Základní nastavení – viz Gilev, ale mějte na paměti, že vše lze ovlivnit. Viděl jsem zrychlení od odinstalování (a nejen vypnutí) antiviru, od odebrání protokolů jako FCoE, od změny ovladačů na starší, ale Microsoft certifikovanou verzi (zejména u levných karet jako ASUS a DLC), od odebrání druhé síťové karty ze serveru. Možností je spousta, nastavujte si síť pečlivě. Může nastat situace, kdy platforma 8.2 poskytuje přijatelná čísla a 8.3 - dvakrát nebo dokonce vícekrát méně. Zkuste si pohrát s platformou verze 8.3, někdy získáte velmi velký efekt.

1C 8.3.6.2076 (možná později, přesnou verzi jsem ještě nehledal) je stále jednodušší na konfiguraci přes síť než 8.3.7.2008. Normálního provozu po síti se mi od 8.3.7.2008 (u srovnatelných papoušků) podařilo jen párkrát zopakovat pro obecnější případ; Moc jsem tomu nerozuměl, ale soudě podle zábalů nohou z Process Exploreru tam záznam není tak dobrý jako v 8.3.6.

Navzdory tomu, že při práci na 100 Mbit síti je její graf zatížení malý (dá se říci, že síť je volná), provozní rychlost je stále mnohem menší než na 1 Gbit. Důvodem je latence sítě.

Všechny ostatní věci jsou stejné (dobře fungující síť) pro 1C 8.2 je připojení Intel-Realtek o 10 % pomalejší než Intel-Intel. Ale realtek-realtek obecně dokáže z ničeho nic prudce klesnout. Proto, pokud máte peníze, je lepší mít síťové karty Intel všude, pokud nemáte peníze, nainstalujte Intel pouze na server (vaše CO). A návodů na ladění síťových karet Intel je mnohonásobně více.

Výchozí nastavení antiviru (jako příklad používáme drweb verze 10) zabírá asi 8-10 % papoušků. Pokud to nakonfigurujete tak, jak má (povolíte procesu 1cv8 dělat vše, ačkoli to není bezpečné), rychlost je stejná jako bez antiviru.

NEČTĚTE Linuxové guru. Server se sambou je skvělý a zdarma, ale pokud na server nainstalujete Win XP nebo Win7 (nebo ještě lépe - server OS), bude verze souboru 1c fungovat rychleji. Ano, samba a zásobník protokolů a nastavení sítě a mnohem, mnohem více lze dobře vyladit v debian/ubuntu, ale toto je doporučeno pro specialisty. Nemá smysl instalovat Linux s výchozím nastavením a pak říkat, že je pomalý.

Je docela dobrý nápad zkontrolovat fungování disků připojených přes net use pomocí fio . Alespoň bude jasné, zda se jedná o problémy s platformou 1C, nebo se sítí/diskem.

U verze pro jednoho uživatele mě nenapadají testy (nebo situace), kdy by byl viditelný rozdíl mezi 1 Gbit a 10 Gbit. Jediné, kde 10Gbit pro verzi souboru dávalo lepší výsledky, je připojení disků přes iSCSI, ale to je téma na samostatný článek. Přesto si myslím, že pro verzi souboru stačí 1 Gbit karty.

Nechápu, proč u 100 Mbit sítě funguje 8.3 znatelně rychleji než 8.2, ale byla to skutečnost. Všechna ostatní zařízení, všechna ostatní nastavení jsou naprosto stejná, jen se v jednom případě testuje 8.2 a ve druhém - 8.3.

Nenaladěný NFS win-win nebo win-lin dává 6 papoušků, do tabulky jsem je nezahrnul. Po naladění jsem dostal 25, ale bylo to nestabilní (rozdíl v měření byl více než 2 jednotky). Nemohu zatím dát doporučení k používání Windows a protokolu NFS.

Po všech nastaveních a kontrolách spouštíme test znovu z klientského počítače a radujeme se z vylepšeného výsledku (pokud funguje). Pokud se výsledek zlepšil, existuje více než 30 papoušků (a zejména více než 40), současně pracuje méně než 10 uživatelů a pracovní databáze je stále pomalá - téměř jistě problém s programátorem (nebo máte již dosáhl maximálních možností verze souboru).

Terminálový server. (databáze je na serveru, klienti se připojují přes síť, protokol RDP). Algoritmus krok za krokem:

0. Přidejte testovací databázi Gilev na server do stejné složky jako hlavní databáze. Připojíme se ze stejného serveru a spustíme test. Výsledek si pamatujeme.

1. Stejným způsobem jako ve verzi souboru nastavíme dílo. V případě terminálového serveru obecně hraje hlavní roli procesor (předpokládá se, že neexistují žádná zjevná slabá místa, jako je nedostatek paměti nebo velké množství zbytečného softwaru).

2. Nastavení síťových karet v případě terminálového serveru nemá na provoz 1c prakticky žádný vliv. Pro zajištění „zvláštního“ komfortu, pokud váš server produkuje více než 50 papoušků, můžete hrát s novými verzemi protokolu RDP, jen pro pohodlí uživatelů, rychlejší odezvu a rolování.

3. Pokud aktivně pracuje velké množství uživatelů (a zde již můžete zkusit připojit 30 lidí k jedné databázi, pokud se o to pokusíte), je velmi vhodné nainstalovat SSD disk. Z nějakého důvodu se předpokládá, že disk nijak zvlášť neovlivňuje činnost 1C, ale všechny testy se provádějí s mezipamětí řadiče povolenou pro zápis, což je nesprávné. Testovací základna je malá, docela dobře se vejde do cache, proto ta vysoká čísla. Na skutečných (velkých) databázích bude všechno úplně jiné, takže cache je pro testy zakázána.

Ověřil jsem například fungování testu Gilev s různými možnostmi disku. Nainstaloval jsem disky z toho, co bylo po ruce, jen abych ukázal tendenci. Rozdíl mezi 8.3.6.2076 a 8.3.7.2008 je malý (ve verzi Ramdisk Turbo boost 8.3.6 produkuje 56.18 a 8.3.7.2008 produkuje 55.56, v ostatních testech je rozdíl ještě menší). Spotřeba energie - maximální výkon, turbo boost deaktivován (pokud není uvedeno jinak).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Jeden SSD	Ramdisk		Mezipaměť povolena řadič RAID
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1C 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

Povolená mezipaměť řadiče RAID odstraňuje všechny rozdíly mezi disky, čísla jsou stejná pro sat i cas. Testovat s ním na malém množství dat je zbytečné a nevypovídá to o žádném druhu.

U platformy 8.2 je rozdíl ve výkonu mezi možnostmi SATA a SSD více než dvojnásobný. Nejedná se o překlep. Pokud se při testu na SATA discích podíváte na monitor výkonu. pak můžete jasně vidět „Provozní doba aktivního disku (v %)“ 80-95. Ano, pokud povolíte mezipaměť samotných disků pro nahrávání, rychlost se zvýší na 35, pokud povolíte mezipaměť řadiče raid - až 49 (bez ohledu na to, které disky jsou v tuto chvíli testovány). Ale to jsou syntetické cache papoušky v reálné práci, s velkými databázemi, nikdy nebude 100% zápis cache hit ratio.

Rychlost i levných SSD (testoval jsem na Agility 3) je pro běh verze souboru poměrně dostačující. Záznamový zdroj je věc druhá, na ten je potřeba se podívat v každém konkrétním případě, je jasné, že Intel 3700 ho bude mít o řád vyšší, ale cena tomu odpovídá. A ano, chápu, že při testování SSD disku testuji ve větší míře i cache tohoto disku, reálné výsledky budou menší.

Nejsprávnější (z mého pohledu) řešení by bylo alokovat 2 SSD disky v zrcadleném raidu pro souborovou databázi (nebo více databází souborů) a nic jiného tam neumisťovat. Ano, se zrcadlem se SSD opotřebovávají stejně, a to je mínus, ale alespoň je elektronika řadiče nějak chráněna před chybami.

Hlavní výhody SSD disků pro verzi souboru se projeví, když existuje mnoho databází, každá s několika uživateli. Pokud jsou 1-2 databáze a je tam asi 10 uživatelů, budou stačit disky SAS. (ale v každém případě se podívejte na načítání těchto disků, alespoň přes perfmon).

Hlavní výhody terminálového serveru jsou, že může mít velmi slabé klienty a nastavení sítě ovlivní terminálový server mnohem méně (opět vaše K.O.).

Závěry: pokud spustíte test Gilev na terminálovém serveru (ze stejného disku, kde jsou umístěny pracovní databáze) a v okamžicích, kdy se pracovní databáze zpomalí, a test Gilev ukazuje dobrý výsledek (nad 30), pak pomalý chod hlavní pracovní databáze má na svědomí nejspíše programátor.

Pokud Gilevův test ukazuje malá čísla a vy máte procesor s vysokým taktem a rychlé disky, pak si administrátor musí vzít alespoň perfmon, někam zaznamenat všechny výsledky a sledovat, pozorovat a vyvozovat závěry. Žádná definitivní rada nebude.

Možnost klient-server.

Testy byly provedeny až 8.2, protože na 8.3 vše docela vážně závisí na verzi.

Pro testování jsem zvolil různé možnosti serveru a sítě mezi nimi, abych ukázal hlavní trendy.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fibre channel - SSD	SQL: Xeon E5-2630 Fibre channel - SAS	SQL: Xeon E5-2630 Místní SSD	SQL: Xeon E5-2630 Fibre channel - SSD	SQL: Xeon E5-2630 Místní SSD	1C: Xeon 5650 =	1C: Xeon 5650 = Sdílená paměť	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1C 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

Zdá se, že jsem zvážil všechny zajímavé možnosti, pokud vás ještě něco zajímá, napište do komentářů, pokusím se to udělat.

SAS na úložných systémech je pomalejší než místní SSD, i když úložné systémy mají větší velikost mezipaměti. SSD, místní i na úložných systémech, pracují pro Gilevův test srovnatelnými rychlostmi. Neznám žádný standardní vícevláknový test (nejen záznam, ale veškeré vybavení) kromě zátěžového testu 1C z MCC.

Změna serveru 1C z 5520 na 5650 téměř zdvojnásobila výkon. Ano, konfigurace serveru se úplně neshodují, ale ukazuje to trend (žádné překvapení).

Zvýšení frekvence na serveru SQL má jistě efekt, ale ne stejný jako na serveru 1C MS SQL server je vynikající (pokud se ptáte) na použití více jader a volné paměti.

Změna sítě mezi 1C a SQL z 1 Gbit na 10 Gbit dává přibližně 10 % papoušků. Čekal jsem víc.

Povolení sdílené paměti má stále účinek, i když ne 15%, jak je popsáno. Určitě to udělejte, naštěstí je to rychlé a snadné. Pokud během instalace někdo dal serveru SQL pojmenovanou instanci, pak aby 1C fungoval, název serveru musí být zadán nikoli pomocí FQDN (tcp/ip bude fungovat), nikoli prostřednictvím localhost nebo pouze ServerName, ale například prostřednictvím ServerName\InstanceName zz-test\zztest. (V opačném případě dojde k chybě DBMS: Microsoft SQL Server Native Client 10.0: Poskytovatel sdílené paměti: Knihovna sdílené paměti použitá k navázání spojení se serverem SQL Server 2000 nebyla nalezena. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr : SQLSTATE=08001, stav=1, Závažnost=10, nativní=126, řádek=0).

Pro méně než 100 uživatelů je jediným bodem rozdělení na dva samostatné servery licence Win 2008 Std (a starší), která podporuje pouze 32 GB RAM. Ve všech ostatních případech je rozhodně nutné nainstalovat 1C a SQL na jeden server a dát mu více (alespoň 64 GB) paměti. Dávat MS SQL méně než 24-28 GB RAM je neopodstatněná chamtivost (pokud si myslíte, že na to máte dostatek paměti a vše funguje dobře, možná by vám stačila verze souboru 1C?)

Jak hůře funguje kombinace 1C a SQL ve virtuálním stroji, je téma na samostatný článek (nápověda - znatelně horší). Ani v Hyper-V není vše tak jasné...

Režim vyváženého výkonu je špatný. Výsledky jsou zcela v souladu s verzí souboru.

Mnoho zdrojů uvádí, že režim ladění (ragent.exe -debug) způsobuje výrazné snížení výkonu. No, snižuje to, ano, ale 2–3 % bych nenazval významným efektem.

Z různých důvodů se uživatelé programu 1C čas od času setkávají s problémy s výkonem 1C. Například: zpracování dokumentu trvá dlouho, generování sestavy dlouho, chyby transakcí, zamrzání programu, pomalá reakce na akce uživatele atd. Dodržováním našich pokynů můžete dosáhnout významného úspěchu ve výkonu programu a zabránit překročení systémového limitu. Toto není všelék na všechny neduhy, ale většina důvodů zpomalení 1C spočívá právě v těchto otázkách.

1. Během práce uživatelů neprovádějte rutinní úkoly ani úkoly na pozadí

Prvním a hlavním pravidlem pro správce systému je naplánovat všechny úlohy na pozadí tak, aby byly dokončeny mimo pracovní dobu. Systém musí být maximálně vytížený, aby mohl provádět rutinní úkony (indexování, zpracování dokumentů, nahrávání dat) a zároveň nezasahoval do práce uživatelů. Systém ani uživatelé se nebudou navzájem rušit, pokud budou pracovat v různých časech.

2. Nevyměňujte si data RIB během pracovní doby uživatelů

Přestože společnosti v poslední době opouštějí systém výměny dat RIB ve prospěch online režimu a terminálového přístupu, není na škodu připomenout, že při nahrávání a stahování výměnných dat není možné provádět dokumenty a plně pracovat v programu. Pokud je to možné, tento postup, pokud existuje, by měl být prováděn v noci pomocí úloh na pozadí.

3. Zvyšte výkon počítače včas a přizpůsobte jeho výkon skutečným potřebám

Nezapomeňte, že současný provoz 30 a 100 uživatelů v systému produkuje různé zátěže. Pokud je tedy plánováno kvantitativní zvýšení počtu uživatelů, měla by IT služba urychleně zvážit s vedením společnosti otázku rozšíření strojového parku, nákupu další paměti nebo serverů.

4. Software, na kterém běží 1C

Program 1C je takový, že na operačních systémech funguje jinak. Není přesně známo proč, ale je to tak. Například serverová verze databáze 1C na OS Linux ve spojení s SQL Postgre je mnohem pomalejší než stejná databáze 1C na OS Windows ve spojení s MS SQL. Přesné důvody této skutečnosti nejsou známy, ale zřejmě někde hluboko v platformě 1C existují problémy s kompatibilitou s operačními systémy a DBMS jiných výrobců. Pokud plánujete značné zatížení databáze, vyplatí se také nasadit systém na 64bitový server.

5. Indexování databáze

Interní postup programu 1C, který „češe“ systém zevnitř. Nastavte jej tak, aby v noci běžel jako rutinní úkol na pozadí a buďte v klidu.

6. Deaktivace účtování provozních dávek

Faktem je, že při operativním zpracování dokladů jsou pohyby evidovány v evidencích, včetně evidencí dávkového účetnictví. Evidenci registrů účtování dávek při zaúčtování dokladů lze zakázat v nastavení programu. Jednou měsíčně bude nutné začít zpracovávat zaúčtování dokladů dávkově, například v době, kdy je nejméně vytížená databáze nebo kdy pracuje nejméně uživatelů.

7. RAM

Použijte následující vzorec:

RAM = (DB 1+DB 2+DB N) / 100 * 70

Cca 70 % z celkového fyzického objemu databází. Databáze 1C se rády dobře živí RAM. Nezapomeň na to.

8. Pokud je to možné, optimalizujte samostatně psané zprávy a zpracování s nedokonalými a zastaralými kódy

Během života společnosti existuje potřeba psaní zpráv a zpracování, stejně jako zlepšení řízení obchodních procesů a získávání specifických informací. Jsou to všechna tato vylepšení, která mohou způsobit závady a zpomalit práci, protože... a) některé Kulibiny mohly kdysi napsat těžký, nesprávný kód, který je pro program obtížně proveditelný a jeho provedení vyžaduje značné úsilí b) kód, ve kterém je zapsáno zpracování nebo zpráva, může být zastaralý a vyžaduje revizi a přeprogramování; Použijte pravidlo: Čím méně něčeho v programu změníme, tím lépe.

9. Vymažte mezipaměť

Pravidelný restart serveru někdy řeší problémy se zastaralou mezipamětí 1C. Jen to zkus. Pomoci může i vykládání – načítání informační báze přes konfigurátor. A posledním čištěním mezipaměti konkrétního uživatele je smazání složek v systémovém adresáři 1C formuláře: kexifzghjuhfv8j33hbdgk0. Ale smazání uživatelských složek v mezipaměti je to poslední, protože... Kromě odstranění smetí má vymazání mezipaměti nepříjemné důsledky v podobě smazání uložených nastavení sestav a rozhraní uživatelské nabídky.

10. Snížení fyzického objemu databází

Více základny znamená více zdrojů. Přirozeně. Ke sbalení databáze použijte standardní nástroje 1C. Přemýšlejte o možnosti vzdát se pěti let dat za účelem zvýšení produktivity. A pokud stále potřebujete data za posledních pět let, můžete vždy použít kopii databáze.

11. Správná organizace architektury

Obecně platí, že architektura podnikového informačního systému musí být správná. Co rozumíme správným systémem? Srovnatelnost úkolů přidělených systému s dostupným vybavením a softwarem. Plánujte systém společně s: správcem systému (protože zná strojový park), programátorem 1C (protože zná potřeby zdrojů 1C) a vedoucím společnosti (protože ví o budoucím růstu nebo kontrakci společnosti ).

Startuje 1C za dvě minuty? Trvá otevření protokolu dokumentů 40 sekund? Je dokument uchováván téměř minutu?

Toto je známá situace, pokud používáte verzi souboru s přístupem k síti.
Můžete samozřejmě nainstalovat server a zapomenout na brzdy, ale pokud v 1C pracují pouze 2-3 lidé a utrácet peníze za nákup licencí serveru není praktické.

Příznaky:
Práce několika uživatelů v síti se stejným souborem (databází) zahrnuje mechanismus blokování sítě. To nutí systém ztrácet drahocenný čas identifikací otevřených relací nahrávání a odpovídajícím řešením konfliktů. Hlavní příznaky blokování:

rychlá uživatelská práce s databází po síti v exkluzivním režimu a extrémně pomalá, když několik uživatelů pracuje současně.
rychlá uživatelská práce s lokální databází na serveru a pomalá práce po síti.
Procesor na serveru je téměř nečinný.
Zatížení gigabitové síťové karty je nižší než 5 %.
přístupy k systému souborů jsou o něco menší než 10 MB/s.
Při pokusu o současné odeslání dokumentů se jeden počítač zastaví asi na minutu a druhý se zhroutí z 1C s chybovým textem „nepodařilo se uzamknout stůl“.
Startování 1C trvá asi 3 minuty.

Tipy, které mohou pomoci urychlit databázi souborů:

Přejděte do práce v terminálovém přístupu. Windows 7 bohužel neumožňují proměnit se v terminálový server pomocí standardních nástrojů - aktivní je maximálně jedno připojení. V tomto případě se zbývající relace neukončí; můžete se znovu připojit pod jiným uživatelem - „vyhodit“ předchozího uživatele, ale bez ukončení jeho relace. Proto byste měli přenést 1C na serverový OS, kde žádná taková omezení neexistují, nebo problém vyřešit pomocí nástroje třetí strany.
Zakažte používání síťového protokolu IPv6, nakonfigurujte adresování na „starém“ IPv4.
Přidejte procesy 1C k výjimkám brány firewall Windows a také k výjimkám antiviru nebo je úplně deaktivujte (rizikovější, ale jednoduchý test ukázal zvýšení rychlosti opětovného přenosu dokumentů s výrazně deaktivovaným antivirem Avast!)
Začněte indexovat fulltextové vyhledávání v 1C nebo jej úplně vypněte
Spusťte testování a opravu databáze, kontrolu pomocí nástroje ChDbfl (utilita se nachází ve složce „bin“ nainstalované technologické platformy).
Spusťte v konfiguraci položku "Zkontrolovat konfiguraci" (pokud konfigurace není standardní, může se to hodit).
Vypněte nepotřebné funkční možnosti (čím méně zbytečné ve spravovaném rozhraní, tím rychleji to zpravidla funguje).
Nastavte uživatelská práva (čím méně zbytečné ve spravovaném rozhraní, tím zpravidla rychleji funguje).
Začněte přepočítávat součty a obnovovat posloupnost (výrazný nárůst může nastat pouze v případě, že součty nebyly obnoveny delší dobu).
V nastavení seznamu databáze zadejte "Rychlost připojení - nízká".
Defragmentace disku s databází souborů.
Konvoluce databáze (může být užitečná, pokud je databáze velká, například několik let).
Upgrade hardwaru - rychlejší pevný disk (SSD), nový přepínač, procesor, paměť atd.
Instalace na webový server, přístup pomocí tenkého klienta.

Po dokončení všech těchto kroků může databáze souborů 1C pracovat mnohem rychleji. V některých případech to začalo za 10 sekund a rychlost přenosu dokumentů se zvýšila 12krát.

P.S. V konfiguraci UT 11.1 je spuštění souboru 1C pomocí síťového přístupu ke sdílené složce nereálné, protože I ten nejrychlejší SSD, RAM a procesor se zablokují v síti a práce více než jednoho uživatele se stává prakticky nemožným.
Samostatně psané malé konfigurace mohou fungovat poměrně rychle i ve verzi souboru.

Velmi často za námi lidé přicházejí s dotazy jako:

Proč se server 1C zpomaluje?
Počítač 1C je velmi pomalý
1C klient je strašně pomalý

Někdy jako řešení problému nabízíme klientům server pro 1C k pronájmu bez brzd, s výběrem konfigurace serveru a operačního systému, server můžete nakonfigurovat online na webu našeho partnera pomocí odkazu https://1cloud.ru kapitola Služby, kapitola Virtuální server.

Co dělat a jak to překonat a tak dále v pořadí:

Klienti pracují se serverovou verzí 1C velmi pomalu

Kromě pomalé práce 1C je tu také pomalá práce se síťovými soubory. Problém nastává při běžném provozu a při RDP

Abych to vyřešil, po každé instalaci Seven nebo serveru 2008 vždy spustím

netsh int tcp set global autotuning=disabled

netsh int tcp set global autotuninglevel=disabled

netsh int tcp set global rss=zakázáno komín=zakázáno

a síť funguje bez problémů

někdy je nejlepší možnost:

netsh interface tcp set global autotuning= HighlyRestricted

takhle vypadá instalace

Nakonfigurujte antivirový program nebo bránu firewall systému Windows

Jak nakonfigurovat antivirový nebo Windows firewall pro provozování serveru 1C (například kombinace 1C Server: Enterprise a MS SQL 2008).

Přidat pravidla:

Pokud SQL server akceptuje připojení na standardním TCP portu 1433, pak to povolíme.
Pokud je port SQL dynamický, musíte povolit připojení k aplikaci %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.
Server 1C běží na portech 1541, clusteru 1540 a rozsahu 1560-1591. Z naprosto mystických důvodů někdy takový seznam otevřených portů stále neumožňuje připojení k serveru. Abyste se ujistili, že to funguje, povolte rozsah 1540-1591.

Ladění výkonu serveru/počítače

Aby váš počítač fungoval na maximální výkon, musíte jej nakonfigurovat takto:

1. Nastavení BIOSu

V BIOSu serveru deaktivujeme všechna nastavení, abychom šetřili výkon procesoru.
Pokud je tam „C1E“ a nezapomeňte ODPOJIT!!
U některých nepříliš paralelních úloh se také doporučuje vypnout hypertrading v BIOSu
V některých případech (zejména u HP!) musíte jít do BIOSu serveru a VYPNOUT tam položky, které mají v názvu EIST, Intel SpeedStep a C1E.
Místo toho tam musíte najít položky související s procesorem, které mají v názvu Turbo Boost, a POVOLIT je.
Pokud je v systému BIOS obecná indikace režimu úspory energie a zahrňte jej do režimu maximálního výkonu (může být také nazýván „agresivní“).

2. Nastavení schématu v operačním systému - Vysoký výkon

Servery s architekturou Intel Sandy Bridge mohou dynamicky měnit frekvence procesoru.

Někdy je řešením problému pomalého provozu serveru 1C zastaralé nebo nefunkční zařízení, v tomto případě nabízíme klientům server pro 1C k pronájmu bez brzd, s možností výběru konfigurace serveru a operačního systému, můžete to udělat na našem na webu partnera, na odkazu https://1cloud.ru Sekce služeb, sekce Virtuální server.

Máte-li jakékoli dotazy, kontaktujte:

volejte +7-812-385-55-66 v Petrohradě
napište na adresu
zanechte přihlášku na našem webu na stránce „Online přihláška“.

pohledy

Uložit VKontakte