ІГОР ЧУФАРІВ, начальник відділу інтегрованих автоматизованих систем АТ «Радіозавод», [email protected]
40 балів у тесті Гільова –
міф чи реальність?
Навколо тесту Гільова продовжуються бурхливі обговорення, у тому числі засновані на суперечливих результатах. Поділюсь своїм досвідом використання даного інструменту
Витоки неоднозначності
Вперше зіткнувшись із тестом Гільова, багато фахівців дивуються нехарактерним результатам, які виходять за його допомогою. Наприклад, десктопне залізо може показувати вищі результати, ніж дорогий потужний сервер. Файлова версія отримує більший рейтинг, ніж SQL. І якщо з другим казусом все більш менш зрозуміло, це пояснюється і в документації до тесту, і в численних обговореннях на форумах, то щодо низьких результатів на дорогому серверному обладнанні однозначних висновків поки що ніхто не зробив.
Перш ніж поінформувати про отримані результати, варто кілька слів згадати про тест Гільова, розповісти, що ж це таке.
Під ім'ям «Тест Гільова» мається на увазі тест навантаження TPC-1C, доступний для вільного скачування за адресою .
Відомі результати
У джерелі наводяться цікаві результати порівняння сервера на базі 2*Intel Xeon E5620 2,4 Ghz із 48 Гб оперативної пам'яті та персонального комп'ютера на Intel Core i5 3,0 Ghz із 16 Гб ОЗУ. Без додаткових налаштувань хитрощів, що називається «з коробки», робоча станція «порвала» сервер у тесті Гільова, показавши на 155% вищу продуктивність.
Сервер набрав приблизно 17 балів, у той час як десктоп – понад 40. У результаті експериментів (більша частина з яких полягала у урізанні ресурсів десктопу, щоб визначити, наскільки від цього деградує результат тесту) і налаштування сервера авторам статті вдалося досягти 25,6 бала.
Результат, скажімо прямо, далекий від 40 на звичайному системному блоці. Так що ж, сервер 1С краще розгортати на бюджетному залізі, купленому у найближчому кіоску? Звичайно ж ні.
Обговорення на Infostart Event 2016
За кілька днів до моєї поїздки на конференцію Infostart Event 2016 до Санкт-Петербурга на сайті курси-по-1с.рф з'явилося цікаве двогодинне відео про роботу системи 1С:Підприємство у віртуалізованих середовищах, підборі обладнання та питаннях продуктивності.
На конференції Infostart Event 2016 передбачався виступ автора даного вебінару Андрія Бурмістрова – 1С-експерта з технологічних питань великих впроваджень, який працював як у фірмі «1С», так і на багатьох великих впровадженнях у нашій країні, наставника понад 2000 фахівців з курсу «Оптимізація продуктивності 1С » та підготовці до 1С: Експерт.
На хвилі інтересу до теми поспілкувався з Андрієм як віртуально, так і згодом на самій конференції. Одне з питань, яке я йому поставив під час круглого столу НighLoad, стосувався можливості випуску вебінару з референсним тестуванням різних варіантів серверного обладнання - з SSD, зі звичайним жорстким диском, у різній конфігурації обладнання. Відповідь звучала приблизно так: «Дякую, ідея цікава. Можливо, зробимо. Просто дайте нам Intel P3700, P3600 і ми з радістю його протестуємо. Це не так просто дістати десь на тестування на тиждень SSD».
Так ось, виявилося, що саме на власні очі практично ніхто з моїх співрозмовників не бачив більше 30 балів у режимі SQL, а ті, хто бачив, зазначали, що це було не на серверному устаткуванні.
Замкнуте коло? Назріло неабияке питання: «40 балів у тесті Гільова на серверному устаткуванні в режимі SQL – міф чи реальність?»
Статтю повністю читайте у журналі «Системний адміністратор», №5 за 2017 р. на сторінках 10-15.
PDF-версію цього номера можна придбати у нашому
Фото Олени Тулякової, ІА «Клерк.ру»
У статті вказані основні помилки, які роблять початківці адміністратори 1С, і показані способи їх вирішення на прикладі тесту Гільова.
Основна мета написання статті – щоб не повторювати очевидні нюанси тим адміністраторам (і програмістам), які ще не набрали досвіду з 1С.
Вторинна мета, якщо маю якісь недоліки, — на Інфостарті мені це вкажуть найшвидше.
Якимсь стандартом "де факто" вже став тест В. Гільова. Автор на своєму сайті дав цілком зрозумілі рекомендації, я ж наведу деякі результати, і прокоментую найбільш ймовірні помилки. Природно, що результати тестування на Вашому устаткуванні можуть відрізнятися, це просто для орієнтиру, що має бути і чого можна прагнути. Відразу хочу наголосити, що зміни треба робити покроково, і після кожного кроку перевіряти, який результат це дало.
На Інфостарті подібні статті є, у відповідних розділах ставитиму на них посилання (якщо пропущу щось - прохання підказати у коментарях, додам). Отже, припустимо у вас гальмує 1С. Як діагностувати проблему, і як зрозуміти, хто винен, адміністратор чи програміст?
Вихідні дані:
Комп'ютер, що тестується, основний піддослідний кролик: HP DL180G6, в комплектації 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Для порівняння, порівняні результати в однопотоковому тесті показує Core i3-2100. Обладнання спеціально взяв не найновіше, на сучасному обладнанні результати помітно кращі.
Для тестування рознесених серверів 1С і 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. Додаємо на файловий сервер тестову базу Гільова до тієї ж папки, що й основні бази. З клієнтського комп'ютера підключаємось, запускаємо тест. Запам'ятовуємо результат.
Мається на увазі, що навіть для старих комп'ютерів 10-річної давності (Pentium на 775 socket) час від натискання на ярлик 1С: Підприємство до появи вікна бази має пройти менше хвилини. (Celeron = повільна робота).
Якщо у Вас комп'ютер гірший, ніж пентіум на 775 socket з 1 гб оперативної пам'яті, то я Вам співчуваю, і комфортної роботи на 1С 8.2 у файловій версії Вам буде важко. Подумайте або про апгрейд (давно пора), або про перехід на термінальний (або web, у разі тонких клієнтів та керованих форм) сервер.
Якщо комп'ютер не гірший, можна штовхати адміністратора. Як мінімум – перевірити роботу мережі, антивіруса та драйвера захисту HASP.
Якщо тест Гільова на цьому етапі показав 30 папуг і вище, але робоча база 1С все одно працює повільно - питання вже до програміста.
1. Для орієнтира, скільки ж може "вичавити" клієнтський комп'ютер, перевіряємо роботу тільки цього комп'ютера без мережі. Тестову базу ставимо на локальний комп'ютер (на швидкий диск). Якщо клієнтському комп'ютері немає нормального ССД, то створюється рамдиск. Поки що, найпростіше і безкоштовне - Ramdisk enterprise.
Для тестування версії 8.2 цілком достатньо 256 мегабайт рамдиска, і! Найголовніше. Після перезавантаження комп'ютера з працюючим рамдиском на ньому повинно бути вільно 100-200 мб. Відповідно, без рамдиска, для нормальної роботи вільної пам'яті має бути 300-400 мегабайт.
Для тестування версії 8.3 рамдиска 256 мегабайт вистачить, але вільної оперативної пам'яті треба більше.
При тестуванні слід дивитися на завантаження процесора. У випадку, близькому до ідеального (рамдиск), локальна файлова 1с під час роботи завантажує 1 ядро процесора. Відповідно, якщо при тестуванні у вас ядро процесора завантажено не повністю - шукайте слабкі місця. Трохи емоційно, але загалом коректно, вплив процесора працювати 1С описано . Просто для орієнтиру, навіть на сучасних Core i3 з високою частотою, цілком реальні цифри 70-80.
Найпоширеніші помилки цьому етапі.
- Неправильно налаштований антивірус. Антивірусів багато, налаштування для кожного свої, скажу лише те, що при грамотному налаштуванні ні веб, ні касперський 1С не заважають. При налаштуваннях "за замовчуванням" - може забиратися приблизно 3-5 папуг (10-15%).
- Режим продуктивності. Чомусь на це мало хто звертає уваги, а ефект – найвагоміший. Якщо потрібна швидкість - робити це обов'язково, і на клієнтських і на серверних комп'ютерах. (Гарний опис у Гілева. Єдиний нюанс, на деяких материнських платах якщо вимкнути Intel SpeedStep то не можна включати TurboBoost).
Вмикати режим продуктивності можна (і бажано) у двох місцях:
- через BIOS. Вимкнути режими C1, C1E, Intel С-state (C2, C3, C4). У різних біосах вони називаються по-різному, але сенс один. Шукати довго, потрібно перезавантаження, але якщо зробив один раз – потім можна забути. Якщо BIOS все зробити правильно, то швидкості додасться. На деяких материнських платах налаштуваннями BIOS можна зробити так, що режим продуктивності Windows ролі не гратиме. (Приклади налаштування BIOS у Гільова). Ці налаштування здебільшого стосуються серверних процесорів або "просунутих" BIOS, якщо Ви таке у себе не знайшли, і у вас НЕ Xeon – нічого страшного.
- Панель керування - Електроживлення - Висока продуктивність. Мінус - якщо ТО комптютера давно не проводилося, він сильніше гудітиме вентилятором, більше грітиметься і споживатиме більше енергії. Це – плата за продуктивність.
| Це налаштування за замовчуванням. У BIOS C-state включені, режим енергоспоживання збалансований |  |
| У BIOS C-state включено, режим високої продуктивності Для Pentium та Core на цьому можна зупинитися, з Xeon ще можна вичавити трохи "папужок" |  |
| У BIOS C-state вимкнено режим високої продуктивності. Якщо не використовувати Turbo boost - саме так має виглядати сервер, налаштований на продуктивність |  |
Нині ж цифри. Нагадаю: Intel Xeon 5650, Ramdisk. У першому випадку тест показує 23.26, в останньому – 49.5. Різниця – майже дворазова. Цифри можуть змінюватись, але співвідношення залишається практично таким же для Intel Core.
Шановні адміністратори, ви можете як завгодно лаяти 1С, але якщо кінцевим користувачам потрібна швидкість, необхідно включати режим високої продуктивності.
в) Turbo Boost. Спочатку треба зрозуміти, чи підтримує Ваш процесор цю функцію, наприклад. Якщо підтримує, можна ще цілком легально отримати трохи продуктивності. (Питання розгону по частоті, особливо серверів, торкатися не хочу, робіть це на свій страх і ризик. Але погоджуся з тим, що підвищення Bus speed зі 133 до 166 дає дуже відчутний приріст як швидкості, так і тепловиділення)
Як включати turbo boost написано, наприклад, . Але! Для 1С є деякі нюанси (не найочевидніші). Складність у цьому, що максимальний ефект від turbo boost проявляється тоді, коли включені C-state. І виходить приблизно така картинка:
Зверніть увагу, що множник – максимальний, частота Core speed – найкрасивіша, продуктивність – висока. Але що буде в результаті з 1с?
А в результаті виходить, що за тестами продуктивності ЦПУ варіант з множником 23 попереду, за тестами Гільова у файловій версії - продуктивність з множником 22 і 23 однакова, а ось у клієнт-серверній - варіант з множником 23 жах жах (навіть, якщо C -state виставити на рівень 7, все одно повільніше, ніж з вимкненим C-state). Тому рекомендація, перевірте обидва варіанти у себе, і виберіть із них найкращий. У будь-якому випадку, різниця 49,5 та 53 папуги – досить значна, тим більше це без особливих зусиль.
Висновок – turbo boost включати обов'язково. Нагадаю, що недостатньо включити пункт Turbo boost у біосі, треба ще подивитися й інші налаштування (BIOS: QPI L0s, L1 – disable, demand scrubbing – disable, Intel SpeedStep – enable, Turbo boost – enable. Панель управління – Електроживлення – Висока продуктивність) . І я все-таки (навіть для файлової версії) зупинився на варіанті, де c-state вимкнений, хоч там множник і менше. Вийде якось так...
Досить спірним моментом є частота пам'яті. Наприклад, ось частота пам'яті показується як дуже сильно впливає. Мої ж тести – такої залежності не виявили. Я не порівнюватиму DDR 2/3/4, я покажу результати зміни частоти в межах однієї лінійки. Пам'ять та сама, але у біосі примусово ставимо менші частоти.
 |  |  |
