Причини за много бавна работа 1s 8. Съвети за автоматизация

Основната цел на написването на статията е да не се повтарят очевидните нюанси на онези администратори (и програмисти), които все още не са натрупали опит с 1C.

Второстепенна цел, ако имам пропуски, Инфостарт ще ми го посочи най-бързо.

Тестът на В. Гилев вече се е превърнал в своеобразен стандарт "de facto". Авторът на своя уебсайт даде доста разбираеми препоръки, но аз просто ще дам някои резултати и ще коментирам най-вероятните грешки. Естествено, резултатите от теста на вашето оборудване може да се различават, това е само насока, какво трябва да бъде и към какво можете да се стремите. Искам веднага да отбележа, че промените трябва да се правят стъпка по стъпка и след всяка стъпка проверявайте какъв резултат е дал.

В Infostart има подобни статии, в съответните раздели ще поставя връзки към тях (ако пропусна нещо, моля, кажете ми в коментарите, ще го добавя). И така, да предположим, че забавите 1C. Как да диагностицираме проблема и как да разберем кой е виновен, администраторът или програмистът?

Първоначални данни:

Тестван компютър, основно морско зайче: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. За сравнение, сравними резултати в еднонишков тест са показани от Core i3-2100. Оборудването е специално взето не най-новото, на модерно оборудване резултатите са значително по-добри.

За тестване на отдалечени 1C и SQL сървъри, SQL сървър: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

За тестване на 10 Gbit мрежа бяха използвани адаптери Intel 520-DA2.

Версия на файла. (базата е на сървъра в споделената папка, клиентите са свързани в мрежа, протоколът CIFS/SMB). Алгоритъм стъпка по стъпка:

0. Добавете тестовата база данни Gilev към файловия сървър в същата папка като основните бази данни. Свързваме се от клиентския компютър, изпълняваме теста. Помним резултата.

Разбираемо е, че дори за стари компютри преди 10 години (Pentium на 775 сокет ) времето от щракване върху етикета 1C:Enterprise до появата на прозореца на базата данни трябва да бъде по-малко от минута. ( Celeron = бавна работа).

Ако вашият компютър е по-лош от включен Pentium 775 гнездо с 1 GB RAM, тогава ви съчувствам и ще ви бъде трудно да постигнете удобна работа на 1C 8.2 във файловата версия. Обмислете или надграждане (отдавна закъсняло) или преминаване към терминален (или уеб, в случай на тънки клиенти и управлявани формуляри) сървър.

Ако компютърът не е по-лош, тогава можете да изритате администратора. Най-малко проверете работата на мрежата, антивирусната програма и драйвера за защита на HASP.

Ако тестът на Гилев на този етап показа 30 "папагала" и повече, но работната база на 1C все още работи бавно - въпросите вече са за програмиста.

1. За ориентир, колко клиентски компютър може да "изцеди", проверяваме работата само на този компютър, без мрежа. Поставихме тестовата база локален компютър(на много бърз диск). Ако клиентският компютър няма нормален SSD, тогава се създава ramdisk. Засега най-простият и безплатен е Ramdisk enterprise.

За тестване на версия 8.2 са достатъчни 256 MB ramdisk и! Най-важните. След рестартиране на компютъра с работещ рамдиск трябва да има 100-200 MB свободни. Съответно, без ramdisk, за нормална работа на свободната памет трябва да има 300-400 MB.

За тестване на версия 8.3 е достатъчен 256 MB ramdisk, но е необходима повече свободна RAM.

Когато тествате, трябва да погледнете натоварването на процесора. В случай, близък до идеалния (ramdisk), локалният файл 1c зарежда 1 процесорно ядро ​​по време на работа. Съответно, ако по време на тестване ядрото на процесора ви не е напълно заредено, потърсете слаби места. Малко емоционално, но като цяло правилно е описано влиянието на процесора върху работата на 1C. Само за справка, дори и на съвременния Core i3 с висока честотацифри 70-80 са съвсем реални.

Най-честите грешки на този етап.

а) Неправилно конфигурирана антивирусна програма. Има много антивируси, настройките за всяка са различни, мога само да кажа, че при правилна конфигурация нито мрежата, нито Kaspersky 1C се намесват. С настройките "по подразбиране" - могат да бъдат отведени около 3-5 папагала (10-15%).

б) Режим на изпълнение. По някаква причина малко хора обръщат внимание на това, а ефектът е най-значимият. Ако имате нужда от скорост, тогава трябва да го направите, както на клиентски, така и на сървърни компютри. ( добро описаниепри Гилев. Единственото предупреждение за някои дънни платкиАко изключите Intel SpeedStep, тогава не можете да включите TurboBoost).

Накратко, по време на работа на 1C има много изчакване за отговор от други устройства (диск, мрежа и т.н.). Докато чакате отговор, ако режимът на производителност е балансиран, тогава процесорът намалява честотата си. Отговорът идва от устройството, 1C (процесор) трябва да работи, но първите цикли вървят намалена честота, след това честотата се повишава - и 1C отново чака отговор от устройството. И така - много стотици пъти в секунда.

Можете (и за предпочитане) да активирате режим на производителност на две места:

Чрез BIOS. Деактивирайте режимите C1, C1E, Intel C-state (C2, C3, C4). В различните биоси те се наричат ​​по различен начин, но значението е едно и също. Търсете дълго време, изисква се рестартиране, но ако сте го направили веднъж, можете да забравите. Ако всичко е направено правилно в BIOS, тогава скоростта ще бъде добавена. На някои дънни платки настройките на BIOS могат да бъдат зададени така, че режимът на производителност на Windows да не играе роля. (Примери BIOS настройкипри Гилев). Тези настройки се отнасят главно за сървърни процесори или "advanced" BIOS, ако не сте го намерили в системата си и нямате Xeon - няма проблем.

Контролен панел - Захранване - Висока производителност. Минус - ако компютъра не е обслужван дълго време ще бръмчи по-силно с вентилатор, ще загрява повече и ще харчи повече енергия. Това е цената на изпълнението.

Как да проверите дали режимът е активиран. Стартирайте Task Manager - Performance - Resource Monitor - CPU. Изчакваме, докато процесорът не е зает с нищо.

Това са настройките по подразбиране. C-състояние на BIOS включени, режим на балансирана мощност
C-състояние на BIOS включени, режим на висока производителност За Pentium и Core можете да спрете дотук, все още можете да изстискате някои "папагали" от Xeon
C-състояние на BIOS изключено, режим на висока производителност. Ако не използвате Turbo boost - така трябва да изглежда сървър, настроен за производителност

А сега числата. Да напомня: Intel Xeon 5650, рамдиск. В първия случай тестът показва 23,26, във втория - 49,5. Разликата е почти двойна. Числата може да варират, но съотношението остава почти същото за Intel Core.

Уважаеми администратори, можете да се карате на 1C както искате, но ако крайните потребители се нуждаят от скорост, трябва да активирате режима с висока производителност.

в) Turbo Boost. Първо трябва да разберете дали вашият процесор поддържа тази функция, например. Ако това стане, тогава все още можете съвсем законно да получите известно представяне. (Не искам да засягам въпросите за овърклок, особено сървъри, направете го на свой собствен риск и риск. Но съм съгласен, че увеличаването на скоростта на шината от 133 на 166 дава много забележимо увеличение както на скоростта, така и на разсейването на топлината)

Как да включите турбо усилване е написано например. Но! За 1C има някои нюанси (не най-очевидните). Трудността е, че максималният ефект от турбо усилване се проявява, когато C-състоянието е включено. И се оказва нещо като тази снимка:

Моля, имайте предвид, че множителят е максимален, скоростта на ядрото е най-красивата, производителността е висока. Но какво ще се случи в резултат на 1s?

	Фактор	Скорост на ядрото (честота), GHz	CPU-Z единична нишка	Gilev Ramdisk тест версия на файла	Gilev Ramdisk тест клиентски сървър
без турбо усилване
C-състояние изключено, турбо усилване				53.19	40,32
С-състояние включено, турбо усилване			1080	53,13	23,04

Но в крайна сметка се оказва, че според тестовете за производителност на процесора вариантът с множител 23 е по-напред, според тестовете на Гилев във файловата версия производителността с множител 22 и 23 е същата, но в клиент-сървър версия, вариантът с множител от 23 ужас, ужас, ужас (дори ако C -state е зададено на ниво 7, пак е по-бавно, отколкото с изключено C-state). Ето защо, препоръката, проверете и двете опции за себе си и изберете най-добрата от тях. Във всеки случай разликата между 49,5 и 53 папагала е доста значителна, особено след като е без много усилия.

Извод - трябва да се включи турбо буст. Позволете ми да ви напомня, че не е достатъчно да активирате елемента Turbo boost в BIOS, трябва да погледнете и други настройки (BIOS: QPI L0s, L1 - деактивиране, почистване на изискване - деактивиране, Intel SpeedStep - активиране, Turbo boost - контролен панел - Захранване - Висока производителност) . И все пак бих се спрял (дори и за файловата версия) на опцията, при която c-state е изключено, въпреки че там множителят е по-малък. Вземете нещо подобно...

