За да разбера реалното натоварване на оборудването, беше необходимо да тествам производителността на 1C терминален сървър в производството, което направих съвсем наскоро и сега искам да представя резултатите, за да могат всички да ги видят.
Прочетете повече в статията.
Ще намерите други статии за 1C в съответния раздел -.
В няколко предишни статии за 1C работих върху изчисляването на сървърни конфигурации за различни натоварвания, генерирани от усилията на основните потребители на 1C, а именно служители на счетоводните и търговските отдели. Задачите на счетоводителите зависят не само от изготвянето на отчети и въвеждането на данни в програмата и затова е по-предпочитано те да имат пълен терминален достъп и да работят с всичко необходимо оттам (). За мениджърите всичко е много по-просто и за тях публикуването на приложение () е напълно приемлив случай на употреба.
Не рискувах да пусна сървъра в производство, без да провеждам реално тестване, така че беше организирано широкомащабно тестване. Предимството му за мен лично беше, че можех да потвърдя (или опровергая) на практика моите теоретични изчисления, чиято основа бяха много субективни показатели за ефективност на работните станции на служителите.
Тестова среда
И така, за тестване взехме сървър с процесор Intel Xeon E5-1650 v3 @ 3,50 GHz, 128 GB RAM, 2*SSD в RAID 1. На този сървър е разположена виртуална машина, която е само терминален сървър, с инсталирани приложения 1C 8.2, 1C 8.3, MS Office 2013 Pro.
Веднага ще кажа, че естеството на натоварването беше смесено, тоест имаше клиенти, работещи чрез RemoteApp, и имаше такива, които влязоха изцяло чрез RDP и използваха програмите, необходими за тяхната работа (не само 1C, но и Office ). Разпределението беше приблизително както следва: 24 RemoteApp сесии, 5 RDP клиента.
Потребителите бяха изправени пред задачата да влизат в приложения на всеки 30 минути в продължение на два часа и да изпълняват ежедневни задачи в тях - създаване на отчети, отпечатване на данни, публикуване на документи, експортиране на данни в други формати и т.н. Основното е, че нямаше цел да поставите сървъра целта беше да се даде реално средно дневно натоварване.
Резултати от теста
Всичко започна както обикновено - потребителите от третото натискане, вече от ръководители на отдели и по-горе, започнаха да влизат в 1C и да изпълняват рутинни задачи. Всичко това не продължи дълго и имах само един шанс да взема показателите за производителност на сървъра възможно най-близо до реалното натоварване. Ето какво получих в крайна сметка:
RAM (динамично разпределената памет беше зададена на виртуалния сървър, така че ако е необходимо, текущото количество RAM постоянно се променяше нагоре):
Сега е необходимо да се анализират резултатите и да се направят изводи.
Анализ на данни
Трябва да се отбележи, че изчисленията за процесора се оказаха изключително точни.
В статията емпирично установих, че потреблението на процесорен ресурс на една сесия на 1C RemoteApp е средно 122 775 процесорни единици за производителност (данните за производителността са взети от уебсайта www.cpubenchmark.net). В друга статия изчислих ресурсите, необходими за стартиране на пълна RDP сесия и те възлизат на 4% от Core i5 4460, тоест 0,04 * 6622 (данните също са с www.cpubenchmark.net) = 264,88.
Общо получаваме:
- пълна RDP сесия изяжда 264,88 единици за производителност на процесора;
- сесия 1C RemoteApp консумира 122,775 единици.
Най-отгоре споменах, че има 24 потребители на RemoteApp и 5 RDP. Ние броим:
24 * 122,775 + 5 * 264,88 = 4271
Относителният индекс на производителност на Intel Xeon E5-1650 v3 е 13477 единици. Тоест теоретично Натоварването на процесора трябва да бъде около 32% (4271 / 13477 * 100).
Графиката на натоварване на процесора показва, че във времевия интервал 10:30 - 10:50 процесорът се натоварва с 25 - 40% (пиковете не се броят). Разбира се, няма да получите права линия на натоварване на процесора от 32%; все още ще има колебания от минимуми до относителни максимуми, но като цяло можем да приемем, че реалните данни са в съответствие с теоретичните. Между другото, колкото повече потребители има на вашия сървър, толкова по-равномерно ще бъде натоварването.
Всъщност данните от RAM се оказаха по-ценни. Според изчисленията от предишни статии имах:
- 2GB на RDP сесия;
- 100 MB на сесия на RemoteApp.
Тоест обемът на заетата памет трябваше да е максимум 12,4 GB + малко за ОС. Но, както се оказа и аз по принцип имах предчувствие, тази стойност на практика беше съвсем друга цифра. 1C се оказа много алчен за RAM, за мое съжаление. Освен това приложението се държи по такъв начин, че след като е заело място, не смята за необходимо да го освободи в момента, в който вече не е необходимо:
Е, нормално ли е да изяде 2GB RAM и да седи и да не прави нищо (натоварването на процесора на сесията е 0%). Съвременните програмисти изобщо не се интересуват от оптималното използване на ресурсите. Лично аз, когато учех в университет, бях принуден да пренапиша кода на приложението, ако беше написан нерационално по отношение на използването на изчислителни ресурси. Явно квалификацията на съвременните програмисти е паднала под цокъла или може би това е просто подход - защо да оптимизираме вече написан код, когато е по-добре да разработваме нова функционалност. Като цяло не е важното, бомбардира и това е добре.
От 16 GB „говорители“, разпределени на сървъра, той ги изяде всички и най-вероятно поиска повече. На теория, ако няма достатъчно RAM, операционната система ще се смени на диска и в този случай започва сериозен спад в производителността. В моя случай това не беше така и най-вероятно това се дължи на SSD, който практически не показа никакво натоварване - само два краткотрайни пика през целия тестов период (от 10:00 до 12:00). Въпреки това, както показва практиката, не препоръчвам да спестявате RAM на терминалния сървър.
Снимка на Алена Тулякова, информационна агенция „Клерк.Ру“
Статията идентифицира основните грешки, които начинаещите администратори на 1C допускат, и показва как да ги разрешат, използвайки теста Gilev като пример.
Основната цел на написването на тази статия е да се избегне повтарянето на очевидни нюанси за онези администратори (и програмисти), които все още не са натрупали опит с 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 i3s с високи честоти числата 70-80 са доста реалистични.
Най-честите грешки на този етап.
- Неправилно конфигурирана антивирусна програма. Има много антивируси, настройките за всяка са различни, ще кажа само, че при правилна конфигурация нито мрежата, нито Kaspersky 1C се намесват. С настройките по подразбиране могат да бъдат отведени приблизително 3-5 папагала (10-15%).
- Режим на изпълнение. По някаква причина малко хора обръщат внимание на това, но ефектът е най-значимият. Ако имате нужда от скорост, тогава трябва да направите това, както на клиентски, така и на сървърни компютри. (Гилев има добро описание. Единственото предупреждение е, че на някои дъна, ако изключите Intel SpeedStep, не можете да включите TurboBoost).
Можете (и за предпочитане) да активирате режим на производителност на две места:
- чрез BIOS. Деактивирайте режимите C1, C1E, Intel C-state (C2, C3, C4). В различните биоси те се наричат по различен начин, но значението е едно и също. Търсенето отнема много време, изисква се рестартиране, но ако го направите веднъж, можете да го забравите. Ако направите всичко правилно в BIOS, скоростта ще се увеличи. На някои дънни платки можете да конфигурирате настройките на BIOS, така че режимът на производителност на Windows да не играе роля. (Примери за настройки на BIOS от Гилев). Тези настройки се отнасят главно до сървърни процесори или „разширен“ BIOS, ако не сте намерили това и НЯМАТЕ Xeon, всичко е наред.
- Контролен панел - Захранване - Висока производителност. Минус - ако компютърът не е бил обслужван дълго време, ще издава по-силен шум от вентилатора, ще загрява повече и ще консумира повече енергия. Това е такса за изпълнение.
| Това са настройките по подразбиране. Активирано C-състояние на BIOS, режим на балансирана консумация на енергия |  |
| Активирано C-състояние на BIOS, режим на висока производителност За Pentium и Core можете да спрете дотук, Все още можете да изстискате малко "папагали" от Xeon |  |
| В BIOS C-състоянието е деактивирано, режим на висока производителност. Ако не използвате Turbo boost, ето как трябва да изглежда сървър, настроен за производителност |  |
А сега числата. Да напомня: Intel Xeon 5650, рамдиск. В първия случай тестът показва 23,26, в последния - 49,5. Разликата е почти двойна. Числата може да варират, но съотношението остава по същество същото за Intel Core.
Уважаеми администратори, можете да критикувате 1C колкото искате, но ако крайните потребители се нуждаят от скорост, трябва да активирате режима с висока производителност.
в) Turbo Boost. Първо трябва да разберете дали вашият процесор поддържа тази функция, например. Ако поддържа, тогава все още можете съвсем законно да получите известна производителност. (Не искам да засягам проблемите с честотния овърклок, особено сървърите, направете го на свой риск и риск. Но съм съгласен, че увеличаването на скоростта на шината от 133 на 166 дава много забележимо увеличение както на скоростта, така и на разсейването на топлината)
Как да включите турбоусилване е написано например . Но! За 1C има някои нюанси (не най-очевидните). Трудността е, че максималният ефект от турбо усилване се получава, когато C-state е включен. И получаваме нещо подобно:
Моля, обърнете внимание, че множителят е максимален, скоростта на ядрото е красива и производителността е висока. Но какво ще се случи в резултат на 1s?
Но в крайна сметка се оказва, че според тестовете за производителност на процесора изпреварва версията с множител 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 Gbit мрежа ще бъде средната скорост на копиране от 100 MB/sec, добра работа - 120 MB/sec. Бих искал да обърна внимание на факта, че слабото място (включително) може да бъде натоварването на процесора. SMB протоколът на Linux е доста слабо паралелизиран и по време на работа може доста лесно да „изяде“ едно процесорно ядро и да не консумира повече.
И още нещо. С настройките по подразбиране клиентът на windows работи най-добре с сървър на windows (или дори работна станция на windows) и протокола SMB/CIFS, клиент на linux (debian, ubuntu не погледна другите) работи по-добре с linux и NFS ( работи и с SMB, но на NFS папагалите са по-високи). Фактът, че по време на линейно копиране Windows Linux сървър към NFS се копира в един поток по-бързо, не означава нищо. Настройката на Debian за 1C е тема за отделна статия, все още не съм готов за това, въпреки че мога да кажа, че във файловата версия получих дори малко по-добра производителност от версията Win на същото оборудване, но с postgres с над 50 потребители Все още имам всичко много лошо.
Най-важното нещо, което „изгорелите“ администратори знаят, но начинаещите не вземат предвид. Има много начини да зададете пътя до базата данни 1c. Можете да направите servershare, можете да направите 192.168.0.1share, можете да използвате net z: 192.168.0.1share (и в някои случаи този метод също ще работи, но не винаги) и след това да посочите устройство Z. Изглежда, че всички тези пътища посочете едно и също нещо на същото място, но за 1C има само един метод, който осигурява нормална производителност доста надеждно. И така, това е, което трябва да направите правилно:
На командния ред (или в политиките, или както ви е удобно) - направете net use DriveLetter: servershare. Пример: net use m: сървърни бази. Особено подчертавам НЕ IP адреса, а името на сървъра. Ако името на сървъра не се вижда, добавете го към dns на сървъра или локално към файла hosts. Но адресът трябва да е по име. Съответно, по пътя към базата данни, достъп до този диск (вижте снимката).
А сега ще покажа с цифри защо е такъв съветът. Първоначални данни: Intel X520-DA2, Intel 362, Intel 350, Realtek 8169 карти OS 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. Не давам всички числа, а само най-интересните, за да имате с какво да сравнявате.
| 100 Mbit CIFS Win 2008 - Win 2008 контакт чрез ip адрес | 100 Mbit CIFS Win 2008 - Win 2008 викане по име | 1 Gbit CIFS Win 2008 - Win 2008 контакт чрез ip адрес | 1 Gbit CIFS Win 2008 - Win 2008 викане по име | 1 Gbit CIFS Win 2008 - Win 7 викане по име | 1 Gbit CIFS Win 2008 - Debian викане по име | 10 Gbit CIFS Win 2008 - Win 2008 контакт чрез ip адрес | 10 Gbit CIFS Win 2008 - Win 2008 викане по име |
|
| 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 |
Изводи (от таблицата и от личен опит. Отнася се само за файловата версия):
- През мрежата можете да получите съвсем нормални номера за работа, ако тази мрежа е правилно конфигурирана и пътят е въведен правилно в 1C. Дори първият Core i3 може спокойно да произведе 40+ папагала, което е доста добре и това не са само папагали, но и при реална работа разликата е осезаема. Но! Ограничението при работа с няколко (повече от 10) потребители вече няма да е мрежата, тук 1 Gbit все още е достатъчен, но блокиране при работа с много потребители (Гилев).
- платформата 1C 8.3 е многократно по-взискателна по отношение на правилната мрежова конфигурация. Основни настройки - виж Гилев, но имай предвид, че всичко може да се влияе. Видях ускорение от деинсталиране (а не само изключване) на антивирусната програма, от премахване на протоколи като FCoE, от смяна на драйвери към по-стара, но сертифицирана от Microsoft версия (особено за евтини карти като ASUS и DLC), от премахване на втората мрежова карта от сървъра. Има много опции, конфигурирайте мрежата си внимателно. Възможно е да има ситуация, при която платформа 8.2 дава приемливи числа, а 8.3 - два или дори повече пъти по-малко. Опитайте да играете с платформа версии 8.3, понякога получавате много голям ефект.
- 1C 8.3.6.2076 (може би по-късно, все още не съм търсил точната версия) все още е по-лесно да се конфигурира по мрежата от 8.3.7.2008. Успях да постигна нормална работа по мрежата от 8.3.2008 г. (в сравними папагали) само няколко пъти; не можах да го повторя за по-общ случай. Не разбрах много, но съдейки по обвивките на краката от Process Explorer, записът там не е толкова добър, колкото в 8.3.6.
- Въпреки факта, че когато работите в мрежа от 100 Mbit, нейният график на натоварване е малък (можем да кажем, че мрежата е безплатна), скоростта на работа все още е много по-малка, отколкото при 1 Gbit. Причината е латентността на мрежата.
- При равни други условия (добре работеща мрежа) за 1C 8.2 връзката Intel-Realtek е с 10% по-бавна от Intel-Intel. Но realtek-realtek обикновено може да даде рязко слягане изневиделица. Ето защо, ако имате пари, по-добре дръжте мрежовите карти на Intel навсякъде; ако нямате пари, инсталирайте Intel само на сървъра (вашата CO). И има много пъти повече инструкции за настройка на мрежови карти на Intel.
- Антивирусните настройки по подразбиране (използвайки drweb версия 10 като пример) заемат около 8-10% от папагалите. Ако го конфигурирате както трябва (позволете на процеса 1cv8 да прави всичко, въпреки че не е безопасно), скоростта е същата като без антивирусна.
- НЕ четете Linux гурута. Сървър със samba е страхотен и безплатен, но ако инсталирате Win XP или Win7 (или дори по-добре - сървърна ОС) на сървъра, тогава файловата версия на 1c ще работи по-бързо. Да, samba и протоколният стек и мрежовите настройки и много, много други могат да бъдат добре настроени в debian/ubuntu, но това се препоръчва за специалисти. Няма смисъл да инсталирате Linux с настройки по подразбиране и след това да казвате, че е бавен.
- Доста добра идея е да проверите работата на дискове, свързани чрез net use с помощта на fio. Поне ще стане ясно дали това са проблеми с платформата 1C или с мрежата/диска.
- За версията за един потребител не мога да се сетя за тестове (или ситуация), при които разликата между 1 Gbit и 10 Gbit би била видима. Единственото нещо, при което 10Gbit за файловата версия дава по-добри резултати е свързването на дискове през iSCSI, но това е тема за отделна статия. Все пак мисля, че за файловата версия 1 Gbit карти са достатъчни.
- Не разбирам защо при 100 Mbit мрежа 8.3 работи значително по-бързо от 8.2, но беше факт. Цялото друго оборудване, всички други настройки са абсолютно еднакви, просто в единия случай се тества 8.2, а в другия - 8.3.
- Ненастроен NFS win-win или win-lin дава 6 папагала, не съм ги включил в таблицата. След настройка получих 25, но беше нестабилен (разликата в измерванията беше повече от 2 единици). Все още не мога да дам препоръки относно използването на Windows и NFS протокола.
Терминален сървър. (базата данни е на сървъра, клиентите се свързват през мрежата, RDP протокол). Алгоритъм стъпка по стъпка:
- Добавяме тестовата база данни на Gilev към сървъра в същата папка като основните бази данни. Свързваме се от същия сървър и провеждаме теста. Помним резултата.
- Точно по същия начин, както във файловата версия, ние конфигурираме процесора. В случай на терминален сървър, процесорът обикновено играе основна роля (предполага се, че няма очевидни слаби места, като липса на памет или огромно количество ненужен софтуер).
- Конфигурирането на мрежови карти в случай на терминален сървър практически няма ефект върху работата на 1c. За да осигурите „специален“ комфорт, ако вашият сървър произвежда повече от 50 папагала, можете да играете с нови версии на протокола RDP, само за удобство на потребителите, по-бърз отговор и превъртане.
- Когато активно работят голям брой потребители (а тук вече можете да опитате да свържете 30 души към една база данни, ако опитате), е много препоръчително да инсталирате SSD устройство. По някаква причина се смята, че дискът не влияе особено на работата на 1C, но всички тестове се извършват с активиран за писане кеш на контролера, което е неправилно. Тестовата база данни е малка, тя се побира доста добре в кеша, оттук и високите числа. В реални (големи) бази данни всичко ще бъде напълно различно, така че кешът е деактивиран за тестове.
| 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 | |
| 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 |
- Активираният кеш на RAID контролера елиминира всички разлики между дисковете; числата са еднакви както за sat, така и за cas. Тестването с него върху малко количество данни е безполезно и не е показателно за никакъв вид.
- За платформа 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).
- Основните предимства на терминалния сървър са, че може да има много слаби клиенти и мрежовите настройки влияят много по-малко на терминалния сървър (отново вашият K.O.).
Ако тестът на Gilev показва малки числа и имате процесор с висок такт и бързи дискове, тогава администраторът трябва да вземе поне perfmon, да запише всички резултати някъде и да гледа, наблюдава и прави изводи. Няма да има окончателен съвет.
Опция клиент-сървър.
Тестовете бяха проведени само на 8.2, т.к на 8.3 всичко зависи доста сериозно от версията.
За тестване избрах различни сървърни опции и мрежи между тях, за да покажа основните тенденции.
| 1C: Xeon 5520 SQL: Xeon E5-2630 | 1C: Xeon 5520 SQL: Xeon E5-2630 Фибърен канал - SSD | 1C: Xeon 5520 SQL: Xeon E5-2630 Фибърен канал - SAS | 1C: Xeon 5650 SQL: Xeon E5-2630 | 1C: Xeon 5650 SQL: Xeon E5-2630 Фибърен канал - SSD | 1C: Xeon 5650 SQL: Xeon E5-2630 | 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 | |
| 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 |
Изглежда, че разгледах всички интересни опции, ако има нещо друго, което ви интересува, пишете в коментарите, ще се опитам да го направя.
- SAS на системите за съхранение е по-бавен от локалните SSD, въпреки че системите за съхранение имат по-големи размери на кеша. SSD, както локални, така и на системи за съхранение, работят със сравними скорости за теста на Gilev. Не знам нито един стандартен многонишков тест (не само за запис, но и за цялото оборудване), с изключение на теста за натоварване 1C от MCC.
- Промяната на сървъра 1C от 5520 на 5650 почти удвои производителността. Да, сървърните конфигурации не съвпадат напълно, но показва тенденция (не е изненада).
- Увеличаването на честотата на SQL сървъра със сигурност дава ефект, но не същият като на 1C сървъра; MS SQL сървърът е отличен (ако го попитате) за използване на многоядра и свободна памет.
- Промяната на мрежата между 1C и SQL от 1 Gbit на 10 Gbit дава приблизително 10% папагали. Очаквах повече.
- Активирането на споделена памет пак дава ефект, макар и не 15%, както е описано в статията. Не пропускайте да го направите, за щастие е бързо и лесно. Ако по време на инсталацията някой даде на SQL сървъра наименуван екземпляр, тогава за да работи 1C, името на сървъра трябва да бъде посочено не чрез FQDN (tcp/ip ще работи), не чрез localhost или просто ServerName, а чрез ServerNameInstanceName, например zz- testzztest. (В противен случай ще има грешка в DBMS: Microsoft SQL Server Native Client 10.0: Shared Memory Provider: Библиотеката със споделена памет, използвана за установяване на връзка с SQL Server 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, т.е. високо натоварени системи, създадени на базата на 1C:Enterprise, в ситуации, при които симптомите не са напълно разбрани и не може да се направи конкретна диагноза.
Основните причини, влияещи върху работата на 1C
В повече от 60% от случаите причините за ниската производителност са:
- Неоптимални заявки и конфигурационен код (26% от случаите);
- Неоптимално индексиране на обектни таблици (19% от случаите);
- Неоптимално натоварване на дисковата подсистема (16% от случаите).
Водещи разработчици на Microsoft са съгласни с това.
По този начин, за да се постигне значително подобрение в производителността на приложение за база данни, е възможно да се оптимизира обхватът на достъпа до данни, включително логическия и физически дизайн на базите данни (доколкото е възможно в 1C), както и чрез създаване на правилния заявки и използване на оптимално индексиране. Някои проблеми с производителността на базата данни могат да бъдат решени чрез увеличаване на хардуерния капацитет, но не винаги: неправилният дизайн на приложното решение не може да бъде компенсиран от по-мощен сървър. Не е необичайно, без да разбират причините за проблем с производителността, компаниите потребители правят значителни разходи чрез закупуване на ново оборудване, но проблемът остава неразрешен.
Висококачествената диагностика на производителността на 1C с помощта на цялата гама от съществуващи инструменти е ключът към успешното решаване на проблеми и оптимизиране на разходите
Първата стъпка за идентифициране и разрешаване на проблеми с ниска производителност е да се разработи изчерпателен списък на ключовите проблемни дейности, включително текущата им скорост и очакваната бъдеща скорост.
Пример:
Неправилно: Програмата замръзва при генериране на отчет. Искам да се образува по-бързо.
Правилно: Отчетът „Дългова справка“ се генерира за 5 минути 10 секунди. Очакваната скорост на генериране на този отчет е не повече от 20 секунди.
След като списъкът с проблеми е съставен и дигитализиран, е необходимо да се анализират причините, като се започне с търсене на проблемен код, ако има такъв (например „тежки“ заявки, дълго чакане на заключвания, блокировки и др.).
Инструменти за идентифициране на проблемен код
- „1C: Център за управление на производителността“ (модул, включен в инструменталния пакет „1C: Corporate“, произведен от 1C);
- Gilev облачни услуги;
- Стандартни инструменти, вградени в СУБД от водещи производители.
Ефективността на използването на тези инструменти се гарантира от квалификацията на разработчика „1C: Технологичен експерт“, което предполага участието му в мащабни внедрявания на 1C. В същото време различни експерти, въз основа на своя личен опит, могат да дадат предпочитание на един или друг инструмент/метод.
Успоредно с използването на един от представените инструменти се използват и стандартни инструменти за наблюдение на натоварването на оборудването (броячи на монитори за производителност).
Въз основа на получените измервания се определя класът на причината:
- Проблемът е в кода;
- И/или проблемът е в хардуера;
- Проблемът е с други програми, изискващи много ресурси, използвани на производствени сървъри.
Тестване на натоварването 1C - метод за оценка на сървърното оборудване
Както вече споменахме, сред факторите, които могат да повлияят на работата на 1C, както положително, така и отрицателно, сървърният хардуер и неговата конфигурация заемат важно място. Нека разгледаме опциите за измервания, оценка на натоварването и тестване на производителността на системата при следните условия:
- Сървърът 1C е наличен и се намира:
- Заедно със СУБД;
- На отделен сървър.
За оценка на съответствието на параметрите на съществуващото сървърно оборудване с изискванията на системата е необходимо да се съберат данни за натоварването на хардуера, включително процесора, т.е. 1C тестване на натоварване. За тази цел се използва “Performance Monitor” - инструмент, който ви позволява да измервате оборудването на работната верига и да четете броячите на производителността.
По-долу е даден основен набор от броячи, които трябва да бъдат конфигурирани за наблюдение на производителността на хардуера в Windows. Събирането се извършва от всички сървъри, където са инсталирани 1C сървъри.
Ако броячът на процента натоварване на процесора за изгледа „Процесор“ има висока стойност, трябва да идентифицирате процеси, които могат да бъдат спрени, без да се засяга работата на сървъра, и също така да бъдат прехвърлени към други сървъри.
Изгледът „Процес“ ще ви позволи да конфигурирате наблюдение за всеки отделен процес, както и да определите кои процеси заемат най-много процесорно време. Ако на сървъра е инсталиран само 1C сървър, тогава, за да разберете какво натоварване поставя върху хардуера, трябва да конфигурирате колекцията от следните броячи:
| \Process("1cv8*")\% Процесорно време |
| \Process("ragent*")\% Процесорно време |
| \Process("ragent*")\Private Bytes |
| \Process("ragent*")\Virtual Bytes |
| \Process("rmngr*")\% процесорно време |
| \Process("rmngr*")\Private Bytes |
| \Процес("rmngr*")\Виртуални байтове |
| \Process("rphost*")\% процесорно време |
| \Process("rphost*")\Private Bytes |
| \Process("rphost*")\Virtual Bytes |
| \Process("1cv8*")\Private Bytes |
| \Process("1cv8*")\Virtual Bytes |
Ако текущата система е в незадоволително състояние, тогава въз основа на събраните измервания, като се използва линейна връзка, трябва да се изчислят параметрите на оборудването за инсталиране на целевата система.
Ако само се планира закупуването на сървърно оборудване, неговите параметри могат да бъдат изчислени чрез емулиране на работата на планираната система, но в по-малък мащаб, като се използва съществуващо оборудване. За тази цел се използва „1C: Test Center“, който е включен в 1C Corporate Toolkit. Въз основа на получените измервания, като се използват изчислителни методи, се определят параметрите на планираната система и съответно изискванията към оборудването. Този тест може да се използва многократно за различни измервания, като преди това е допълнена и разширена функционалността. Тази техника има висока точност и лекота на изчисление.
Като част от проучването на възможността за наемане на капацитет на специален сървър не само за уеб индустрията, но и за хостване на различни видове информационни и счетоводни системи, ние се опитахме да направим качествена оценка на производителността, използвайки примера за функциониране в специална среда на приложението 1C сървърни версии 8.2 и 8.3 във връзка с CentOS 6.4+ PostgreSQL 9.1.2-1.1C, всички софтуерни компоненти (x_64).
Физическата платформа беше сървър HP ProLiant DL120 G7 (процесор Intel Xeon E3-1230, 8 GB, 2 твърди диска SATA HP MB0500EBZQA без RAID), скоростта на интернет връзката към сървъра беше 100 Mbit/s, скоростта на връзката на клиента варираше от 5 до 12 Mbit/s.
След като прочетох множество материали и дискусии на различни интернет ресурси (като http://www.infostart.ru, www.3nity.ru, www.mista.ru, www.ixbt.com и т.н.), посветени на проблеми с производителността на 1C приложения във версията клиент-сървър беше решено да се използва свободно разпространяваният тест на В. Гилев (http://www.gilev.ru/tpc1cgilv/), резултатите от който позволяват качествено сравнение на различни набори от сървъри и техните компоненти, ОС, СУБД и версии на сървъри за приложения 1C, за да се определи оптималната конфигурация на целия комплекс, включително в ценовия диапазон.
Резултатите от теста са представени на екранните снимки:
Трябва да се отбележи, че имаше доста забележим спад в резултата от теста на платформата 1C версия 8.3.3 (за версия 8.2.18, при равни други условия, броят на точките беше 60), което очевидно се дължи на разлика в изпълнението на програмния код на различни платформи. Клиентската част работеше в нормален режим на приложение (дебел клиент).
Възможността за многонишкова работа също беше тествана, като се използва следният тест като пример (http://infostart.ru/public/173394/). Този тест ви позволява да оцените приблизителния брой едновременни потребители, при които времето за реакция на системата е все още приемливо.
ИГОР ЧУФАРОВ, началник отдел „Интегрирани автоматизирани системи“ в „Радиозавод“ АД, [имейл защитен]
40 точки от теста на Гилев –
мит или реалност?
Продължават бурните дискусии около теста на Гилев, включително и с противоречиви резултати. Ще споделя моя опит с използването на този инструмент.
Произход на неяснотата
Сблъсквайки се за първи път с теста на Гилев, много специалисти остават изненадани от нехарактерните резултати, получени с негова помощ. Например хардуерът за настолен компютър може да покаже по-добри резултати от скъп, мощен сървър. Версията на файла получава по-висока оценка от SQL. И ако с втория инцидент всичко е повече или по-малко ясно, това е обяснено както в документацията за теста, така и в многобройните дискусии във форумите, тогава никой все още не е направил ясни изводи от сравнително ниските резултати на скъпо сървърно оборудване.
Преди да информираме за получените резултати, си струва да споменем няколко думи за самия тест на Гилев, като разкажем какво представлява.
Името „Gilev Test“ се отнася до теста за натоварване TPC-1C, достъпен за безплатно изтегляне от .
Известни резултати
Източникът предоставя интересни резултати от сравнение на сървър, базиран на 2*Intel Xeon E5620 2.4 Ghz с 48 GB RAM и персонален компютър, базиран на Intel Core i5 3.0 Ghz с 16 GB RAM. Без допълнителни настройки и трикове, както се казва „извън кутията“, работната станция „счупи“ сървъра в теста на Гилев, като показа 155% по-висока производителност.
Сървърът отбеляза приблизително 17 точки, докато работният плот отбеляза повече от 40. В резултат на експерименти (повечето от които включваха намаляване на ресурсите на работния плот, за да се определи колко това ще влоши резултата от теста) и настройки на сървъра, авторите на статията успяха за постигане на 25,6 точки.
Резултатът, честно казано, е далеч от 40 на обикновен системен блок. И така, по-добре ли е да разположите сървъра 1C на бюджетен хардуер, закупен в най-близкия павилион? Разбира се че не.
Дискусия на Infostart Event 2016
Няколко дни преди пътуването ми до конференцията Infostart Event 2016 в Санкт Петербург, на уебсайта courses-po-1s се появи интересно двучасово видео за работата на системата 1C:Enterprise във виртуализирани среди, избор на оборудване и проблеми с производителността .rf.
На конференцията Infostart Event 2016 се очакваше да говори авторът на този уебинар Андрей Бурмистров - 1C експерт по технологични въпроси на големи имплементации, работил както в компанията 1C, така и по много големи имплементации у нас, ментор на повече от 2000 специалисти в курса „1C Оптимизация на производителността“ и подготовка за 1C: Expert.
В резултат на интереса към темата разговарях с Андрей както виртуално, така и впоследствие на самата конференция. Един от въпросите, които му зададох по време на кръглата маса HighLoad, се отнася до възможността за пускане на уебинар с референтно тестване на различни варианти на сървърен хардуер - със SSD, с обикновен хард диск, в различни хардуерни конфигурации. Отговорът прозвуча приблизително така: „Благодаря, това е интересна идея. Може би ще го направим. Просто ни дайте Intel P3700, P3600 и ние ще се радваме да го тестваме. Не е толкова лесно да вземеш някъде SSD за тестване за една седмица.
Така се оказа, че със собствените си очи почти никой от моите събеседници не видя повече от 30 точки в SQL режим, а тези, които го видяха, отбелязаха, че не е на сървърно оборудване.
Порочен кръг? Възникна сериозен въпрос: „40 точки в теста на Гилев на сървърен хардуер в SQL режим - мит или реалност?“
Прочетете цялата статия в списание „Системен администратор”, № 5, 2017 г., на стр. 10-15.
PDF версия на този брой може да бъде закупена от нашия