І результати тестування. 1С 8.2.19.83, для файлового варіанта локальний рамдиск, для клієнт-серверного 1С та SQL на одному комп'ютері, Shared memory. Turbo boost в обох варіантах вимкнено. 8.3 показує порівняні результати.
Різниця - у межах похибки вимірів. Я спеціально витягнув скрини CPU-Z щоб показати, що зі зміною частоти змінюються інші параметри, ті ж CAS Latency і RAS to CAS Delay, що нівелює зміну частоти. Різниця буде тоді, коли фізично змінюватимуться модулі пам'яті, з повільніших на швидші, але й там цифри не надто значні.
2. Коли з процесором та пам'яттю клієнтського комп'ютера розібралися, переходимо до наступного дуже важливого місця – мережі. Про тюнінг мережі написано багато томів книг, є статті на Інфостарті ( , та інші), тут я на цю тему загострюватиму увагу не буду. Перед початком тестування 1С прохання переконатися, що iperf між двома комп'ютерами показує всю смугу (для 1 гбіт карток – ну хоча б 850 мбіт, а краще 950-980), що виконані поради Гільова. Потім - найпростішою перевіркою роботи буде, хоч як це дивно, копіювання одного великого файлу (5-10 гігабайт) по мережі. Непрямою ознакою нормальної роботи в мережі в 1 гбіт буде середня швидкість копіювання 100 мб/сек, хорошої роботи — 120 мб/сек. Хочу звернути увагу, що слабким місцем (у тому числі) може бути завантаженість процесора. SMB протокол на Linux досить погано паралеліться, і під час роботи він цілком спокійно може «з'їсти» одне ядро процесора і більше не споживати.
І ще. За замовчуванням windows клієнт найкраще працює з windows server (або навіть windows робоча станція) і протоколом SMB/CIFS, linux клієнт (debian, ubuntu інші не дивився) краще працює з linux і NFS (з SMB теж працює, але на NFS папуги вище). Те, що при лінійному копіюванні вин-лінукс сервер на НФС копіюється в один потік швидше, ще ні про що не говорить. Тюнінг debian для 1С - тема окремої статті, я до неї ще не готовий, хоча можу сказати, що у файловій версії отримував навіть трохи більшу продуктивність, ніж Win варіант на цьому ж обладнанні, але з postgres при користувачах понад 50 у мене поки що все дуже погано.
Найголовніше, про що знають адміністратори, що не "обпеклися", але не враховують початківці. Є багато способів задати шлях до бази 1с. Можна зробити servershare, можна 192.168.0.1share, можна net use z: 192.168.0.1share (і в деяких випадках такий спосіб теж спрацює, але далеко не завжди) і потім вказувати диск Z. Начебто всі ці шляхи вказують на одне і те ж місце, але для 1С є тільки один спосіб, що досить стабільно дає нормальну продуктивність. Так ось, правильно робити треба так:
У командному рядку (або політиків, або як Вам зручно) - робите net use DriveLetter: servershare. Приклад: net use m: serverbases. Я спеціально наголошую, НЕ IP адресу, а саме ім'я сервера. Якщо сервер на ім'я не видно - додайте його в dns на сервері, або локально до файлу hosts. Але звернення має бути на ім'я. Відповідно - в дорозі до бази звертатися до цього диска (див. картинку).
А тепер я на цифрах покажу, чому саме така порада. Вихідні дані: Карти Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. Win 2008 R2, Win 7, Debian 8. Драйвера останні, оновлення застосовані. Перед тестуванням я переконався, що Iperf дає повну смугу (крім 10 гбіт карток, там вийшло тільки 7.2 Gbit вичавити, потім подивлюсь чому тестовий сервер ще не налаштований як треба). Диски різні, але скрізь SSD (спеціально вставив одиночний диск для тестування, більше нічим не навантажено) або рейд із SSD. Швидкість 100 Мбіт отримана шляхом обмеження в налаштуваннях адаптера Intel 362. Різниці між 1 Gbit мідь Intel 350 і 1 Gbit оптика Intel X520-DA2 (отриманої шляхом обмеження швидкості адаптера) не виявлено. Максимальна продуктивність, турбобуст вимкнений (просто для сумісності результатів, турбобуст для хороших результатів додає трохи менше 10%, для поганих - взагалі може не позначитися). Версії 1С 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 | |
| 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 | |
| 1С 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 |
Висновки (з таблиці, і з особистого досвіду. Стосується лише файлової версії):
- По мережі можна отримати цілком нормальні цифри для роботи, якщо цю мережу нормально налаштувати і правильно прописати шлях до 1С. Навіть перші Core i3 можуть давати 40+ папуг, що досить непогано, причому це не тільки папуги, в реальній роботі різниця теж помітна. Але! обмеженням при роботі кількох (більше 10) користувачів вже виступатиме не мережа, тут 1 Гбіт ще вистачить, а блокування при розрахованій на багато користувачів роботі (Гілев).
- платформа 1C 8.3 в рази вимогливіша до грамотного настроювання мережі. Базові налаштування - см Гілев, але врахуйте, що впливати може все. Бачив прискорення від того, що деінсталювали (а не просто відключали) антивірус, від прибирання протоколів типу FCoE, від зміни драйверів на більш стару, але microsoft certified версію (особливо стосується дешевих карток типу асусів та довжин), від прибирання другої мережевої картки із сервера . Дуже багато варіантів, настроюйте мережу вдумливо. Цілком може бути ситуація, коли платформа 8.2 дає прийняті цифри, а 8.3 - у два чи навіть більше разів менше. Спробуйте грати з версіями платформи 8.3, іноді виходить дуже великий ефект.
- 1С 8.3.6.2076 (може і пізніші, точну версію ще не шукав) по мережі все-таки налаштувати простіше, ніж 8.3.7.2008. Домогтися від 8.3.7.2008 нормальної роботи по мережі (у порівнянних папугах) вдалося всього кілька разів, повторити для більш загального випадку не зміг. Сильно не розбирався, але судячи з онуч від Process Explorer там запис не так йде, як у 8.3.6.
- Незважаючи на те, що при роботі на 100Мбіт мережі графік її завантаженості невеликий (можна сказати, що мережа вільна), швидкість роботи все одно набагато менше, ніж на 1 гбіт. Причина – затримки (latency) мережі.
- За інших рівних умов (добре працюючої мережі) для 1С 8.2 з'єднання Intel – Realtek повільніше на 10%, ніж Intel-Intel. А ось realtek-realtek взагалі можуть дати різкі просідання на рівному місці. Тому, якщо є гроші - краще скрізь тримати мережеві картки Intel, якщо грошей немає - Intel ставити тільки на сервер (ваш К.О.). Та й інструкцій з тюнінгу інтелевих мережевих карток у рази більше.
- Налаштування антивірусів за умовчанням (на прикладі drweb 10 версії) забирають близько 8-10% папуг. Якщо налаштувати як треба (дозволити процесу 1cv8 робити все, хоч це й не безпечно) – швидкість така сама, як і без антивірусу.
- Лінуксовим гуру не читати. Сервер з samba це здорово і безкоштовно, але якщо на сервер поставити Win XP або Win7 (а ще краще – серверні ОС), то у файловій версії 1с працюватиме швидше. Так, і samba і стек протоколів та налаштування мережі та багато іншого в debian/ubuntu добре тюнінгується, але робити це рекомендується фахівцям. Немає сенсу ставити лінукс із налаштуваннями за замовчуванням і потім говорити, що він повільно працює.
- Досить добре перевіряти роботу дисків, підключених через net use, з допомогою fio . Принаймні буде зрозуміло, чи це проблеми з платформою 1С, чи з мережею/диском.
- Для одного користувача варіанта не можу придумати тести (або ситуацію), де була б видна різниця між 1Гбіт і 10 Гбіт. Єдине, де 10Гбіт для файлової версії дав результат краще – це підключення дисків по iSCSI, але це тема окремої статті. Все-таки вважаю, що для файлової версії 1 Гбіт карток достатньо.
- Чому при 100 Мбіт мережі 8.3 працює помітно швидше за 8.2 - не розумію, але факт мав місце бути. Все інше обладнання, всі інші установки абсолютно однакові, просто в одному випадку тестується 8.2, а в іншому - 8.3.
- Не тюнінгований NFS win-win або win-lin дає 6 папуг, у таблицю включати не став. Після тюнінгу 25 отримав, але нестабільно (розбіг у вимірах більше 2 одиниць). Поки не можу дати рекомендації щодо використання windows та NFS протоколу.
Термінальний сервер (База лежить на сервері, клієнти підключаються по мережі, протокол RDP). Алгоритм за кроками:
- Додаємо на сервер тестову базу Гільова в ту саму папку, що й основні бази. З цього сервера підключаємося, запускаємо тест. Запам'ятовуємо результат.
- Так само, як і у файловій версії, налаштовуємо роботу процесора. Що стосується термінального сервера - процесор взагалі несе у собі основну роль (маю на увазі, що немає явних слабких місць, типу браку пам'яті чи величезної кількості непотрібного ПЗ).
- Налаштування мережевих карток у разі термінального сервера мало впливає працювати 1с. Для забезпечення "особливого" комфорту, якщо у вас сервер видає більше 50 папуг можна погратися з новими версіями RDP протоколу, просто для комфорту роботи користувачів, швидшого відгуку та скролінгу.
- При активній роботі великої кількості користувачів (а тут вже можна пробувати і 30 осіб на одну базу підключити, якщо постаратися), дуже бажано поставити SSD диск. Чомусь вважається, що диск не особливо впливає на роботу 1С, але всі тести проводять із включеним на запис кешем контролера, що неправильно. Тестова база маленька, вона цілком міститься у кеш, звідси й високі цифри. На реальних (великих) базах все буде зовсім інакше, тому для тестів кеш вимкнено.
| Raid 10 4x SATA 7200 ATA ST31500341AS | Raid 10 4x SAS 10k | Raid 10 4x SAS 15k | Поодинокий SSD | Ramdisk | Ramdisk | Увімкнено кеш 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 | |
| 1С 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 контролера нівелює всю різницю між дисками, цифри однакові і сата, і сас. Тестування з нею для невеликого обсягу даних марна і є якимось показником.
- Для платформи 8.2 різниця у продуктивності між SATA та SSD варіантами - більш ніж удвічі. Це не помилка. Якщо під час тесту на CATA дисках дивитися на монітор продуктивності. то там очевидно видно "Активний час роботи диска (в%)" 80-95. Так, якщо включити кеш самих дисків на запис, швидкість зросте до 35, якщо включити кеш рейд контролера - до 49 (незалежно від того, які диски тестуються в даний момент). Але це - синтетичні папуги кешу, у реальній роботі при великих базах ніколи не буде 100% write cache hit ratio.
- Швидкість навіть дешевих ССД (я тестував на Agility 3) цілком вистачає для роботи файлової версії. Ресурс запису - інша справа, тут треба дивитися в кожному конкретному випадку, зрозуміло, що у Intel 3700 він буде на порядок вище, але там і ціна відповідна. І так, я розумію, що при тестуванні SSD диска я теж тестую переважно кеш цього диска, реальні результати будуть меншими.
- Найправильнішим (на мою думку) рішенням буде виділити 2 ССД диска в дзеркальний рейд для файлової бази (або кількох файлових баз), і нічого більше туди не поміщати. Так, при дзеркалі ССД зношуються однаково і це мінус, але хоча б від помилок електроніки контролера хоч якось застраховані.
- Основні плюси ССД дисків для файлового варіанта з'являться тоді, коли буде багато баз і в кожній по кілька користувачів. Якщо баз 1-2 і користувачів в районі 10, то і SAS дисків вистачить. (але у будь-якому разі - дивитися завантаження цих дисків, хоча б через perfmon).
- Основні плюси термінального сервера – у нього можуть бути дуже слабкі клієнти, і налаштування мережі на термінальний сервер впливають набагато менше (знову ваш К.О.).
Якщо ж і тест Гільова показуємо маленькі цифри, і у вас і процесор з високою частотою, і швидкі диски, то ось тут адміністратору треба брати як мінімум perfmon, причому із записом всіх результатів куди-небудь, і дивитися, спостерігати, робити висновки. Однозначних порад не буде.
Клієнт-серверний варіант.
Тести проводив лише з 8.2, т.к. На 8.3 все досить серйозно залежить від версії.
Для тестування вибирав різні варіанти серверів та мережі між ними, щоб показати основні тенденції.
| 1С: Xeon 5520 SQL: Xeon E5-2630 | 1С: Xeon 5520 SQL: Xeon E5-2630 Fibre channel - SSD | 1С: Xeon 5520 SQL: Xeon E5-2630 Fibre channel - SAS | 1С: Xeon 5650 SQL: Xeon E5-2630 | 1С: Xeon 5650 SQL: Xeon E5-2630 Fibre channel - SSD | 1С: Xeon 5650 SQL: Xeon E5-2630 | 1С: Xeon 5650 = | 1С: Xeon 5650 = | 1С: Xeon 5650 = | 1С: Xeon 5650 = | 1С: 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 |
Начебто всі цікаві варіанти розглянув, якщо щось цікавить ще – пишіть у коментарі, постараюся зробити.
- САС на СГД працює повільніше, ніж локальні ССД, навіть незважаючи на те, що у СГД великі розміри кешу. ССД і локальні та на СХД для тесту Гільова працюють з порівнянною швидкістю. Якийсь стандартний багатопотоковий тест (не тільки записи, а всього обладнання), крім навантажувального 1С з ЦУП, я не знаю.
- Зміна сервера 1С із 5520 на 5650 дала практично подвоєння продуктивності. Так, конфігурації серверів не збігаються повністю, але тенденцію показує (нічого дивовижного).
- Збільшення частоти на сервері SQL, звичайно, дає ефект, але не такий, як на сервері 1С, MS SQL сервер відмінно вміє (якщо його про це попросити) використовувати багатоядерність і вільну пам'ять.
- Зміна мережі між 1С та SQL з 1 гбіт на 10 гбіт дає приблизно 10% папуг. Чекав на більше.
- Включення Shared memory ефект таки дає, хоч і не 15%, як у статті описано. Робити обов'язково, благо це швидко та просто. Якщо хтось при встановленні дав серверу SQL іменований інстанс, то для роботи 1С ім'я сервера треба вказувати не FQDN (працюватиме tcp/ip), не через localhost або просто ServerName, а через ServerNameInstanceName, наприклад zz-testzztest. (Інакше буде помилка СУБД: Microsoft SQL Server Native Client 10.0: Постачальник спільної пам'яті: Не знайдено бібліотеку спільної пам'яті, яка використовується для встановлення з'єднання з SQL Server 2000 . state=1, Severity=10, native=126, line=0).
- Для користувачів менше 100 єдиний сенс для рознесення на два окремі сервери - це ліцензія на Win 2008 Std (і старіші версії), яка підтримує лише 32 Гб ОЗУ. У всіх інших випадках - 1С і SQL однозначно треба ставити на один сервер і давати йому більше (хоча б 64 Гб) пам'яті. Давати MS SQL менше 24-28 Гб ОЗУ - невиправдана жадібність (якщо Ви думаєте, що у Вас цієї пам'яті йому вистачає і все нормально працює - може Вам і файлової версії 1С вистачило б?)
- Наскільки гірше працює зв'язка 1С і SQL у віртуальній машині – тема окремої статті (підказка – помітно гірша). Навіть у Hyper-V все не так однозначно.
- Збалансований режим продуктивності – це погано. Результати цілком корелюють із файловою версією.
- У багатьох джерелах написано, що режим налагодження (ragent.exe -debug) дає сильне зниження продуктивності. Ну знижує, так, але 2-3% я не назвав би значним ефектом.
В рамках вивчення можливості надання в оренду виділених серверних потужностей не тільки для web-індустрії, але і для розміщення різноманітних інформаційних та облікових систем, нами була спроба якісної оцінки продуктивності на прикладі функціонування у виділеному середовищі сервера додатків 1С версій 8.2 та 8.3 у зв'язці CentOS 6.4+ PostgreSQL 9.1.2-1.1С, всі програмні компоненти (x_64).
В якості фізичної платформи був взятий сервер HP ProLiant DL120 G7 (CPU Intel Xeon E3-1230, 8 GB, 2 жорсткі диски SATA HP MB0500EBZQA без RAID), швидкість інтернет-з'єднання з сервером 100 Мбіт/с, швидкість з'єднання клієнта варіювалася від 5 до 12 Мбіт/с.
Після ознайомлення з численними матеріалами та дискусіями на різних інтернет-ресурсах (таких як http://www.infostart.ru, www.3nity.ru, www.mista.ru, www.ixbt.com та ін), присвячених питанням продуктивності додатків 1С у клієнт-серверному варіанті, було вирішено використовувати вільно поширюваний тест В. Гільова (http://www.gilev.ru/tpc1cgilv/), результати виконання якого дозволяють проводити якісне порівняння різної сукупності серверів та їх компонентів, ОС, СУБД та версій серверів додатків 1С з метою визначення оптимальної конфігурації всього комплексу, в тому числі і в ціновому діапазоні.
Результати тестування представлені на скріншотах:
Слід зазначити досить помітне зменшення результату тесту на платформі 1С версії 8.3.3 (для версії 8.2.18 за інших рівних умов кількість балів дорівнювала 60), що, певне, пов'язані з різницею виконання програмного коду різних платформах. Клієнтська частина функціонувала як звичайного докладання (товстий клієнт).
Також було протестовано можливість багатопоточної роботи з прикладу наступного тесту (http://infostart.ru/public/173394/). Цей тест дозволяє оцінити приблизну кількість користувачів, що одночасно працюють, при якому час відгуку системи ще залишається допустимим.
Кожен спеціаліст підтримки має досвід отримання абстрактних скарг із боку користувачів. Всім знайомі формулювання: "вона дуже довго думає", "у мене червоне вікно", "система працює якось не так", а також "цього давно не було, і ось знову".
У такій ситуації відразу розібратися, де криється помилка, і що в першу чергу, дуже складно. У статті розглянемо чого залежить продуктивність 1С, тобто. високонавантажених систем, створених на базі «1С:Підприємство», у ситуаціях, коли симптоматика не до кінця зрозуміла та конкретний діагноз поставити неможливо.
Основні причини, що впливають на продуктивність 1С
Більш ніж у 60% випадків причинами низької продуктивності виявляються:
- Неоптимальні запити та програмний код конфігурації (26% випадків);
- Неоптимальна індексація таблиць об'єктів (19% випадків);
- Неоптимальне навантаження на дискову підсистему (16% випадків).
З цим солідарні провідні розробники Microsoft
Таким чином, отримати значне поліпшення продуктивності програми бази даних, можна оптимізувати область доступу до даних, включаючи логічне та фізичне проектування баз (наскільки це можливо в 1С), а також за допомогою створення правильних запитів та використання оптимальної індексації. Частина проблем із продуктивністю баз даних може бути вирішена за допомогою нарощування апаратних потужностей, але не завжди: неправильне проектування прикладного рішення не може бути компенсоване більш потужним сервером. Не поодинокі випадки, коли, не розібравшись із причинами проблеми продуктивності, компанії-користувачі йдуть на серйозні витрати, купуючи нове обладнання, а проблема так і залишається невирішеною.
Якісна діагностика продуктивності 1С із застосуванням всього спектра існуючих інструментів – запорука успішного вирішення проблем та оптимізації витрат
Першим кроком до виявлення та усунення проблем низької продуктивності має стати складання повного переліку ключових проблемних операцій із зазначенням точної швидкості їх виконання на поточний момент та очікуваної швидкості їх виконання в майбутньому.
Приклад:
Неправильно: Під час формування звіту програма «зависає». Хочу, щоби формувала швидше.
Правильно: Формування звіту «Відомість із заборгованості» здійснюється 5 хвилин 10 секунд. Очікувана швидкість формування цього звіту – не більше 20 секунд.
Після того як перелік проблем складено та оцифровано, необхідно провести аналіз причин, розпочавши з пошуків проблемного коду, якщо такий є (наприклад, «важкі» запити, тривалі очікування на блокуваннях, deadlock' та ін.).
Інструменти для ідентифікації проблемного коду
- «1С:Центр управління продуктивністю» (модуль, що входить до інструментального пакету «1С:Корпоративний», виробником якого є фірма 1С);
- Хмарні послуги Гільова;
- Штатні інструменти, вбудовані в СУБД провідних вендорів.
Ефективність використання даних інструментів гарантує кваліфікація розробника «1С:Експерт з технологічних питань», що передбачає його участь у масштабних впровадженнях 1С. При цьому різні експерти, виходячи зі свого індивідуального досвіду, можуть надавати перевагу тому чи іншому інструменту/методу.
Паралельно з використанням одного з представлених інструментів застосовуються і штатні засоби моніторингу завантаження обладнання (лічильники Performance monitors).
З отриманих вимірів виявляється клас причини:
- Проблема у коді;
- та/або проблема в апаратній частині;
- Проблема в інших ресурсомістких програмах, що використовуються на робочих серверах.
Навантажувальне тестування 1С - методика оцінки серверного обладнання
Як вже згадувалося, серед факторів, здатних вплинути на швидкодію 1С, як у позитивну, так і негативну сторону, важливе місце займає серверне обладнання та його налаштування. Розглянемо варіанти вимірів, оцінки навантаження та тестування працездатності системи у таких умовах:
- Сервер 1С є в наявності та розташовується:
- Спільно з СУБД;
- На окремому сервері.
Для оцінки відповідності параметрів наявного серверного обладнання вимогам системи необхідно зробити збір даних із навантаження на апаратну частину, зокрема і процесор, тобто. тестування навантаження 1С. Для цього застосовується «Performance Monitor» – інструмент, що дозволяє провести вимірювання обладнання на робочому контурі та зняти лічильники продуктивності.
Нижче наведено базовий набір лічильників, які необхідно налаштувати для моніторингу продуктивності обладнання Windows. Збір провадиться з усіх серверів, де встановлені сервери 1С.
Якщо показник лічильника відсотка завантаженості процесора для виду "Processor" має високе значення, слід виявити процеси, які можна зупинити без шкоди для роботи сервера, а також перенести на інші сервери.
Вигляд «Process» дозволить налаштувати моніторинг для кожного окремого процесу, а також визначити, які процеси займають найбільше процесорного часу. Якщо на сервері встановлено лише сервер 1С, то щоб зрозуміти, яке навантаження він дає на залізо, необхідно налаштувати збір наступних лічильників:
| \Process("1cv8*")\% Processor Time |
| \Process("ragent*")\% Processor Time |
| \Process("ragent*")\Private Bytes |
| \Process("ragent*")\Virtual Bytes |
| \Process("rmngr*")\% Processor Time |
| \Process("rmngr*")\Private Bytes |
| \Process("rmngr*")\Virtual Bytes |
| \Process("rphost*")\% Processor Time |
| \Process("rphost*")\Private Bytes |
| \Process("rphost*")\Virtual Bytes |
| \Process("1cv8*")\Private Bytes |
| \Process("1cv8*")\Virtual Bytes |
Якщо поточна система перебуває у незадовільному стані, то виходячи з зібраних вимірів, застосовуючи лінійну залежність, слід розрахувати параметрів устаткування установки цільової системи.
Якщо придбання серверного обладнання лише планується, розрахувати його параметри можна проеммулировав роботу планованої системи, але у меншому масштабі, наявному устаткуванні. Для цього використовується «1С:Тест-цент», що входить до Корпоративного інструментального пакету 1С. На підставі отриманих вимірів, за допомогою методик розрахунку визначаються параметри системи, що планується, і, відповідно, вимоги до обладнання. Цей тест можна використовувати багаторазово під різні виміри, попередньо доповнивши та розширивши функціонал. Ця методика має високу точність та простоту розрахунку.
Реалізація інфраструктури 1С з урахуванням Linux тема древня, але досі актуальна. Ми нещодавно публікували статтю Сервер додатків 1С на Linux, але залишилося відкритим питання реальної продуктивності порівняно з рішенням під Windows. Тестування проводилося і в ручному режимі, але для об'єктивності результатів я опублікую підсумки тесту Гільова, що пройшов на одній апаратній платформі з використанням різних ОС: Linux CentOS 7 і MS Windows Server 2012.
Як сервер використовувався стенд з двома процесорами Intel Xeon E5-2670, 8х4Гб ОЗУ та SSD Intel.
Зведена таблиця середніх значень результатів тесту Гільова.
Приклади результатів
Прийнятні результати тестування, простота розгортання та низькі витрати на ліцензування спонукали нас створити закінчений продукт: Сервер 1С на базі Linux з коробки.
Кожна модель має зручний конфігуратор, в якому можна підібрати оптимальну конфігурацію для своїх завдань. Ось про це трохи докладніше.
Створення калькулятора обчислювальної потужності сервера 1С – завдання не тривіальне. А створення універсального конфігуратора 1С під усі можливі випадки практично неможлива.
Напевно на хабрі багато адмінів, у яких своє уявлення про навантаження та вимоги до обчислювальної потужності серверів під 1С (Ваші коментарі підвищать цінність цієї статті). Є й офіційні рекомендації 1С, в яких працюватиме все на всьому…
Але все ж таки є основні параметри, які можна прорахувати, застосовно до типової схеми експлуатації. Знаючи скільки ресурсів процесора та оперативної пам'яті забирає термінальна сесія, скільки IOPS зажадає SQL при певній кількості користувачів, і відштовхуючись від результатів численних тестів - ми розробили конфігуратор типового рішення під 1С.
Безумовно, кожен випадок унікальний і вимагає детального пресейлу, але для орієнтовного розрахунку достатньо вказати кількість користувачів, тип бази, обсяг поточної бази та вибрати необхідні ліцензії.
Для порівняння вартості готового рішення на базі Linux та Windows наведу приклад з конфігуратора з роздрібними цінами.
Сервер на 20 користувачів з базою SQL до 80Гб, ліцензією 1С: Бухгалтерія 8 ПРОФ, на базі Linux CentOS буде коштувати 522 759,43 руб. Аналогічна конфігурація з урахуванням Windows - 1 036 279,43 крб.
Модельний ряд серверів для STSS Flagman 1С складається з 3 моделей як для Linux, так і для Windows.
1C113.5-020UL- Сервер 1С початкового рівня, підтримка до 20 користувачів з базою SQL. Обсяг дискового простору розраховується з урахуванням зростання бази на 20% на рік протягом трьох років. Масив RAID1 будується з урахуванням Enterprise SSD Intel. Можливе встановлення подвійного БП та додаткових дисків під «холодні» дані. Доступний вибір програмних сервісів: PostgreSQL, xrdp та httpd.
1C216.4-200UL- модель на базі 2-процесорної платформи, що забезпечує роботу 1C-інфраструктури до 200 одночасних підключень. Сховище розраховується за таким самим принципом - розмір бази з урахуванням зростання, але будується на основі масиву RAID10 з 4хSSD необхідного обсягу.
1C217.2-050UL-REF- це рішення для замовників з обмеженим бюджетом, побудоване на базі сервера відновленого на нашому виробництві (після гарантійної заміни, демо-фонд та ін.) Сервери проходять такі ж тести навантаження перед відвантаженням, як і нові моделі, але мають скорочений термін гарантійного обслуговування ( 1 рік). Сервер підтримує до 50 підключень і, без урахування ліцензій, коштує всього 203 705,00 руб., З масивом під базу 40Гб.
1C113.5-020UW- Сервер 1С початкового рівня, підтримка до 20 користувачів з базою SQL. Обсяг дискового простору розраховується з урахуванням зростання бази на 20% на рік протягом трьох років. Масив RAID1 будується з урахуванням Enterprise SSD Intel. Можливе встановлення подвійного БП та додаткових дисків під «холодні» дані.
1C216.4-200UW- Модель на базі Windows з підтримкою до 200 користувачів. Сховище будується на основі масиву RAID10 із 4хSSD необхідного об'єму.
1C217.2-050UW-REF- Та сама платформа, що й у рішенні на базі Linux. Бюджетний варіант на 50 з'єднань, гарантія 1 рік.
Як платформа 1С у всіх моделях можна вибрати такі ліцензії:
1С: Управління невеликою фірмою 8 ПРОФ
1С: Управління торгівлею 8 ПРОФ
1С: Бухгалтерія 8 ПРОФ
1С: Бухгалтерія 8 КОРП
1С: Зарплата та управління персоналом 8 ПРОФ
1С: Зарплата та управління персоналом 8 КОРП
1С: Документообіг 8 ПРОФ
1С: Документообіг 8 КОРП
Якщо замовник має достатню експертизу для підбору сервера під 1С, він може скористатися класичними моделями серверного обладнання. Але якщо такої експертизи немає, то, сподіваюся, конфігуратор серверів для 1С допоможе Вам зробити оптимальний вибір системи.
Дякую за увагу! Сподіваюся, що хабра-користувачі, близькі до цієї теми, поділяться своїм досвідом у підборі обладнання під 1С в коментарях.