Доста спорен момент е честотата на паметта. Например, честотата на паметта е показана като много влиятелна. Моите тестове не разкриха такава зависимост. Няма да сравнявам DDR 2/3/4, ще покажа резултатите от промяната на честотата в същия ред. Паметта е същата, но в BIOS форсираме по-ниски честоти.

И резултатите от теста. 1C 8.2.19.83, за файлова версия локален ramdisk, за клиент-сървър 1C и SQL на един компютър, Споделена памет. Turbo boost е деактивирано и в двете опции. 8.3 показва сравними резултати.

Разликата е в рамките на грешката на измерване. Специално извадих екранните снимки на CPU-Z, за да покажа, че други параметри се променят с промяната на честотата, същото CAS Latency и RAS към CAS Delay, което изравнява промяната на честотата. Разликата ще бъде при физическа промяна на модулите памет, от по-бавни към по-бързи, но дори и там числата не са много значими.

2. Когато разбрахме процесора и паметта на клиентския компютър, преминаваме към следващото много важно място - мрежата. За настройката на мрежата са написани много томове книги, има статии за Infostart (и други), тук няма да се фокусирам върху тази тема. Преди да започнете да тествате 1C, моля, уверете се, че iperf между два компютъра показва цялата лента (за 1 Gbit карти - добре, поне 850 Mbit, но по-добре 950-980), че се следват съветите на Гилев. След това - най-простият тест за работа ще бъде, колкото и да е странно, копирането на такъв голям файл(5-10 гигабайта) през мрежата. Косвен знак за нормална работа в мрежа от 1 Gbps ще бъде средна скорост на копиране от 100 Mb / s, добра работа - 120 Mb / s. Искам да обърна внимание на факта, че натоварването на процесора също може да бъде слабо място (включително). SMB протоколът на Linux е доста слабо паралелен и по време на работа може доста лесно да „изяде“ едно ядро ​​на процесора и да не го консумира повече.

И по-нататък. С настройки по подразбиране Windows клиентработи най-добре с windows server (или дори работещи прозорци station) и протокола SMB / CIFS, клиентът на linux (debian, ubuntu не погледна останалите) работи по-добре с linux и NFS (работи и с SMB, но папагалите са по-високи на NFS). Фактът, че при линейно копиране на win-linux сървър в nfs се копира в един поток по-бързо, не означава нищо. Настройката на debian за 1C е тема за отделна статия, все още не съм готов за това, въпреки че мога да кажа, че във файловата версия дори получих малко по-добра производителност от версията Win на същото оборудване, но с postgres с потребители над 50 все още имам всичко много лошо.

Най-важните , което е известно на "изгорелите" администратори, но начинаещите не го вземат предвид. Има много начини да зададете пътя до базата данни 1c. Можете да направите \\server\share, можете \\192.168.0.1\share, можете да използвате net z: \\192.168.0.1\share (и в някои случаи този метод също ще работи, но не винаги) и след това задайте устройството Z. Изглежда, че всички тези пътища сочат към едно и също място, но за 1C има само един начин, който дава доста стабилна производителност. И така, ето какво трябва да направите правилно:

IN командна линия(или в политиките, или каквото ви подхожда) - използвайте net DriveLetter: \\server\share. Пример: net use m:\\server\bases. Особено подчертавам НЕ IP адрес, а именно Имесървър. Ако сървърът не се вижда по име - добавете го към dns на сървъра или локално в хост файл. Но обжалването трябва да е поименно. Съответно, по пътя към базата данни, достъп до този диск (вижте снимката).

И сега ще покажа в цифри защо такъв съвет. Първоначални данни: Карти Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. ОС Win 2008 R2, Win 7, Debian 8. Последни драйвери, приложени актуализации. Преди тестване се уверих, че Iperf дава пълната честотна лента (с изключение на 10 Gbit карти, се оказа, че изстисква само 7,2 Gbit, по-късно ще видя защо, тестовият сървър все още не е конфигуриран правилно). Дисковете са различни, но навсякъде е SSD (специално поставен един диск за тестване, нищо друго не се зарежда) или raid от SSD. Скоростта от 100 Mbit беше получена чрез ограничаване на настройките на адаптера Intel 362. Нямаше разлика между 1 Gbit меден Intel 350 и 1 Gbit оптика Intel X520-DA2 (получена чрез ограничаване на скоростта на адаптера). Максимална производителност, турбо усилване е деактивирано (само за сравнимост на резултатите, турбо усилване добавя малко по-малко от 10% за добри резултати, за лоши резултати може да не се отрази изобщо). Версии 1C 8.2.19.86, 8.3.6.2076. Не давам всички числа, а само най-интересните, за да има с какво да се сравнява.

	Win 2008 - Win 2008 обаждане по ip адрес	Win 2008 - Win 2008 Обръщение по име	Win 2008 - Win 2008 Обаждане по ip адрес	Win 2008 - Win 2008 Обръщение по име	Win 2008 - Win 7 Обръщение по име	Windows 2008 - Debian Обръщение по име	Win 2008 - Win 2008 Обаждане по ip адрес	Win 2008 - Win 2008 Обръщение по име
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1С 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

Изводи (от таблицата и от личен опит. Отнася се само за файловата версия):

През мрежата можете да получите съвсем нормални номера за работа, ако тази мрежа е нормално конфигурирана и пътят е правилно написан в 1C. Дори първите Core i3s могат да дадат 40+ папагала, което е доста добре и това не са само папагали, но и в реална работа разликата е забележима. Но! ограничението при работа с няколко (повече от 10) потребители вече няма да бъде мрежата, тук 1 Gbit все още е достатъчен, но блокиране при работа с много потребители (Гилев).

Платформата 1C 8.3 е многократно по-взискателна за компетентна настройка на мрежата. Основни настройки- вижте Гилев, но имайте предвид, че всичко може да повлияе. Видях ускорение от факта, че те деинсталираха (а не просто изключиха) антивирусната, от премахване на протоколи като FCoE, от смяна на драйвери към по-стара, но сертифицирана от Microsoft версия (особено за евтини карти като asus и longs), от премахване на втора мрежова карта от сървъра. Много опции, конфигурирайте мрежата внимателно. Възможно е да има ситуация, когато платформа 8.2 дава приемливи числа, а 8.3 - два или дори повече пъти по-малко. Опитайте се да си поиграете с платформа версии 8.3, понякога получавате много голям ефект.

1C 8.3.6.2076 (може би по-късно, все още не съм търсил точната версия) през мрежата все още е по-лесно да се настрои от 8.3.7.2008. От 08.07.2008 г. за постигане на нормална работа на мрежата (в сравними папагали) се оказа само няколко пъти, не можах да го повторя за по-общ случай. Не разбрах много, но съдейки по кърпичките от Process Explorer, записът не върви там, както в 8.3.6.

Въпреки факта, че когато работите в мрежа от 100 Mbps, нейният график на натоварване е малък (можем да кажем, че мрежата е безплатна), скоростта на работа все още е много по-малка, отколкото при 1 Gbps. Причината е латентността на мрежата.

При други равни условия (добре работеща мрежа) за 1C 8.2 връзката Intel-Realtek е с 10% по-бавна от Intel-Intel. Но realtek-realtek обикновено може да даде рязко слягане изневиделица. Ето защо, ако има пари, по-добре е да държите мрежовите карти на Intel навсякъде, ако няма пари, поставете Intel само на сървъра (вашият KO). Да, и има много пъти повече инструкции за настройка на мрежови карти на intel.

Антивирусните настройки по подразбиране (например версия drweb 10) отнемат около 8-10% от папагалите. Ако го конфигурирате правилно (разрешете на процеса 1cv8 да прави всичко, въпреки че не е безопасно) - скоростта е същата като без антивирусна.

НЕ четете Linux гурута. Сървър със samba е страхотен и безплатен, но ако поставите Win XP или Win7 на сървъра (или още по-добре - сървърна ОС), тогава във файловата версия 1c ще работи по-бързо. Да, както samba, така и протоколният стек и мрежовите настройки и много други в debian / ubuntu са добре настроени, но това се препоръчва за специалисти. Няма смисъл да инсталирате Linux с настройки по подразбиране и след това да казвате, че е бавен.

Добра идея е да тествате дискове, свързани чрез net use с fio. Поне ще стане ясно дали това са проблеми с платформата 1C или с мрежата / диска.

За еднопотребителски вариант не се сещам за тестове (или ситуация), при които да се вижда разликата между 1Gb и 10Gb. Единственото място, където 10Gbps за файловата версия дава по-добри резултати е свързването на дискове през iSCSI, но това е тема за отделна статия. Все пак смятам, че 1Gbit карти са достатъчни за файловата версия.

Защо при 100 Mbit мрежа 8.3 работи значително по-бързо от 8.2 - не разбирам, но фактът се случи. Цялото друго оборудване, всички други настройки са абсолютно еднакви, просто в единия случай се тества 8.2, а в другия - 8.3.

Ненастроен NFS win - win или win-lin дава 6 папагала, не го включих в таблицата. След настройка получих 25, но е нестабилен (разгонът в измерванията е повече от 2 единици). В момента не мога да препоръчам използване на windowsи NFS протокол.

След всички настройки и проверки, пускаме теста отново от клиентския компютър, радваме се на подобрения резултат (ако се получи). Ако резултатът се е подобрил, има повече от 30 папагала (и особено повече от 40), има по-малко от 10 потребители, работещи едновременно и работещата база данни все още се забавя - почти определено проблем на програмист (или вече сте достигна върха на възможностите на файловата версия).

терминален сървър. (базата е на сървъра, клиентите са свързани в мрежа, протоколът RDP). Алгоритъм стъпка по стъпка:

0. Добавете тестовата база данни Gilev към сървъра в същата папка като основните бази данни. Свързваме се от същия сървър и провеждаме теста. Помним резултата.

1. По същия начин, както във файловата версия, ние настройваме работата. В случай на терминален сървър, процесорът обикновено играе основна роля (разбира се, че няма очевидни слабости, като липса на памет или огромно количество ненужен софтуер).

2. Настройването на мрежови карти в случай на терминален сървър практически няма ефект върху работата на 1s. За да осигурите "специален" комфорт, ако вашият сървър дава повече от 50 папагала, можете да си поиграете с нови версии на протокола RDP, само за удобство на потребителите, по-бърза реакция и превъртане.

3. С активната работа на голям брой потребители (и тук вече можете да опитате да свържете 30 души към една база, ако опитате), е много желателно да инсталирате SSD устройство. По някаква причина се смята, че дискът не засяга особено работата на 1C, но всички тестове се извършват с активиран за писане кеш на контролера, което е погрешно. Тестовата база е малка, побира се в кеша, оттук и високите числа. В реални (големи) бази данни всичко ще бъде напълно различно, така че кешът е деактивиран за тестове.

Например, проверих работата на теста Gilev с различни опции на диска. Сложих дискове от това, което ми беше под ръка, просто да покажа склонност. Разликата между 8.3.6.2076 и 8.3.7.2008 е малка (в Ramdisk Turbo boost версия 8.3.6 дава 56.18 и 8.3.7.2008 дава 55.56, в други тестове разликата е още по-малка). Консумация на енергия - максимална производителност, турбо усилване деактивирано (освен ако не е отбелязано друго).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Единично SSD	рамдиск		Кешът е активиран RAID контролер
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1С 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

Включеният кеш на RAID контролера елиминира всички разлики между дисковете, номерата са еднакви и за sat, и за sas. Тестването с него за малко количество данни е безполезно и не е индикатор.

За платформата 8.2 разликата в производителността между опциите SATA и SSD е повече от двойна. Това не е правописна грешка. Ако погледнете монитора на производителността по време на теста на SATA устройства. след това има ясно видимо "Активно време на диска (в%)" 80-95. Да, ако активирате кеша за запис на самите дискове, скоростта ще се увеличи до 35, ако активирате кеша на raid контролера - до 49 (независимо кои дискове се тестват в този момент). Но това са синтетични папагали на кеша, при реална работа с големи бази данни никога няма да има 100% коефициент на попадение в кеша за запис.

Скоростта дори на евтини SSD (тествах на Agility 3) е достатъчна, за да работи файловата версия. Ресурсът за запис е друг въпрос, тук трябва да погледнете във всеки конкретен случай, ясно е, че Intel 3700 ще има порядък по-висок, но там цената е съответна. И да, разбирам това при тестване SSD устройствоАз също тествам кеша на този диск в по-голяма степен, реалните резултати ще бъдат по-малко.

Най-правилното (от моя гледна точка) решение би било да разпределите 2 SSD диска в огледален рейд за файловата база (или няколко файлови бази) и да не поставяте нищо друго там. Да, с огледало SSD дисковете се износват по същия начин и това е минус, но поне някак са застраховани от грешки в електрониката на контролера.

Основните предимства на SSD дисковете за файловата версия ще се появят, когато има много бази данни и всяка с няколко потребители. Ако има 1-2 бази и потребители в района на 10, тогава SAS дисковете ще бъдат достатъчни. (но за всеки случай - вижте зареждането на тези дискове, поне през perfmon).

Основните предимства на терминалния сървър са, че той може да има много слаби клиенти и мрежовите настройки влияят много по-малко на терминалния сървър (отново вашият KO).

Изводи: ако стартирате теста Gilev на терминалния сървър (от същия диск, където са работещите бази данни) и в онези моменти, когато работещата база данни се забави, тестът Gilev ще покаже добър резултат(над 30) - тогава най-вероятно програмистът е виновен за бавната работа на основната работна база.

Ако тестът на Gilev показва малки числа и имате както процесор с висока честота, така и бързи дискове, тогава тук администраторът трябва да вземе поне perfmon и да запише всички резултати някъде и да гледа, наблюдава, прави заключения. Няма да има окончателен съвет.

Опция клиент-сървър.

Тестовете бяха проведени само на 8.2, т.к. На 8.3 всичко зависи доста сериозно от версията.

За тестване избрах различни вариантисървъри и мрежата между тях, за да покаже основните тенденции.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fiber channel-SSD	SQL: Xeon E5-2630 Фибърен канал - SAS	SQL: Xeon E5-2630 Локален SSD	SQL: Xeon E5-2630 Fiber channel-SSD	SQL: Xeon E5-2630 Локален SSD	1C: Xeon 5650 =	1C: Xeon 5650 = споделена памет	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
1С 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

Изглежда, че разгледах всички интересни опции, ако се интересувате от нещо друго - пишете в коментарите, ще се опитам да го направя.

SAS при съхранение е по-бавно от локалните SSD, въпреки че хранилището има големи размери на кеша. SSD дискове и локални и системи за съхранение за теста Gilev работят със сравними скорости. Не знам нито един стандартен многонишков тест (не само записи, но и цялото оборудване), с изключение на натоварването 1C от MCC.

Промяната на сървъра 1C от 5520 на 5650 даде почти удвояване на производителността. Да, сървърните конфигурации не съвпадат напълно, но показва тенденция (нищо изненадващо).

Увеличаването на честотата на SQL сървъра, разбира се, дава ефект, но не същият като на 1C сървъра, MS SQL сървърът е напълно способен (ако бъде помолен за това) да използва многоядрена и свободна памет.

Промяната на мрежата между 1C и SQL от 1 Gbps на 10 Gbps дава около 10% от папагалите. Очаквано повече.

Активирането на споделената памет все още дава ефекта, макар и не 15%, както е описано. Не забравяйте да го направите, става бързо и лесно. Ако някой даде на SQL сървъра наименуван екземпляр по време на инсталацията, тогава, за да работи 1C, името на сървъра трябва да бъде посочено не чрез FQDN (tcp / ip ще работи), не чрез localhost или просто ServerName, а чрез ServerName\InstanceName, например zz-тест\zzтест. (В противен случай ще има грешка в СУБД: Microsoft SQL Server Native Client 10.0: Доставчик споделена памет: Библиотеката със споделена памет, използвана за установяване на връзка с SQL сървър 2000 г. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, състояние=1, сериозност=10, естествено=126, ред=0).

За потребители под 100 единственият смисъл е да се раздели на две отделни сървърие лиценз за Win 2008 Std (и по-стари версии), който поддържа само 32 GB RAM. Във всички останали случаи 1C и SQL определено трябва да се инсталират на един и същ сървър и да им се даде повече (поне 64 GB) памет. Даването на MS SQL на по-малко от 24-28 GB RAM е неоправдана алчност (ако смятате, че имате достатъчно памет за него и всичко работи добре, може би версията на файла 1C ще ви е достатъчна?)

Колко по-лошо работи куп 1C и SQL виртуална машина- темата на отделна статия (намек - забележимо по-лошо). Дори в Hyper-V нещата не са толкова ясни...

Режимът на балансирана производителност е лош. Резултатите са в добро съответствие с версията на файла.

Много източници казват, че режимът за отстраняване на грешки (ragent.exe -debug) дава силно намаляване на производителността. Е, понижава, да, но 2-3% не бих нарекъл съществен ефект.

Често потребителите се оплакват, че „1C 8.3 се забавя“: формулярите на документи се отварят бавно, документите се публикуват дълго време, програмата се стартира, отчетите се генерират дълго време и т.н.

Освен това такива "бъгове" могат да възникнат в различни програми:

Причините може да са различни. Това не е възстановено съхраняване на документи, слаб компютър или сървър, 1C сървърът е неправилно конфигуриран.

В тази статия искам да разгледам една от най-простите и често срещани причини за бавна програма -. Тази инструкцияще бъде от значение за потребители на файлови бази данни за 1-2 потребители, където няма конкуренция за ресурси.

Ако се интересувате от по-сериозна оптимизация на клиент-сървър опциите за системата, посетете секцията на сайта.

Къде са планираните задачи в 1C 8.3

Нямах време да изтегля програмата, тъй като в 1C много фонови работни места. Можете да ги видите, като отидете в менюто "Администрация", след това - "Поддръжка и поддръжка":

Вземете 267 1C видео урока безплатно:

Ето как изглежда прозорецът с изпълнените задачи:

И така пълен списъквсичко рутинни задачикоито се изпълняват:

Сред тези задачи са видими като "", зареждане на различни класификатори, проверка на уместността на версията на програмата и т.н. Аз например нямам нужда от почти всички тези задачи. Не водя валутни записи, сам контролирам версиите, качвам класификатори според нуждите.

Съответно, в мой (и в повечето случаи във ваш) интерес е да деактивирам ненужните задачи.

Деактивиране на планирани и фонови задачи в 1C 8.3

Системата 1C заема доминираща позиция на пазара за автоматизация за малки и средни предприятия. Ако една компания е избрала счетоводна система 1C, тогава обикновено почти всички служители работят в нея, от обикновени специалисти до ръководство. Съответно скоростта на бизнес процесите на компанията зависи от скоростта на 1C. Ако 1C работи с незадоволителна скорост, това пряко засяга работата на цялата компания и печалбата.

Всъщност има три метода за ускоряване на 1C:

• Увеличаване на хардуерния капацитет.
• Оптимизация на настройките операционна системаи СУБД.
• Оптимизиране на код и алгоритми в 1C.

Първият метод изисква закупуване на оборудване и лицензи, третият изисква много труд за програмистите и в резултат на това и двата начина водят до значителни финансови разходи. На първо място, трябва да обърнете внимание на програмния код, тъй като никакво увеличение на капацитета на сървъра не може да компенсира неправилния код. Всеки програмист знае, че само с няколко реда код е възможно да се създаде процес, който да натовари напълно ресурсите на всеки сървър.

Ако компанията е уверена в оптималността на програмния код и той все още работи бавно, обикновено ръководството решава да увеличи капацитета на сървъра. В този момент възниква логичен въпрос: какво липсва, колко и какво трябва да се добави в резултат.

Компанията 1C дава доста неясен отговор на въпроса колко ресурси са необходими, писахме за това по-рано в нашите публикации. И така, трябва самостоятелно да провеждате експерименти и да разберете от какво зависи производителността на 1C. Експериментите за ефективност в EFSOL са описани по-долу.

Когато работите с 1C 8.2, особено с конфигурации, които използват управлявани форми, беше забелязан странен факт: 1C работи по-бързо на работна станция, отколкото на мощен сървър. Освен това всички характеристики на работната станция са по-лоши от тези на сървъра.

Таблица 1 - Конфигурации, на които е извършено първоначалното тестване

Работната станция показва производителност със 155% повече от 1C сървър с превъзходна производителност. Започнахме да разбираме какво е и стесняваме кръга от търсения.

Фигура 1 - Измервания на производителността на работната станция чрез теста на Gilev

Първото съмнение беше, че тестът на Гилев е неадекватен. Измерванията на отваряне на формуляри, публикуване на документи, генериране на отчети и т.н. с помощта на инструментални инструменти показаха, че тестът Gilev дава оценка, пропорционална на действителната скорост на работа в 1C.

Брой и честота на RAM

Анализът на наличната информация в Интернет показа, че мнозина пишат за зависимостта на производителността на 1C от честотата на паметта. Това е от честотата, а не от обема. Решихме да тестваме тази хипотеза, тъй като имаме RAM честота от 1066 Mhz на сървъра срещу 1333 Mhz на работната станция, а количеството RAM на сървъра вече е много по-високо. Решихме да поставим не 1066 Mhz, а 800 Mhz веднага, за да направим ефекта от зависимостта на производителността от честотата на паметта по-видим. Резултатът - производителността спадна с 12% и възлиза на 39,37 единици. Инсталирахме памет с честота 1333 Mhz вместо 1066 Mhz на сървъра и получихме леко увеличение на производителността - около 11%. Производителността е 19,53 единици. Съответно, не става дума за памет, въпреки че нейната честота дава малко увеличение.

Фигура 2 - Измервания на производителността на работната станция след намаляване на честотата на RAM

Фигура 3 - Измервания на производителността на сървъра след увеличаване на честотата на RAM

Дискова подсистема

Следващата хипотеза беше свързана с дисковата подсистема. Веднага възникнаха две хипотези:

• SSD са по-добри от SAS устройствата, дори ако са в raid 10.
• iSCSI е бавен или не работи правилно.

Затова в работната станция беше инсталиран обикновен SATA диск вместо SSD и същото беше направено със сървъра - основата беше поставена на локален SATA диск. В резултат на това измерванията на производителността не са се променили по никакъв начин. Най-вероятно това се случва, тъй като има достатъчно RAM и дисковете практически не се използват по никакъв начин по време на теста.

процесор

Процесорите на сървъра, разбира се, са по-мощни и има два от тях, но честотата е малко по-ниска, отколкото на работната станция. Решихме да проверим ефекта от честотата на процесора върху производителността: нямаше процесори с по-висока честота под ръка за сървъра, така че намалихме честотата на процесора на работната станция. Веднага го намалихме до 1,6, така че корелацията да се прояви по-ярко. Тестът показа, че производителността е спаднала значително, но дори и с 1.6 процесор, работната станция произвежда почти 28 единици, което е почти 1,5 пъти повече, отколкото на сървъра.

Фигура 4 - Измервания на производителността на работна станция с 1,6 Ghz процесор

видео карта

В интернет има информация, че видеокартата може да повлияе на производителността на 1C. Опитахме се да използваме интегрирано видео на работна станция, професионален адаптер Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, стара видео карта GeForce 16MbSDR. По време на теста на Гилев не се забелязва съществена разлика. Може би видеокартата все още влияе, но в реални условия, когато трябва да отворите управлявани форми и т.н.

В момента има две подозрения защо работната станция работи по-бързо дори при значително по-лоша производителност:

1. ПРОЦЕСОР.Типът процесор на работната станция е по-подходящ за 1C.
2. Чипсет.При равни други условия нашата работна станция е с по-нов чипсет, което може да е причината.

Планираме да закупим необходимите компоненти и да продължим тестовете, за да разберем най-накрая от какво зависи в по-голяма степен производителността на 1C. Докато тече процесът на одобрение и обществена поръчка, решихме да направим оптимизация, още повече, че не струва нищо. Идентифицирани са следните стъпки:

Етап 1. Настройка на системата

Първо, нека направим следните настройки в BIOS и операционната система:

1. В BIOS на сървъра деактивирайте всички настройки, за да спестите мощност на процесора.
2. Изберете плана "Максимална производителност" в операционната система.
3. Процесорът също е настроен за максимална производителност. Това може да стане с помощта на помощната програма PowerSchemeEd.

Етап 2. Настройка на SQLсървъри и сървъри 1C:Enterprise

Правим следните промени в настройките на СУБД сървъра и 1C:Enterprise.

1. Конфигуриране на протокола за споделена памет:
   
   
   • Споделената памет ще бъде активирана само на платформата, започваща от 1C 8.2.17, в по-ранни версии Named Pipe ще бъде активирана - малко по-ниска по скорост. Тази технологияработи само ако услугите 1C и MSSQL са инсталирани на един и същ физически или виртуален сървър.
2. Препоръчително е да поставите услугата 1C в режим на отстраняване на грешки, парадоксално това дава тласък на производителността. По подразбиране отстраняването на грешки е деактивирано на сървъра.
3. Настройка на SQL сървър:
   
   
   • Имаме нужда само от сървър, останалите услуги, които принадлежат към него и може би някой ги използва, само забавят работата. Ние спираме и деактивираме такива услуги като: пълнотекстово търсене (1C има собствен механизъм за пълнотекстово търсене), интеграционни услуги и др.
   • Задайте максималното количество памет, разпределено на сървъра. Това е необходимо, за да може sql сървърът да разчита на тази сума и да почисти паметта предварително.
   • Задайте максималния брой нишки (Максимални работни нишки) и задайте повишен приоритет на сървъра (Приоритет на повишаване).

Етап 3. Създаване на работеща база данни

След като DBMS сървърът и 1C:Enterprise са оптимизирани, преминаваме към настройките на базата данни. Ако базата все още не е внедрена от .dt файла и знаете нейния приблизителен размер, тогава е по-добре незабавно да посочите размера за инициализация на основния файл с „>=“ на основния размер, но това е въпрос на вкус, той все още ще расте, когато се разгърне. Но автоматичното увеличаване на размера трябва да бъде посочено: приблизително 200 MB на база данни и 50 MB на журнал, тъй като. стойности по подразбиране - нарастване с 1MB и с 10% забавяне на сървъра много, когато трябва да увеличи файла с всяка 3-та транзакция. Също така е по-добре да посочите съхранението на основния файл и регистрационния файл на различни физически дискове или RAID групи, ако се използват. RAID масиви ограничаване на растежа на журнала. Препоръчително е да преместите Tempdb файла във високоскоростен масив, тъй като СУБД има достъп до него доста често.

Етап 4. Настройване на планирани задачи

Планираните задачи се създават съвсем просто с помощта на плана за поддръжка в раздела за управление, като се използват графични инструменти, така че няма да описваме подробно как се прави това. Нека се спрем на това какви операции трябва да се извършат, за да се подобри производителността.

• Индексите трябва да бъдат дефрагментирани и статистическите данни да се актуализират ежедневно. ако фрагментацията на индекса е > 25%, това ще намали драстично производителността на сървъра.
• Дефрагментиране и актуализиране на статистика - извършва се бързо и не изисква прекъсване на връзката на потребителите. Също така се препоръчва да се прави ежедневно.
• Пълно преиндексиране - извършва се със заключване на база данни, препоръчително е да се прави поне веднъж седмично. Естествено, след пълно преиндексиране, индексите се дефрагментират и статистиката се актуализира незабавно.

Накрая с помощта фина настройкасистема, SQL сървър и работеща база данни, успяхме да подобрим производителността с 46%. Измерванията са извършени с помощта на уреда 1C и с помощта на теста Gilev. Последният показа 25.6 единици срещу 17.53, които бяха първоначално.

Кратко заключение

1. Производителността на 1C не зависи много от честотата на RAM. Когато се достигне достатъчен обем, по-нататъшното разширяване на паметта няма смисъл, тъй като не води до увеличаване на производителността.
2. Производителността на 1C не зависи от видеокартата.
3. Производителността на 1C не зависи от дисковата подсистема, при условие че опашката за четене или запис на дискове не е превишена. Ако е инсталиран SATA устройстваи те не са на опашка, тогава инсталирането на SSD няма да подобри производителността.
4. Производителността е доста зависима от честотата на процесора.
5. При правилна конфигурация на операционната система и MSSQL сървъра е възможно да се постигне увеличение на производителността на 1C с 40-50% без никакви материални разходи.

ВНИМАНИЕ! Много важен момент! Всички измервания бяха извършени на тестова база с помощта на теста Gilev и инструменти за измерване 1C. Поведение на реална база с реални потребителимогат да се различават от получените резултати. Например в тестовата база данни не открихме никаква зависимост на производителността от видеокартата и количеството RAM. Тези заключения са доста съмнителни и в реални условия тези фактори могат да окажат значително влияние върху производителността. Когато работите с конфигурации, които използват управлявани формуляри, графичната карта е важна и мощна. GPUускорява работата по отношение на изчертаването на интерфейса на програмата, визуално това се проявява в повече бърза работа 1C.

Вашият 1C работи ли бавно? Поръчайте ИТ поддръжка на компютри и сървъри от специалисти на EFSOL с дългогодишен опит или прехвърлете своя 1C на мощен и устойчив на грешки 1C виртуален сървър.

Системна интеграция. Консултиране

Често получаваме въпроси за това какво забавя 1s, особено при преминаване към версия 1s 8.3, благодарение на нашите колеги от Interface LLC, ние разказваме подробно:

В предишните ни публикации вече засегнахме влиянието на производителността на дисковата подсистема върху скоростта на 1C, но това проучване се отнасяше за локалното използване на приложението на отделен компютър или терминален сървър. В същото време повечето малки реализации включват работа с файлова база по мрежа, където един от персоналните компютри на потребителя се използва като сървър, или специален файлов сървър, базиран на обикновен, най-често също евтин компютър.

Малко проучване на рускоезични ресурси за 1C показа това този въпросвнимателно заобиколен, в случай на проблеми обикновено се препоръчва да превключите в режим клиент-сървър или терминал. Също така стана почти общоприето, че конфигурациите на управлявано приложение работят много по-бавно от обичайните. По правило аргументите се дават „желязо“: „тук счетоводството 2.0 просто излетя, а„ тройката “едва се движи“, разбира се, има истина в тези думи, така че нека се опитаме да го разберем.

Консумацията на ресурси с един поглед

Преди да започнем това проучване, ние си поставихме две цели: да разберем дали управляваните базирани на приложения конфигурации всъщност са по-бавни от конвенционалните конфигурации и кои ресурси имат най-голямо влияние върху производителността.

За тестване взехме две виртуални машини Windows контрол Server 2012 R2 и Windows 8.1 съответно, което им дава 2 ядра на хост Core i5-4670 и 2 GB RAM, което е приблизително същото като средна офис машина. Сървърът беше поставен на RAID 0 масив от два WD Se, а клиентът беше поставен на подобен масив от дискове с общо предназначение.

Като експериментални бази избрахме няколко конфигурации на Счетоводство 2.0, издание 2.0.64.12 , който след това беше актуализиран до 3.0.38.52 , всички конфигурации бяха стартирани на платформата 8.3.5.1443 .

Първото нещо, което привлича вниманието, е увеличеният размер на информационната база на Тройката, която е нараснала значително, както и много по-големи апетити към RAM:

Вече сме готови да чуем обичайното: „какво добавиха към тази тройка“, но да не избързваме. За разлика от потребителите клиент-сървър, които изискват повече или по-малко квалифициран администратор, потребителите файлови версиирядко мислят за поддържане на бази. Освен това служителите на специализирани фирми, обслужващи (четете - актуализиращи) тези бази, рядко мислят за това.

Междувременно информационната база 1C е пълноценна СУБД от собствен формат, която също изисква поддръжка и за това дори има инструмент, наречен Тестване и коригиране на информационната база. Може би името изигра жестока шега, което изглежда предполага, че това е инструмент за отстраняване на неизправности, но лошата производителност също е проблем, а преструктурирането и повторното индексиране, заедно с компресирането на таблици, са добре познати инструменти за оптимизиране на база данни на всеки администратор на RDBMS. Да проверим?

След прилагане на избраните действия базата данни драстично „загуби тегло“, ставайки дори по-малка от „двете“, които също никой никога не е оптимизирал, а потреблението на RAM също леко намаля.

Впоследствие след зареждане на нови класификатори и директории, създаване на индекси и др. размерът на основата ще расте, като цяло основите на "тройката" са по-големи от базите на "двойката". Това обаче не е по-важно, ако втората версия се задоволяваше с 150-200 MB RAM, тогава новото издание вече се нуждае от половин гигабайт и тази стойност трябва да се вземе предвид при планирането на необходимите ресурси за работа с програмата .

Нет

Мрежовата честотна лента е един от най-важните параметри за мрежови приложения, особено като 1C in файлов режимпреместване на големи количества данни по мрежата. Повечето мрежи на малки предприятия са изградени на базата на евтино оборудване със скорост 100 Mbps, затова започнахме тестване, като сравнихме показателите за производителност на 1C в мрежи със скорост 100 Mbps и 1 Gbps.

Какво се случва, когато стартирате файловата база 1C по мрежата? Клиентът изтегля достатъчно във временни папки голям бройинформация, особено ако това е първият "студен" старт. При 100 Mbps очаквано се натъкваме на честотната лента и изтеглянето може да отнеме значително време, в нашия случай около 40 секунди (цената на разделянето на графиката е 4 секунди).

Второто стартиране е по-бързо, тъй като част от данните се съхраняват в кеша и остават там до рестартирането. Преходът към гигабитова мрежа може значително да ускори зареждането на програмата, както "студена", така и "гореща", и съотношението на стойностите се наблюдава. Затова решихме да изразим резултата в относителни стойности, като най-голямата стойност на всяко измерване се приема за 100%:

Както можете да видите от графиките, Accounting 2.0 зарежда два пъти по-бързо при всяка скорост на мрежата, преходът от 100 Mbps към 1 Gbps ви позволява да ускорите времето за изтегляне четири пъти. В този режим няма разлика между оптимизираните и неоптимизираните бази данни на Тройка.

Ние също така проверихме влиянието на скоростта на мрежата върху тежката работа, например по време на групово повторно хостване. Резултатът също се изразява в относителни стойности:

Тук вече е по-интересно, оптимизираната база на "тройката" в мрежа от 100 Mbit / s работи със същата скорост като "двойката", а неоптимизираната показва два пъти по-лош резултат. На гигабит съотношенията се запазват, неоптимизираната "тройка" също е два пъти по-бавна от "двойката", а оптимизираната изостава с една трета. Също така преходът към 1 Gb / s ви позволява да намалите времето за изпълнение с фактор три за версия 2.0 и два пъти за версия 3.0.

За да оценим влиянието на скоростта на мрежата върху ежедневната работа, използвахме измерване на резултатитечрез извършване на последователност от предварително дефинирани действия във всяка база данни.

Всъщност за ежедневните задачи честотната лента на мрежата не е тясно място, неоптимизираната "тройка" е само с 20% по-бавна от двойката, а след оптимизация се оказва почти същата по-бърза - предимствата на работата в режим на тънък клиент се отразяват. Преходът към 1 Gb / s не дава на оптимизираната база никакви предимства, а неоптимизираната база и двойката започват да работят по-бързо, показвайки малка разлика между тях.

От проведените тестове става ясно, че мрежата не е тясно място за нови конфигурации, а управляваното приложение работи дори по-бързо от обикновено. Можете също така да препоръчате преминаване към 1 Gb/s, ако тежките задачи и скоростта на зареждане на базата данни са критични за вас, в други случаи новите конфигурации ви позволяват да работите ефективно дори в бавни мрежи от 100 Mb/s.

Така че защо 1C се забавя? Ще проучим допълнително.

Сървърна дискова подсистема и SSD

В предишната статия постигнахме увеличение на производителността на 1C чрез поставяне на бази данни на SSD. Може би производителността на дисковата подсистема на сървъра не е достатъчна? Измерихме производителността на дисков сървър по време на групово изпълнение в две бази данни едновременно и получихме доста оптимистичен резултат.

Въпреки сравнително високия брой входно-изходни операции в секунда (IOPS) - 913, дължината на опашката не надвишава 1,84, което е много добър резултат за двудисков масив. Въз основа на това можем да направим предположение, че огледало от обикновени дискове ще бъде достатъчно за нормалната работа на 8-10 мрежови клиента в тежки режими.

И така, необходим ли е SSD на сървър? Най-добрият отговор на този въпрос ще помогне тестването, което проведохме по подобен начин, мрежова връзканавсякъде 1 Gbps, резултатът също се изразява в относителни стойности.

Да започнем със скоростта на зареждане на базата данни.

Може да изглежда изненадващо за някого, но SSD базата на сървъра не влияе на скоростта на изтегляне на базата данни. Основният ограничаващ фактор тук, както беше показано от предишния тест, е пропускателната способност на мрежата и производителността на клиента.

Нека да преминем към повторното окабеляване:

Вече отбелязахме по-горе, че производителността на диска е напълно достатъчна дори за тежка работа, така че скоростта на SSD също не е засегната, с изключение на неоптимизираната база, която настигна оптимизираната на SSD. Всъщност това още веднъж потвърждава, че оптимизационните операции организират информацията в базата данни, намалявайки броя на произволните I/O операции и увеличавайки скоростта на достъп до нея.

При ежедневните задачи картината е подобна:

Само неоптимизираната база получава ползата от SSD. Разбира се, можете да закупите SSD, но би било много по-добре да помислите за навременната поддръжка на базите. Също така не забравяйте да дефрагментирате дяла с информационни базина сървъра.

Клиентска дискова подсистема и SSD

Ние анализирахме влиянието на SSD върху скоростта на локално инсталирания 1C в предишната статия, голяма част от казаното е вярно и за работа в мрежов режим. Всъщност 1C доста активно използва дискови ресурси, включително за фонови и планирани задачи. На фигурата по-долу можете да видите как Accounting 3.0 доста активно осъществява достъп до диска за около 40 секунди след зареждане.

Но в същото време трябва да се знае, че за работна станция, където се извършва активна работа с една или две информационни бази, ресурсите за производителност на конвенционален HDD от масова серия са напълно достатъчни. Закупуването на SSD може да ускори някои процеси, но няма да забележите радикално ускорение в ежедневната работа, тъй като например натоварването ще бъде ограничено пропускателна способностмрежи.

Бавен HDDможе да забави някои операции, но сам по себе си не може да доведе до забавяне на програмата.

RAM

Въпреки факта, че RAM сега е неприлично евтина, много работни станции продължават да работят с количеството памет, което е инсталирано при закупуването им. Тук дебнат първите проблеми. Въз основа на факта, че средната "тройка" изисква около 500 MB памет, можем да предположим, че общото количество RAM от 1 GB за работа с програмата няма да е достатъчно.

Намалихме системната памет до 1 GB и пуснахме две информационни бази.

На пръв поглед всичко не е толкова лошо, програмата е намалила апетитите си и напълно е запазила наличната памет, но нека не забравяме, че нуждата от оперативни данни не се е променила, така че къде са отишли? Изхвърляне на диск, кеш, суап и т.н., същността на тази операция е, че данните, които не са необходими в момента, се изпращат от бърза RAM, чието количество не е достатъчно, за да забави диска.

Накъде води? Нека да видим как се използват системните ресурси при тежки операции, например, нека започнем групово повторно изпълнение в две бази данни едновременно. Първо на система с 2 GB RAM:

Както можете да видите, системата активно използва мрежата за получаване на данни и процесора за обработката им, дисковата активност е незначителна, в процеса на обработка от време на време нараства, но не е ограничаващ фактор.

Сега нека намалим паметта до 1 GB:

Ситуацията се променя радикално, основното натоварване сега пада върху твърдия диск, процесорът и мрежата са бездействащи, чакайки системата да прочете необходимите данни от диска в паметта и да изпрати ненужните данни там.

В същото време дори субективна работа с две открити базина система с 1 GB памет се оказа изключително неудобно, директории и списания се отваряха със значително забавяне и активен достъп до диска. Например отварянето на списание Продажби на стоки и услуги отне около 20 секунди и беше придружено от висока дискова активност през цялото това време (маркирано с червена линия).

За да оценим обективно въздействието на RAM върху производителността на конфигурации, базирани на управлявано приложение, проведохме три измервания: скоростта на зареждане на първата база, скоростта на зареждане на втората база и групово повторно публикуване в една от базите. И двете бази са напълно идентични и създадени чрез копиране на оптимизираната база. Резултатът се изразява в относителни единици.

Резултатът говори сам за себе си, ако времето за зареждане нарасне с около една трета, което все още е доста поносимо, тогава времето за извършване на операции в базата данни нараства три пъти, не е необходимо да се говори за комфортна работа в такива условия. Между другото, това е случаят, когато закупуването на SSD може да подобри ситуацията, но е много по-лесно (и по-евтино) да се справите с причината, а не с последствията, и просто да закупите правилното количество RAM.

Липсата на RAM е основната причина, поради която работата с нови 1C конфигурации е неудобна. Трябва да се имат предвид минимални подходящи конфигурации с 2 GB памет на борда. В същото време имайте предвид, че в нашия случай са създадени "парникови" условия: чиста система, стартирани са само 1C и диспечерът на задачите. В реалния живот браузър, офис пакет, антивирусна програма и т.н. обикновено са отворени на работещ компютър, така че изхождайте от необходимостта от 500 MB на база данни плюс известен марж, така че по време на тежки операции да не се сблъскате с липса на паметта и драстично влошаване на производителността.

процесор

Централният процесор без преувеличение може да се нарече сърцето на компютъра, тъй като той в крайна сметка обработва всички изчисления. За да оценим ролята му, проведохме друг набор от тестове, същият като за RAM, като намалихме броя на ядрата, налични за виртуалната машина, от две на едно, докато тестът беше проведен два пъти с размери на паметта от 1 GB и 2 GB.

Резултатът се оказа доста интересен и неочакван, нещо повече мощен процесордоста ефективно пое товара при липса на ресурси, през останалото време без да дава осезаеми предимства. 1C Enterprise трудно може да се нарече приложение, което активно използва процесорни ресурси, по-скоро неизискващо. И в трудни условия процесорът се натоварва не толкова от изчисляването на данните на самото приложение, а от обслужването на режийни разходи: допълнителни I/O операции и т.н.

заключения

И така, защо 1C се забавя? На първо място, това е липса на RAM, основното натоварване в този случай пада върху твърдия диск и процесора. И ако те не блестят с производителност, както обикновено се случва в офис конфигурациите, тогава получаваме ситуацията, описана в началото на статията - "двойката" работи добре, а "тройката" безсрамно забавя.

Второто място трябва да се даде на мрежовата производителност, бавният 100 Mbps канал може да се превърне в истинско затруднение, но в същото време режимът на тънък клиент е в състояние да поддържа доста удобно ниво на работа дори на бавни канали.

Тогава трябва да обърнете внимание на дисковия, закупуването на SSD едва ли ще бъде добра инвестиция, но замяната на диска с по-модерен няма да е излишна. Разликата между поколенията твърди дисковеможе да се оцени по следния начин: Преглед на два евтини диска от серията Western DigitalСин 500 GB и 1 TB.

И накрая процесора. По-бързият модел, разбира се, няма да бъде излишен, но няма смисъл да се увеличава неговата производителност, освен ако този компютър не се използва за тежки операции: пакетна обработка, тежки отчети, затваряне на месеца и т.н.

Надяваме се, че този материал ще ви помогне бързо да разберете въпроса "защо 1C забавя" и да го разрешите най-ефективно и без допълнителни разходи.

В много отношения оптимизацията на 1C и скоростта на работа зависи от работата с ключалки, заявки и индекси. Ще се опитаме да отговорим на въпроса „как да ускорим работата на 1C“ (въпросът как да ускорим стартирането на 1C, ще разгледаме в друга статия) и да избегнем оплакванията на потребителите относно „дълги документи“, което неизбежно засяга бизнес процеси.

Част 3. Изпълнение 1C

Брави в 1C 8.3: търсене и елиминиране в кода, прехвърляне към управлявани брави

Бравите са част от механизма ACID. Помислете за неговата концепция, представена под формата на опростена диаграма, като използвате примера на SQL SERVER

IN автоматичен режимзаключванията се управляват от самата СУБД. В същото време на MS SQL сървъра се появи следното: странични ефекти, като заключване на празни таблици и граничен диапазон от данни (Serializable ниво), което създаде допълнителни проблемипри работа с много потребители. За да разреши тези проблеми, 1C създаде управлявани ключалки.

1C Управлявани брави

Заключващият механизъм беше преместен на сървъра 1C, а на ниво СУБД изолацията беше намалена до минимум. В MS SQL нивото на изолация беше понижено до Read Committed със споделения механизъм за заключване на платформата 8.2 и механизма за редове на версиите на платформата 8.3 (т.нар. Read Committed Snapshot Isolation). По-точно, това е едноименното свойство на базата данни и два режима на работа Read Committed, в зависимост от този параметър.

При последно нивоизолация (RCSI), механизмът позволява да не се пресичат транзакциите за четене и запис на сървъра на DBMS на едни и същи ресурси. Цялата основна работа беше поета от услугата за блокиране на 1C, която определя, въз основа на собствени метаданни, дали да стартира или не транзакции на DBMS сървъра, така че да няма нарушения на бизнес логиката. Проблемите с блокирането на празни таблици и гранични диапазони са нещо от миналото.

СУБД	Тип блокиране	Ниво на изолация на транзакция	Четене извън транзакция
Автоматични брави
Файлова база данни	маси	Може да се сериализира	Мръсно четиво
MS SQL сървър	Вписвания		Мръсно четиво
IBM DB2	Вписвания	Повторно четене или сериализиране	Мръсно четиво
PostgreSQL	маси	Може да се сериализира	Последователно четене
База данни на Oracle	маси	Може да се сериализира	Последователно четене
Управлявани ключалки
Файлова база данни	маси	Може да се сериализира	Мръсно четиво
MS SQL Server 2000	Вписвания	Прочетете ангажирани	Мръсно четиво
MS SQL Server 2005 и по-нова версия		Прочетете ангажираната моментна снимка	Последователно четене
IBM DB2 до версия 9.7	Вписвания	Прочетете ангажирани	Мръсно четиво
IBM DB2 версия 9.7 и по-нова	Вписвания	Прочетете ангажирани	Последователно четене
PostgreSQL	Вписвания	Прочетете ангажирани	Последователно четене
База данни на Oracle	Вписвания	Прочетете ангажирани	Последователно четене

За да разберете в какъв режим на заключване е базата данни на програмата 1C, трябва да изпълните следната заявка от SSMS в контекста на желаната база данни:

Блокиране на 1C. Потребителят няма да чака ключалки, 1C ще бъде ускорен, ако се спазват определени правила:

• Продължителността на транзакциите трябва да бъде възможно най-кратка във времето. Извършването на дълги изчисления в транзакция в 100% от случаите ще доведе до блокиране при работа на OLTP система.
• Изключени са дългосрочни външни операции в рамките на транзакцията, например изпращане и получаване на потвърждения на електронна поща, работи с файлова системаи други допълнителни стъпки. Всички операции трябва да бъдат поставени в чакащи кратки задачи.
• Заявките са максимално оптимизирани.
• Индексите трябва да се създават само при необходимост, за да се осигури оптимална производителност на заявките в приложението.
• Минимизирани включвания в групирания индекс на често актуализирани колони. Актуализирането на колона/и на ключ на клъстериран индекс изисква заключване, както на клъстерирания индекс, така и на всички неклъстерирани индекси (тъй като техният ред за локатор съдържа ключа на клъстерен индекс).
• Когато е възможно, се създава покриващ индекс и се използва за намаляване на времето за извличане на данни.
• Използването на най-ниското ниво на изолация от транзакции, което ще изисква преход към управляван режим на заключване.

Инструменти за диагностика на блока:

• Технологичен вестник;
• Център за управление на производителността от инструментариума 1C;
• Облачни услуги на Гилев;

По-долу е даден пример за мониторинг на системата от услугата Gilev. Общата продължителност на блокирането е ~15 часа. Над 400 активни потребители. След вземане на решение и оптимизиране, времето за изчакване е по-малко от минута, а броят на блоковете е намален с ~670 пъти.

Беше:

Стана:

В ситуация, в която „всичко виси и отнема много време“, а услугите за мониторинг не са конфигурирани или изобщо не се използват, като си спомняте принципа на Парето, трябва да се съсредоточите върху кода.

В автоматичен режим наличието на ключалки на сървъра може да бъде открито чрез системна процедура в контекста на необходимата база данни. Тази съхранена процедура ви позволява да определите режима, в който работят ключалките, техния статус, тип и т.н.:

След като завършите процедурата за 1C, можете да получите визуална информация за това, което се случва в момента на сървъра, като вземете предвид спецификата на таблиците 1C:

Фрагмент 1

//Заключва по отношение на 1C SELECT * FROM dbo.ReturnLockName1C(DEFAULT,DEFAULT) as t Където TableName1C НЕ Е NULL ORDER BY t.Resource

Използването на този механизъм дава възможност за получаване пълна информацияза наличните в момента ключалки. Ако в отчета има само S-заключвания, проблемът може да е дълготрайна заявка или заявки. За да определите причината и мястото на тяхното появяване в кода, можете да отидете по различни начини: използвайте DMO обекти на SQL сървър (но имайте предвид, че данните от тях се нулират след рестартиране на сървъра) или конфигурирайте Data Collector, като запазите наблюдение на данни в таблици за определено време. Основното нещо е да получите текстовете на заявките за проблеми.

Използване на SQL Server DMO

Ние показваме началната дата на сървъра, за да разберем уместността на данните. Разбиваме пакета чрез четене на рейтинг (физически, логически, натоварване на процесора). В този случай се използват основните данни от sys.dm_exec_query_stats. Текстът на заявката се превежда в термините на 1C. Ако можете да разберете контекста на повикването от текста на заявката, тогава остава да разгледате плана на заявката, да намерите проблемни оператори и да разберете какво може да се направи.

Фрагмент 2

//начален час ИЗБЕРЕТЕ sqlserver_start_time ОТ sys.dm_os_sys_info; //Най-популярни заявки за физически четения ИЗБЕРЕТЕ ТОП (50) (total_physical_reads) AS Total_physical_reads,

Идентифициране на проблемни заявки в резултат на събиране на данни

С този инструмент можете да класирате данните според необходимите параметри, като използване на процесора, продължителност, логически I/O, физически четения, което ви позволява да запазите пълна статистика за допълнителен анализ, въпреки рестартирането на SQL сървъра.

След като проблемните заявки бъдат събрани от сървъра без мониторинг от трета страна, можете да класирате получените данни според необходимите параметри.

Освен това, като включите технологичния дневник и посочите в настройките „търсене по низ“ и частта от заявката, която гарантирано ще се появи, можете да разберете откъде идва проблемната заявка. Ако има няколко бази данни на сървъра или потребителското име е известно, струва си да добавите допълнителни полетаза филтъра за намаляване на натоварването на сървъра при събиране на технологичния дневник.

Пример за проблемна заявка и пример за настройка на технологичен дневник:

Оптимизацията на заявките като възможност за ускоряване на 1C 8.3

Последствията от неоптималните заявки могат да се проявят под формата на продължително публикуване на документи, непоносимо дълго генериране на отчети, замръзване на системата и други неприятни събития.

Когато работите със заявки, НЕ:

• Обединяване на таблици с подзаявки;
• Свържете обикновени маси с виртуални;
• Използвайте логическо "ИЛИ" в условия;
• Използвайте подзаявки в условия на присъединяване;
• Вземете данни чрез точка от полета композитен типбез ключова дума"Експрес".

Когато работите със заявки, МОЖЕТЕ:

• Създаване на индекси на условия на заявка, съединяване, агрегиране и полета за сортиране;
• филтриране виртуални маситрябва да се направи с помощта на параметри за избор.

Използването на индекси и тяхното влияние върху качеството на работата на системата

Много е писано за индексите, за необходимостта от използването им и влиянието върху качеството на системата. Нека се опитаме да разберем тънкостите на "устройството" на индекси, приложения и предимства пред конвенционалните таблици.

Индексирането е важна част от ядрото на СУБД. Липсващи индекси или обратното, прекомерният им брой, влияят върху честотата на дискретизация, модифициране, добавяне и изтриване на данни.Нека разгледаме индексирането, използвайки примера на най-често срещаната СУБД от Microsoft.

За общо разбиране как работи това, нека разгледаме подробностите за устройството чрез механизма за съхранение на данни, който обикновено представяме под формата на таблица (например Excel).

Единицата за физическо съхранение на данни е страница - модул от 8 KB, който принадлежи само на един обект (например таблица или индекс). Страницата е най-малката единица за четене и писане. Страниците са организирани в екстенти. Обемът се състои от 8 последователни страници. Страниците с разширение могат да бъдат собственост на един или повече обекти. Ако страниците принадлежат към повече от една функция, екстентът се нарича "смесен" екстент.

Съдържанието му може да видите по-долу:

Сега, след като имаме представа как е организирана дисковата единица за съхранение, нека поговорим повече за таблиците и индексите.

По подразбиране, ако не използвате специални T-SQL изрази, празна таблица се създава като "купчина" - прост набор от страници и екстенти.Данните в купчината нямат логичен ред. Ядрото на SQL Server следи как страниците и екстентите принадлежат към определен обект, използвайки специални системни страници, наречени карти за разпределение на индекси. Всяка таблица или индекс има поне една IAM страница, наречена "първата IAM страница".

Така след създаване на редовна таблица по подразбиране се получава хаотично подреждане на данните. Можете да видите състоянието на таблица, като използвате следната процедура:

Основните индекси, използвани от платформата 1C

Фрагмент 3

Митове и реалност:

Мит първи: клъстерираните индекси и таблица с данни са две различни единици, съхранявани отделно една от друга.

Мит втори: може да има много групирани индекси в една таблица.

Изтеглих програмата за оптимизация на СУБД. Създадени препоръчителни индекси. Скоростта на вземане на проби е увеличена с 50%. Промяната и добавянето на данни се забави 7 пъти.

Клъстериран (групиран) индекс

Клъстерираните индекси са набор от страници, които сортират и съхраняват редове от данни в таблици или изгледи въз основа на техните ключови стойности, колоните, включени в дефиницията на индекса. Има ограничение за този видиндекси в 16 колони и 900 байта. За всяка маса има само един групиран индекс,тъй като редовете с данни могат да бъдат сортирани само в един ред. Създаването на клъстерен индекс става чрез реорганизиране на таблицата, вместо чрез копиране на данните, което прави възможно запазването на таблицата като B-дърво.

Фрагмент 4

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

Неклъстъриран индекс

Неклъстерните индекси имат отделна структура от редовете с данни. Неклъстерният индекс съдържа стойностите на ключа на клъстерирания индекс и всеки запис съдържа ключа на клъстерирания индекс (не RID, тъй като 1C таблиците не използват купчини, с редки изключения).

Можете да добавите неключови колони към листовото ниво на неклъстъриран индекс и да заобиколите съществуващото ограничение за индексни ключове (900 байта и 16 ключови колони), като изпълните напълно индексирани заявки.

След добавяне на неклъстъриран индекс, данните бяха копирани и се появи друг обект:

Фрагмент 5

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

Схема на клъстерирания индекс след получаването му от купчината под формата на балансирано дърво:

Схема на неклъстериран индекс, получен от клъстерирана таблица (обърнете внимание, че колоната за локатор на ред има ключ за клъстерен индекс):

Влияние на индексите върху производителността на заявките

Оптимизаторът на заявки използва индекса, за да търси в ключовите колони на индекса, намира къде се съхраняват заявените редове и извлича съвпадащи редове от там. Търсенето в индекс е много по-бързо от търсенето в таблица, защото за разлика от таблица, индексът често съдържа по-малко колони на ред и редовете са сортирани по ред.

Създаването на много индекси води до факта, че скоростта на извличане се увеличава, а скоростта на запис по време на модификация намалява значително. За да разрешите този проблем, първо трябва да премахнете ненужните индекси или да ги блокирате, без да ги изтривате първо, което ще ви позволи просто да ги активирате, ако възникне такава необходимост.

Имайте предвид, че клъстерираният индекс никога не трябва да бъде блокиран, защото това ще затвори достъпа до данните от таблицата. Това се отнася само за индекси, които сте създали сами чрез T-SQL. Причината за създаване на индекси с помощта на T-SQL, заобикаляйки 1C:Enterprise, се дължи главно на ограничените възможности на платформата 1C по отношение на манипулиране на индекси и включване на допълнителни полета в създадения/внедрения индекс.

T-SQL оператор, който изпълнява действието за заключване на индекса:

//Заключване на единичен индекс в таблицата -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 DISABLE; //Включете желания индекс -ALTER INDEX _Reference22_ByPredefinedIDNotUniq ON _Reference22 REBUILD;

В допълнение към горните действия е важно да създадете файлова група на физически диск, който не съдържа текущи файловебази данни и преместване на неклъстерирани индекси там. Това ще ускори модифицирането на данните чрез паралелизиране на записа им.

Дефиниране на задължителни или излишни индекси за ускоряване на изпълнението на заявката

По подразбиране 1C създава специфичен основен комплектиндекси. Често те просто не са достатъчни. SQL Server има механизми, които позволяват да се разбере, въз основа на натоварването, колко необходими са съществуващите индекси.

Database Engine Tuning Advisor анализира бази данни и прави препоръки за оптимизиране на производителността на заявките. Може да се използва за избор и създаване на оптимални набори от индекси, без да имате експертно ниво на разбиране на структурата на базата данни или вътрешните процеси на SQL Server. Съветникът за настройка на Database Engine ви позволява да изпълнявате следните задачи:

• Отстраняване на проблеми с производителността на конкретна проблемна заявка;
• Настройване на голям набор от заявки към една или повече бази данни.

DMO (обекти за динамично управление), които включват динамични изгледи за управление и функции за динамично управление. Например, T-SQL изразможете да получите всички индекси, които не са били използвани от последното стартиране на сървъра.

Фрагмент 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 И I.type_desc = "NONCLUSTERED" И I.index_id НЕ В (ИЗБЕРЕТЕ S.index_id ОТ sys.dm_db_index_usage_stats AS S WHERE S.object_id=I.object_id И I.index_id=S.index_id И database_id = DB_ID("Database_id '))) SELECT име на обект,T1.NameTable1C, indexid, indexname FROM vl OUTER APPLY dbo.ReturnTableName1C(име на обект) като T1 ORDER BY име на обект, име на индекс;

Инструкция, с която можете да създадете необходимите индекси, препоръчани от DBMS двигателя:

Фрагмент 7

ИЗБЕРЕТЕ T1.NameTable1C като Table_Name_1C, "CREATE INDEX" + "ON"
Оптимизаторът на заявките открива необходимостта от създаване на липсващ индекс по време на генерирането на план за изпълнение на заявки. Той запазва тази информация в XML ShowPlan. защото Ако плановете за заявки са хеширани и инструкциите продължават (до следващото рестартиране на сървъра), те могат да бъдат извлечени, обработени и готови инструкции за създаване на необходимите индекси за всеки план за изпълнение в кеша. Струва си да се обърне внимание на честотата на изпълнение на заявката: колкото по-висока е тя, толкова по-релевантни са резултатите от изпълнението на заявката и съответно събраните индикатори. Ако заявката е била изпълнена веднъж, резултатите от нея не са толкова показателни.

Фрагмент 8

CROSS APPLY query_plan.nodes('//StmtSimple") AS stmt(stmt_xml) WHERE stmt_xml.exist("QueryPlan/MissingIndexes") = 1) ИЗБЕРЕТЕ ТОП 30 DatabaseName като DatabaseName, TableName като Table_Name, T1.NameTable1C като Table_1CName, равенство _колони като сравняване на колони, включване на колони като колони_за_включване,

Фрагмент 9

ИЗПОЛЗВАЙТЕ [Име на база данни] СЪЗДАЙТЕ НЕКЛУСТЕРИРАН ИНДЕКС НА .[_Document497] ([_Fld12771_TYPE],[_Fld12771_RTRef]) ВКЛЮЧЕТЕ ([_Date_Time],[_Fld12771_RRRef],[_Fld12782RRef],[_Fld12784]) КЪРНЕТЕ Някои характеристики на индексиране чрез обобщени полета и полета за сортиране.

Създаването на индекс върху колоните, посочени в клаузата ORDER BY, помага на оптимизатора на заявки бързо да организира набора от резултати, тъй като стойностите на колоните са предварително сортирани в индекса. Вътрешното внедряване на механизма GROUP BY също сортира първо стойностите на колоните, за да групира бързо необходимите данни.

Когато използвате типични препоръки, струва си да проверите резултата преди и след оптимизацията. Ето пример за използване логическа асоциация„OR“ и неговите алтернативи (за отстраняване на проблема със стандартни препоръки) са техники за промяна на заявка чрез синтаксиса „JOIN ALL“.

Самата заявка 1C с "ИЛИ":

ИЗБЕРЕТЕ код, име, връзка ОТ Directory.Contractors AS Contractors WHERE Contractors.Code = "000000004" ИЛИ Contractors.Code = "0074853" ИЛИ Contractors.Code = "000000024" ИЛИ Contractors.Code = "009679294" ИЛИ Contractors.Code = " 0074742" ИЛИ Изпълнители. Код = "000000104";

Модифициране на заявка с „JOIN ALL“:

ИЗБЕРЕТЕ код, име, връзка ОТ Directory.Counterparties AS Counterparties WHERE Counterparties.Code = "000000004" CONNECT ALL SELECT Code, Name, Link FROM Directory.Counterparties AS Counterparties WHERE Counterparties.Code = "0074853" COMBINE ALL SELECT Код, име, връзка FROM Directory.Counterparties AS Counterparties WHERE Counterparties.Code = "000000024" UNITE ALL SELECT Код, име, връзка FROM Directory.Counterparties AS Counterparties WHERE

Действителен план за заявка (за улеснение на показването и сравнение на производителността, заявките се прихващат и изпълняват в SSMS):

В този случай, след оптимизация, производителността спадна наполовина поради многократното използване на оператора Key Lookup, който винаги е последван от оператора Nested Loops. Следователно, използвайки схема за оптимизиране на заявки, трябва да измервате целевото време преди и след използване на подобрения. Този примерпоказани с цел „доверете се, но проверете“, тъй като може да има несъответствие между препоръките на модела и практическите задачи.