SSD диск для 1с 8.3 файловий. Гільов - Переклад конфігурації на керовані блокування

Основна мета написання статті – щоб не повторювати очевидні нюанси тим адміністраторам (і програмістам), які ще не набрали досвіду з 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).

Якщо коротко - під час роботи 1С відбувається дуже багато очікувань відповіді з інших пристроїв (диск, мережа тощо). Під час очікування відповіді, якщо режим продуктивності включений збалансований, процесор знижує свою частоту. Приходить відповідь від пристрою, треба працювати 1С (процесору), але перші такти йдуть зі зниженою частотою, потім частота підвищується - а 1С знову чекає відповіді від пристрою. І так - багато сотень разів на секунду.

Включати режим продуктивності можна (і бажано) у двох місцях:

Через 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с?

	Множник	Core speed (частота), GHz	CPU-Z Single Thread	Тест Гільова Ramdisk файловий варіант	Тест Гільова Ramdisk клієнт-сервер
Без Turbo boost
C-state off, Turbo boost				53.19	40,32
C-state on, Turbo boost			1080	53,13	23,04

А в результаті виходить, що за тестами продуктивності ЦПУ варіант з множником 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с. Можна зробити \\server\share, можна \\192.168.0.1\share, можна net use z: \\192.168.0.1\share (і в деяких випадках такий спосіб теж спрацює, але далеко не завжди) і потім вказувати диск Z. Начебто всі ці шляхи вказують на те саме місце, але для 1С є тільки один спосіб, досить стабільно дає нормальну продуктивність. Так ось, правильно робити треба так:

У командному рядку (або в політиках, або як Вам зручно) - робите net use DriveLetter:\server\share. Приклад: net use m: \\server\bases. Я спеціально наголошую, НЕ 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 Mbit отримана шляхом обмеження в налаштуваннях адаптера Intel 362. Різниці між 1 Gbit мідь Intel 350 та 1 Gbit оптика Intel X520-DA2 (отриманої шляхом обмеження швидкості адаптера) не виявлено. Максимальна продуктивність, турбобуст вимкнений (просто для сумісності результатів, турбобуст для хороших результатів додає трохи менше 10%, для поганих – взагалі може не позначитися). Версії 1С 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 Звернення на ім'я	Win 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
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 протоколу.

Після всіх налаштувань і перевірок запускаємо знову тест з клієнтського комп'ютера, радіємо результату, що покращився (якщо вийшло). Якщо результат покращився, папуг стало більше 30 (а особливо більше 40), користувачів одночасно працює менше 10 а робоча база все одно гальмує - практично однозначно проблеми програміста (або Ви вже досягли піку можливостей файлової версії).

Термінальний сервер. (База лежить на сервері, клієнти підключаються по мережі, протокол RDP). Алгоритм за кроками:

0. Додаємо на сервер тестову базу Гільова в ту саму папку, що й основні бази. З цього сервера підключаємося, запускаємо тест. Запам'ятовуємо результат.

1. Так само, як і у файловій версії, налаштовуємо роботу . Що стосується термінального сервера - процесор взагалі несе у собі основну роль (маю на увазі, що немає явних слабких місць, типу браку пам'яті чи величезної кількості непотрібного ПЗ).

2. Налаштування мережевих карток у разі термінального сервера мало впливає працювати 1с. Для забезпечення "особливого" комфорту, якщо у вас сервер видає більше 50 папуг можна погратися з новими версіями RDP протоколу, просто для комфорту роботи користувачів, швидшого відгуку та скролінгу.

3. При активній роботі великої кількості користувачів (а тут вже можна пробувати і 30 осіб на одну базу підключити, якщо постаратися) дуже бажано поставити диск SSD. Чомусь вважається, що диск не дуже впливає на роботу 1С, але всі тести проводять із включеним на запис кешем контролера, що неправильно. Тестова база маленька, вона цілком міститься в кеш, звідси й високі цифри. На реальних (великих) базах все буде зовсім інакше, тому для тестів кеш вимкнено.

Наприклад, перевірив роботу тесту Гілева з різними варіантами дисків. Диски ставив із того, що було під рукою, просто тенденцію показати. Різниця між 8.3.6.2076 та 8.3.7.2008 невелика (у варіанті Ramdisk Turbo boost 8.3.6 видає 56.18 а 8.3.7.2008 видає 55.56, в решті тестів різниця ще менша). Енергоспоживання – максимальна продуктивність, turbo boost відключено (якщо не сказано інше).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Одиночний SSD	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).

Основні плюси термінального сервера – у нього можуть бути дуже слабкі клієнти, і налаштування мережі на термінальний сервер впливають набагато менше (знову ваш К.О.).

Висновки: якщо на термінальному сервері запустити тест Гілева (з того ж диска, де лежать робочі бази) і в ті моменти, коли гальмує робоча база, і тест Гілева покаже хороший результат (вище 30) - то в повільній роботі основної робочої бази винен, найімовірніше, програміст.

Якщо ж і тест Гілева показуємо маленькі цифри, і у вас і процесор з високою частотою, і швидкі диски, то ось тут адміністратору треба брати як мінімум perfmon, причому із записом всіх результатів куди-небудь, і дивитися, спостерігати, робити висновки. Однозначних порад не буде.

Клієнт-серверний варіант.

Тести проводив лише з 8.2, т.к. на 8.3 все досить серйозно залежить від версії.

Для тестування вибирав різні варіанти серверів та мережі між ними, щоб показати основні тенденції.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fibre channel - SSD	SQL: Xeon E5-2630 Fibre channel - SAS	SQL: Xeon E5-2630 Local SSD	SQL: Xeon E5-2630 Fibre channel - SSD	SQL: Xeon E5-2630 Local SSD	1С: Xeon 5650 =	1С: Xeon 5650 = Shared memory	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, а через ServerName\InstanceName, наприклад zz-test\zztest. (Інакше буде помилка СУБД: 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% я не назвав би значним ефектом.

Проектування сервера під потреби «1С:Підприємство 8» для середнього та великого бізнесу

Матеріал розрахований на технічних фахівців, що проектують серверні рішення для потреб «1С:Підприємство 8» з навантаженням 25-250 користувачів та більше. Розглядаються питання оцінки необхідної продуктивності компонентів сервера, з урахуванням екстремальних за завантаженістю випадків, вплив віртуалізації. Питання побудови відмовостійкої корпоративної інфраструктури для великих підприємств будуть розглянуті у наступному матеріалі.

Оцінка необхідної продуктивності устаткування.

Для підбору обладнання потрібна хоча б попередня оцінка потреби в ресурсах CPU, RAM, дискової підсистеми та мережевих інтерфейсів.
Тут можна розглядати два шляхи:
а) Експериментальний, який дозволяє отримати об'єктивні дані про навантаження на поточне обладнання та виявити вузькі місця;
б) Розрахунковий, який дозволяє зробити оцінку виходячи з емпірично отриманих усереднених даних.
Найбільш ефективним є спільне використання обох методологій.

Моніторинг навантаження, оцінка результатів, пошук вузьких місць та формування вимог

Чому важливо проводити аналіз навантаження, якщо у вас вже є працююча система?
Тут найбільш коректно порівнюватиме з медициною. Коли пацієнт приходить до лікаря, спочатку проводиться огляд, призначаються аналізи, потім оцінюється весь комплекс наявної інформації і призначається лікування. Така сама ситуація і при проектуванні сервера.
Доклавши зусиль до вимірів параметрів навантаження та аналізу результатів, як винагорода ми отримаємо найкращу відповідність проектованого сервера своїм завданням. Підсумковим результатом стануть - суттєва економія як початкових витрат, так і операційних витрат надалі.

Оцінювати продуктивність сервера ми будемо в рамках основних підсистем: центральних процесорів, оперативної пам'яті, дискової підсистеми вводу/виводу та мережевих інтерфейсів. Серед Windows існує стандартний інструментарій оцінки обчислювального навантаження Windows Performance Monitor (perfmon). В інших системах є свої аналогічні засоби оцінки.
Загалом навантаження на кожну підсистему сильно залежить від додатків і типів даних, з якими вони працюють. Для блоку додатків, пов'язаних з 1С, найбільш критичними є CPU, RAM, а SQL-сервера ще й дискова підсистема. При рознесенні на кілька серверів критичним є мережевий інтерфейс. Працюватимемо лише з тими параметрами, які нам важливі з погляду прикладного завдання.
Дані для аналізу необхідно збирати не менше ніж за добу у типовий робочий день. Ідеально - накопичити дані за три типові робочі дні. Для пошуку вузьких місць бажано зняти дані на день найбільшого навантаження.
Все описане нижче стане в нагоді, як на етапі підготовки до проектування нового сервера (для постановки завдання постачальнику), так потім і в процесі експлуатації, для об'єктивної оцінки змін параметрів обладнання та можливого подальшого «тюнінгу» програмно-апаратного комплексу під «1С:Підприємства 8» в цілому.

CPU. Найбільшою мірою нас цікавить один параметр - Processor: % Processor Time» (« Процесор: % завантаженості процесора »). Microsoft про цей параметр каже наступне: «Цей лічильник відстежує час, який ЦП витрачає виконання потоку під час роботи. Постійний рівень завантаження ЦП в діапазоні від 80 до 90 % може вказувати на необхідність оновлення ЦП або необхідність додавання кількох процесорів». Таким чином, якщо завантаження CPU в середньому становить 70-80% - це оптимальне співвідношення ефективності використання ресурсів CPU і запасу за продуктивністю на пікові періоди. Менше – система недовантажена. Понад 80% - у зоні ризику, 90% - система перевантажена, необхідно або розносити навантаження інші хости, або переїжджати на новий, більш продуктивний сервер.

Аналіз CPU . Для сучасних процесорів насамперед є сенс з'ясувати, скільки ядер вам необхідно. Сама Windows досить ефективно розподіляє навантаження між ядрами, і за винятком рідкісних випадків, коли на рівні ПЗ є чітка прив'язка до ядра - всі ядра процесора будуть навантажені більш-менш рівномірно. У випадку, якщо у вас параметр «% завантаженості процесора» знаходиться в межах 50-70% – все добре, є резерв. Якщо менше 50% - значить у вашій системі вже є надмірна кількість ядер, їх кількість можна зменшити або завантажити сервер іншими завданнями. Середнє завантаження 80% і більше - вашій системі потрібна більша кількість ядер.

RAM . Тут має сенс відстежувати два параметри:
« Memory: Available Mbytes» (« Пам'ять: МБ »). У системі, що нормально працює, значення цього лічильника має бути не менше 10% від обсягу фізичної пам'яті, встановленої в сервері. Якщо обсяг доступної пам'яті занадто малий - система буде змушена використовувати файл підкачування для активних процесів. Як наслідок – виникають помітні затримки аж до ефекту «зависання» системи.
« Memory: % CommittedBytesInUse», « Пам'ять: % використання виділеної пам'яті ». Високе значення даного лічильника вказує на те, що в системі спостерігається велике навантаження на оперативну пам'ять. Вкрай бажано, щоб цей параметр був нижчим за 90%, т.к. при 95% з'являється можливість виникнення помилки OutOfMemory.

Аналіз RAM . Ключовим параметром є наявність доступного обсягу RAM на сервері, що цілком ефективно дозволяють моніторити наведені вище лічильники.

Дискова підсистема. Дуже часто питання про швидкодію «1С:Підприємство 8» пов'язані з недостатньою продуктивністю саме дискової підсистеми. І саме тут у нас з'являються досить великі можливості оптимізації обладнання під завдання. Тому аналізу лічильників дискової підсистеми ми приділимо максимум уваги.

« % Free Space» - Відсоток вільного простору на логічному диску. Якщо вільно менше 15% ємності диска, він вважається перевантаженим, а його подальший аналіз швидше за все буде не зовсім коректним - на нього сильно впливатиме фрагментованість даних на диску. Об'єм вільного місця, що рекомендується, на серверному диску — не менше 20%, для SSD бажано більше.
« Avg. Disk sec/Transfer» - Середній час звернення до диска. Лічильник показує усереднений час у мілісекундах, необхідний для однієї операції обміну даними з диском. Для слабо навантажених систем (наприклад, файлових сховищ, VM) його значення бажано утримувати в межах 25 - 30 мс. Для високонавантажених серверів (SQL) бажано не перевищувати 10 мс. Великі значення лічильника свідчать про навантаження дискової підсистеми. Це інтегральний показник, який потребує більш детального аналізу. Які саме операції, читання чи записи, та в якій пропорції, показують лічильники Avg. Disk sec/Read(середній час читання з диска в секундах) та Avg. Disk sec/Write(Середній час звернення до диска на запис).
Інтегральний показник AVG. Disk sec/Transfer в RAID5/RAID6 при суттєвому переважанні операцій читання може бути в межах норми, а операції запису будуть виконуватись із істотними затримками.
3.Avg. Disk Queue Length(Середня довжина черги диска) по суті, є інтегральним показником і складається з Avg. Disk Read Queue Length(середня довжина черги до диска на читання) та Avg. Disk Write Queue Length(Середня довжина черги до диска на запис). Він повідомляє, скільки операцій введення/виводу в середньому очікують, коли жорсткий диск стане доступним. Це не вимірюваний показник, а обчислюваний за законом Літтла з теорії черг як N = A * Sr, де N - кількість запитів, що очікують в системі, A - швидкість надходження запитів, Sr - час відгуку. Для нормально працюючої дискової підсистеми цей показник не повинен перевищувати більше ніж на 1 кількість дисків у групі RAID. У додатках класу SQL Server його середнє значення бажано утримувати лише на рівні менше 0,2.
4.Current Disk Queue Length(поточна довжина черги диска) показує кількість невиконаних та очікуваних на обробку запитів, адресованих вибраному диску. Це поточне значення, моментальний показник, а не середнє за інтервал часу. Час затримки обробки запитів до дискової підсистеми є пропорційним довжині черги. Для комфортної роботи в режимі, що встановився, кількість очікуваних запитів не повинна перевищувати кількість фізичних дисків в масиві більш ніж в 1,5-2 рази (виходимо з того, що в масиві з декількох дисків кожен диск може одночасно вибирати з черги по одному запиту).
5.Disk Transfers/sec(звернень до диска/сек) — кількість окремих дискових запитів вводу-виводу, завершених протягом однієї секунди. Показує реальні потреби програм з випадкового читання та запису до дискової підсистеми. Як показник, що підсумовує кілька окремих лічильників, дозволяє швидко оцінити загальну ситуацію.
6.Disk Reads/sec— кількість звернень читання за секунду, тобто частота виконання операцій читання з диска. Найважливіший параметр для програм класу SQL Server, що визначає реальну продуктивність дискової підсистеми.
У нормальному усталеному режимі інтенсивність звернень має перевищувати фізичні можливості дисків — їх індивідуальним межам, помноженим кількість дисків у масиві.

100-120 IOPS на кожен SATA чи NL SAS диск;

200-240 IOPS на кожен SAS 15000 rpm диск;

65000 IOPS на кожен диск SSD класу Intel SSD s3500 series (SATA);

7.Disk Writes/sec— кількість звернень запису на секунду, тобто частота виконання операцій запису на диск. Надзвичайно важливий параметр для програм класу SQL Server. При роботі в нормальному режимі інтенсивність звернень не повинна перевищувати фізичні межі дисків, помножені на їх кількість у масиві та з урахуванням штрафу на запис для вибраного типу RAID.

80-100 IOPS за кожен SATA або NL SAS диск;

180-220 IOPS на кожен диск SAS;

2 ,20 GHz

DDR4
1600/1866/2133

3 ,50 GHz

DDR4 1600/1866/2133/2400

Табл.1 - Параметри роботи з RAM

RAM . На швидкодію всього сервера впливатиме тип встановленої пам'яті. Наприклад, LR DIMM через свою архітектуру завжди матиме більшу латентність, ніж звичайна пам'ять RDIMM DDR4. Особливо щодо коротких запитах, типових для SQL під час роботи з 1С. Виходячи з більшої латентності та істотно більш високої ціни, LR DIMM має сенс встановлювати лише якщо немає можливості набрати необхідний обсяг RAM за рахунок RDIMM.
Так само DDR4 2400 працюватиме трохи швидше, ніж DDR4 2133 - якщо високі частоти підтримує CPU.

Інтерфейс мережі. Тут бажано дотримуватися простих правил:
а) На сервері повинні бути мінімум три мережеві інтерфейси 1Gb Ethernet або вище (10Gb, 40Gb), і не менше двох з них на серверних мережних чіпах. Безумовно, за інших рівних слід віддати перевагу 10Gb Ethernet інфраструктурі, особливо з урахуванням малої різниці, що зникає, в ціні обладнання (мережевих карт 10Gb і портів 10Gb на комутаторах 1GB/10Gb).
б) Сервер повинен підтримувати ту чи іншу технологію KVM-over-IP для віддаленого керування.
З тонкощів можна виділити дуже хорошу підтримку усіма серверними мережними чіпами Intel інструментів віртуалізації та вміння ефективно розподіляти навантаження між ядрами CPU для 10Gb+.

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

Дискова підсистема складається із двох компонентів:
- підсистема введення/виводу у вигляді контролерів SAS HBA та RAID-контролерів;
- пристрої зберігання даних, або у разі - дисків SSD і HDD.

RAID.
Для зберігання OS і баз даних, як правило, використовується RAID 1 або RAID 10, а також їх різні програмні аналоги.

1. Повністю програмний RAID (Soft RAID) засобами Windows Server не може використовуватися для завантажувального диска, зате цілком підходить для зберігання DB, tempDB і SQL log. Технологія Windows Storage Spaces забезпечує досить високі показники по надійності зберігання та швидкодії, а також пропонує цілий ряд додаткових функцій, найцікавішою з яких примирливо до завдань 1С є «Багаторівневе зберігання» (tiered storage). Перевага даної технології в тому, що частина даних, що найбільш часто запитуються, система автоматично розміщується на SSD.
Що стосується завдань 1С зазвичай використовують або All-Flash масив з SSD, або дуже великих за обсягом (1TB і вище) і багаторічних баз даних - Багаторівневе зберігання.
Одна з переваг технології Windows Storage Spaces – її здатність створити RAID на дисках NVMe.

2. Для розміщення OS ефективний апаратно-програмний RAID1, побудований на основі чіпсету від Intel та технології Intel® Rapid Storage Technology ( IntelRST).
У ньому операції з введення-виведення на апаратному рівні виконує чіпсет материнської плати, практично не використовуючи ресурси CPU. А управління масивом складає програмному рівні, з допомогою драйверів під Windows.
Як будь-яке компромісне рішення, у Intel RST є деякі недоліки.
а) Робота Intel RST залежить від драйверів, які завантажуються в операційну систему. І це несе певний потенційний ризик, що під час оновлення драйверів або OS може виникнути ситуація, що диск RAID буде недоступний. Вона дуже малоймовірна, т.к. компанії Intel і Microsoft дуже дружні і дуже якісно тестують своє програмне забезпечення, але не виключена.
б) Виходячи з результатів експериментів, за непрямими ознаками можна припустити, що драйверна модель Intel RST для кешування на запис використовує ресурси RAM. Це дає приріст продуктивності, але несе деякі ризики втрати даних при незапланованому відключенні електроживлення сервера.
Є у цього рішення та переваги.
Одне - завжди дуже висока продуктивність, що знаходиться на рівні, а іноді й вище ніж у повністю апаратних RAID-контролерів.
Друге – підтримка апаратно-програмного RAID1 для дисків NVMe (на момент написання матеріалу – не для завантажувальних дисків). І тут криється цікава особливість для тих, у кого використовуються високонавантажені дискові підсистеми. На відміну від Windows Storage Spaces, яка «довантажує» ядро, що зайняте введенням/виводом, практично до 100%, Intel RST при досягненні приблизно 70% завантаження ядра підключає до процесу введення/виводу наступне ядро. Як результат - більш рівномірне навантаження на ядра CPU і більша продуктивність при високих навантаженнях.

Рис 4 – Утилізація CPU Windows Storage Spaces vs. Intel RST

3. Повністю апаратний RAID на сервері з 2-6 SSD в RAID 1 цілком можна отримати за рахунок SAS HBA на чіпсеті LSI SAS 3008, наприклад, на Intel® RAID Controller RS3WC080. Для цього в SAS HBA встановлюється спеціальна "IR"-прошивка. Причому даний SAS HBA підтримує стандарт SAS 3.0 (12 Gb/s) за ціною близько $300. Відмінним вибором тут буде Intel RAID Controller RS3WC080, який йде відразу з необхідною прошивкою.
Суть цього рішення в тому, що серверний SSD не потрібен кеш на запис. Більш того, більш просунуті RAID-контролери також відключають вбудований кеш на запис при роботі з SSD. Таким чином, не має кеша SAS HBA в режимі RAID-контролера цілком успішно справляється із завданнями швидкісного запису та читання безпосередньо з SSD, забезпечуючи цілком пристойну продуктивність.

4. Для високонавантажених серверів з великою кількістю дисків SSD SAS або SATA бажано встановити повноцінний RAID-контролер класу Intel® RAID Controller RS3MC044 або Adaptec RAID 8805. Вони мають більш продуктивні процесори вводу/виводу і просунуті алгоритми для роботи з дисками HDD і SSD, у тому числі що дозволяють прискорити складання масиву після заміни диска, що вийшов з ладу.

Пристрої зберігання даних (SSDта HDD).
а) Надійність SSD та HDD .
Зазвичай теоретичною надійність дисків оцінюють за параметром "Non-recoverable Read Errors per Bits Read", що можна перекласти як "Ймовірність появи непоновної помилки читання на кількість лічених біт". Він показує, після читання якого обсягу даних з диска, згідно зі статистикою, слід очікувати на появу невідновної помилки.
Ще один важливий параметр показує можливість відмови диска - AFR (annual failure rate), або «Річна інтенсивність відмов».
Далі в таблиці наведені дані для типових дисків SATA Enterprise HDD 7200 (SATA Raid Edition), SAS HDD Enterprise (15 000), SATA SSD Enterprise.

Параметр	Тип дисків
Параметр	Enterprise SATA\SAS NL 7200 prm	Enterprise SAS 15000 prm (10 000 prm)	Enterprise SATA SSD
Non-recoverable Read Errors per Bits Read
Обсяг, під час читання якого статистично очікується невідновна помилка

Таб. 2 - теоретична надійність HDD та SSD

Імовірності появи непоновних помилок у Enterprise SATA SSD класу Intel® SSD DC S3510 Series , в 10 разів нижче, ніж у SAS HDD Enterprise 15 000 prm, і в 100 разів нижче, ніж у SATA Enterprise HDD 7200 prm. Таким чином, SSD Enterprise-класу теоретично і більш надійно, ніж будь-які HDD.

б) Далі оцінимо продуктивність SSD та HDD .
З точки зору бази даних, якою, по суті, є 1С, найважливішими є лише три параметри диска:
- латентність (Latency), або час відгуку диска, вимірюється в мікросекундах (менше – краще);
- кількість операцій читання в секунду (Disk Reads/sec), що вимірюється в IOPS (більше – краще);
- кількість операцій запису за секунду (Disk Writes/sec), що вимірюється в IOPS.
Зведемо ці три параметри одну таблицю:

Параметр	Тип дисків
Параметр	Enterprise SATA/SAS NL 7200 prm	Enterprise SAS 15000 prm (10 000 prm)	Enterprise SATA SSD	Enterprise NVMe SSD
Latency (час відгуку диска на читання/запис), мікросекунди
Disk Reads/sec (кількість операцій читання за секунду), IOPS
Disk Writes/sec (кількість операцій запису за секунду), IOPS

Таб. 3 - Продуктивність HDD та SSD.

Як добре помітно з таблиці, NVMe SSD (на прикладі Intel® SSD DC P3600 Series) латентностіперевершує Enterprise SAS HDD у 100 разів, а за кількості операцій введення-виводув секунду - в 200 разівна запис та в 1500 разівчитання.
Чи розумно при цьому використовуватиме розміщення баз даних технології HDD?

в) Обсяг перезапису на день для серверних SSD .
Крім будь-яких «плюшок» у вигляді суперконденсаторау разі відключення живлення та апаратних модулів шифрування, серверні SSD мають найважливіший параметр - розрахунковий обсяг перезапису щодня від загальної ємності диска SSD. Якщо ми говоримо про серверні SSD Intel - то маємо на увазі щоденний перезапис цього обсягу протягом 5 років, що входить у гарантійні зобов'язання. Цей параметр дозволяє відсортувати SSD на "призначені переважно для читання", "орієнтовані на запис та читання" та "розраховані на великі навантаження по перезапису". У табличній формі це виглядає так:

Диск Intel SSD
Перезапис на день (від ємності)

Таб 4. - Обсяг перезапису SSD щодня.

Відповідно можна правильно підбирати диски саме під завдання в сервері.
Наприклад, для зберігання OS та SQL log цілком достатньо Intel SSD s3510.
Для зберігання DB та tempDB більше підійдуть Intel SSD s3610 або Intel SSD s3710.

Приклади проектування дискових підсистем.
Озброївшись описаним вище, зберемо кілька дискових підсистем під різні вимоги.
а) Сервер на 45 користувачів, DB – 15 GB, приріст на рік – 4 GB, tempDB – 0,5 GB, SQL log – 2 GB.
Тут економічно виправдано встановити RAID1 із двох дисків Intel SSD s3510 240 GB для потреб OS та SQL Log, і RAID1 із двох дисків Intel SSD s3510 120 GB для потреб DB та tempDB. Як RAID-контролер підійде «бортовий» Intel RAPID.
б) Сервер на 100 користувачів, DB – 55 GB, приріст на рік – 15 GB, tempDB – 4 GB, SQL log – 8 GB.
Для такого сервера можна запропонувати RAID1 із двох дисків Intel SSD s3510 240 GB для потреб OS та SQL Log, і RAID1 із двох дисків Intel SSD s3610 200 GB для потреб DB та tempDB. Як RAID-контролер оптимальним буде Intel® RAID Controller RS3WC080 (простий апаратний, без кеша).
в) Сервер на 200 користувачів, DB – 360 GB, приріст на рік – 70 GB, tempDB – 24 GB, SQL log – 17 GB.
Це сервер уже досить навантажений. Для OS, як і раніше, беремо RAID1 з двох дисків Intel SSD s3510 240 GB. SQL Log і tempDB можна розмістити на виділеному RAID1 із двох дисків Intel SSD s3510 120 GB. А для таблиць DB зібрати RAID10 із чотирьох дисків Intel SSD s3610 400 GB. В якості RAID-контролера доречно використовувати Intel® RAID Controller RS3MC044.

Віртуалізація
Продуктивність сучасних серверів часто дозволяє розмістити на одному фізичному - цілу низку віртуальних. Для їхнього оптимального розміщення бажано пам'ятати, як віртуалізація впливає на кожен із компонентів сервера.
CPU і RAM - це ділянки, які зазнають найменших втрат продуктивності у віртуальному середовищі. Відповідно, ті програмні компоненти, які використовують переважно їх - можуть бути безболісно поміщені в Віртуальну машину (VM). До них відноситься «1С:Підприємство 8. Сервер додатків х64», сервіс Remote Desktop та IIS.
Підсистеми введення-виведення несуть помітно великі втрати при віртуалізації: 5-15% - мережевий інтерфейс і до 25% - дискова підсистема. У нас є програмний компонент SQL Serve, чутливий до продуктивності дискової підсистеми - цілком логічно його розмістити не в VM, а фізичному залізі.
Зазвичай так і роблять з серверами, що окремо стоять, або групою серверів під 1С:
- на «залізо» встановлюється OS Windows та MS SQL Server;
- в VM запускається "1С:Підприємство 8. Сервер додатків х64" і в тій же VM "Сервер ліцензування";
- в окремому VM сервісі Remote Desktop або IIS.
У разі використання одному сервері кількох програмних компонентів, зокрема. на різних VM необхідно на рівні дискової підсистеми передбачити додаткове місце для їх розміщення. Як правило, це системні диски з OS – їх збільшують до 480 GB або більше.

Резервне копіювання
Досить поширеною практикою є встановлення в сервер двох дисків HDD великої ємності (4-8 TB) у RAID1 для зберігання локальних копій баз даних, а також ролі файлового сховища. До такого сховища не висуваються високі вимоги щодо швидкості випадкового доступу. А лінійна швидкість як читання, так і запису виходить цілком достатньою для збереження на ньому щоденної резервної копії та файлів користувача. Зібрати такий том можна на будь-якому варіанті RAID-контролера, а на Intel RAPID він ще буде і досить спритно працювати.

І, будь ласка, не забувайте, що у окремого сервера під відповідальні завдання обов'язково має бути надмірне харчування .

Довгі роки на форумах точаться суперечки про те, що здатне прискорити роботу файлової 1С.

Звичайно рецептів багато, у тому числі і я деякими поділяюся на курсі.

Але хто б, що не говорив, для файлової 1С, вузьке місце номер №1 це, звичайно, дискова підсистема!

Власне "Файлова".

Численні звернення до диска здатні здорово «гальмувати» всю роботу в 1С Підприємстві.

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

Як можна вирішити цю проблему?

Звичайно шляхом переходу на більш швидкі диски HDD, SAS диски, RAID, SSD або навіть спосіб для екстремалів розміщення бази на RAM диску, тобто в оперативній пам'яті ПК або сервера.

Власне в цій статті ми торкнемося всіх способів, але особливу увагу приділимо, звичайно, останньому.

Так як немає в мережі адекватних статей, які б змогли розкрити багато аспектів, як використання 1С і RAM диска, так і тлумачних тестів на всіх інших дискових підсистемах, враховуючи повсякденні роботи в 1С-ці.

Адже питань тут багато:

Кому та коли можна використовувати?

У яких ситуаціях?

Надійність?

Область застосування?

Реальні тести швидкості у різних операціях на 1С?

Почнемо, мабуть, із звичайних HDD.

Звичайно, суть проблеми в механіці HDD, яка не дає потрібних швидкостей для файлової роботи в 1С (особливо розрахований на багато користувачів доступ).

Прискорити роботу HDD можна лише шляхом заміни HDD 5400 rpm на 7200 rpm.

Так, швидкість обертання має значення і 7200 об/хв звичайно швидше за 5400.

Це якщо ми хочемо відчути різницю. (Але варто відзначити що практично всі сучасні HDD працюють на швидкостях 7200.)

Диски на 7200 rpm показують приблизно однаковий результат.

І чи то SATA 2 або SATA 3.

SATA (англ. Serial ATA) – послідовний інтерфейс обміну даними з накопичувачами інформації.

Якщо гнатися за інтерфейсом SATA III, (Для HDD), то тут відчутної швидкості не буде, тільки зовсім невелика в цифрах. (Пізніше ми проведемо тест швидкості HDD диска з підтримкою тільки SATA II та SATA III).

До речі, дізнатися на якому інтерфейсі зараз працює Ваш диск (і який інтерфейс він підтримує) можна програмою, «CrystalDiskInfo».

SATA/300 МБ/с – SATA 2

SATA/600 МБ/с – SATA 3

-| SATA/300 (див. мал. 1) - перше це поточний режим роботи диска, а друге SATA/300 - це режим роботи, що підтримується. (Іноді перше не відображає на старих дисках).

На другому малюнку бачимо що як робота так і підтримка HDD у нас SATA 3, тобто 600 МБ/с. -пропускна спроможність інтерфейсу.

(Потім до питання інтерфейсів ми повернемося).

Інша річ якщо ми поставимо звичайні HDD у RAID – 0 (Stripe).

За наявності двох або чотирьох дисків RAID 0 дає відчутний виграш швидкості передачі даних, але абсолютно не забезпечує надійність. Для його побудови підійде будь-який дешевий та навіть програмний RAID-контролер. Підходить для тих, кому потрібно вичавити максимум продуктивності від файлової системи на звичайних HDD за мінімальних витрат.

Швидкість можна порівняти навіть з деякими старими SSD, але на жаль, тут за швидкість платимо надійністю. При виході з ладу хоч одного диска втрачається вся інформація на обох дисках!

Так що часті бекапи баз 1С при такому RAID обов'язкові.

За рахунок чого швидкість?

Дані в RAID-0 рівномірно розподіляються по дисках масиву, диски об'єднуються в один, який може бути помічений на кілька. Розподілені операції читання та запису дозволяють значно збільшити швидкість роботи, оскільки кілька дисків одночасно читають/записують свою порцію даних.

Тобто RAID 0 легко майстерно обходить механіку, за рахунок цього швидкість.

Це RAID – 10

Але мінімальна кількість дисків, необхідне організації цієї системи – 4.

Звичайно, в цій статті ми говоримо про просту файлову 1С, тому розбираємо тільки бюджетні рішення для малих компаній, де сервери початкового рівня або взагалі немає таких у наявності.

З цієї ж причини більш швидкі та дорогі диски SAS, протоколи iSCSI розбирати не будемо.

Швидше за серверні SAS тільки SSD диски.

Ще кілька років тому я не радив би купувати «твердотільні» для роботи в 1С.

Але ця думка у мене змінилася слідом за сьогоднішніми надійними та відносно дешевими SSD дисками.

Наприклад, компанія SAMSUNG сьогодні дає деякі свої диски 10 років гарантії!

Компанії Intel, SanDisk, Corsair та інші 5 років гарантії на SSD!

SSD стали працювати набагато надійніше, швидше, а контролери помітно порозумнішали, звідси й такі гарантії.

Про ціни

Звичайно, SSD диски корпоративного рівня від компанії INTEL влетять нам у копійку.

Але є й добрі бюджетні альтернативи.

Наприклад, "твердотільний" від компанії SanDisk X400 256 Гб обійдеться нам всього в 95 $!

Власне його ми також тестуватимемо в 1С, вже в наступній частині статті.

SanDisk X400 диск хороший, надійний (5 років гарантії), швидкий (читання/запис до - 540/520 МБ/с).

І якщо ми вже заговорили про швидкості, то тут слід враховувати такий момент як SATA 3.

SATA III (версія 3.x) інтерфейс, офіційно відомий як SATA 6 Гбіт/с, є третім поколінням інтерфейсів SATA працює на 6,0 Гбіт/с. Пропускна здатність яка підтримується інтерфейсом – 600 МБ/с. Даний інтерфейс обернено сумісний з інтерфейсом SATA II -3 Гбіт/с.

Пропускна здатність SATA II лише 300 МБ/с, цього цілком достатньо для HDD, але абсолютно немає для сьогоднішніх SSD.

Щоб відкрити потенціал SSD, потрібен інтерфейс як мінімум з пропускною здатністю в 600 МБ/с, тобто SATA III.

Але не хвилюйтеся, якщо Ви купували ПК або сервер після 2010 року, то він, швидше за все, у Вас є в наявності. (Інакше треба міняти материнську плату).

До речі, хочу звернути Вашу увагу на контролери SATA III від різних виробників (в одній материнській платі), наприклад Intel і Marvell, де перші суттєво можуть вигравати за швидкістю. (Власне днями я сам у цьому переконався. Intel виявився швидше на цілих 35%).

Звичайно, SATA III не єдиний інтерфейс для обміну даними з диском SSD.

Розробники «твердотільних» уперлися в пропускну здатність SATA III - 600 МБ/с, і випустили на ринок нові пристрої з інтерфейсами підключення SATA Express, M.2, mSATA, PCI Express.

Тут уже зовсім інші швидкості:

PCI Express x2 2.0 8 Гбіт/с (800 Мбайт/с)

SATA Express 10 Гбіт/с (1000 Мбайт/с)

PCI Express x4 2.0 16 Гбіт/с (1600 Мбайт/с)

PCI Express x4 3.0 32 Гбіт/с (3200 Мбайт/с)

На жаль, зараз ці пристрої коштують чималих грошей, і назвати таке рішення бюджетним складно.

Щоб прискорити роботу Вашого SSD, можна створити RAID 0 з двох дисків, що дозволить навіть удвічі збільшити швидкість SSD.

Але що ж може бути швидше за SSD?

Звичайно, ОЗУ!

Тут швидкості не можна порівняти з HDD, RAID або SSD.

Є методи (спеціальне ПЗ) за допомогою якого можна взяти частину оперативної пам'яті і зробити з неї диск.

Зараз «оперативка» коштує значно дешевше ніж років 5 тому і в багатьох на «борті» вже по 8 -16 або більше Гб ОЗУ.

Весь фокус у тому, щоб виділити необхідний розмір (під базу 1С, темпи і якщо дозволяє розмір, то запхати і всю платформу повністю на цей диск.).

Я вже казав що спосіб «екстримальний»тут не складно здогадатися чому.

Якщо раптом збій у системі, Ви відразу втратите базу, як і все що буде на цьому диску!

Звичайно, щоб реально працювати в 1С яка знаходиться на RAM диску, необхідно серверне обладнання, серверна оперативна пам'ять, блоки безперебійного живлення та надійне залізо. (материнка, процесор тощо).

+ часті бекапи.

Тоді, звичайно, можна працювати, таким чином, в 1С.

Але що робити якщо такого «заліза» немає, адже нас цікавлять бюджетні рішення?

Навіщо тоді взагалі розбирати роботу 1С на диску RAM?

Вигода є друзі!, звичайно не для постійної роботи користувачів у 1С, а скоріше для виконання різних регламентних операцій.

Закриття місяця, переведення, видалення, «зріз бази» (будь-яка інша подібна робота) пов'язана з великою кількістю документів, довідників та всього іншого.

Багато з цих операцій можуть займати дні! Тоді як у оперативній пам'яті кілька годин!

Якщо, наприклад, Ваші користувачі працюють в 1С через веб браузер, тоді і його можна повністю помістити в ОЗУ, це істотно прискорить роботу користувача в 1С через веб.

Іншими словами можна тимчасово використовувати RAM диск для виконання різних важких операцій на 1С, щоб прискорити процес, а потім назад повертати базу на SSD або HDD.

Цей гарний прийом можна використовувати!

Для того щоб приступити до реального тестування файлової 1С на вище перерахованих дискових системах, вже багато готово, крім RAM диска.

Давайте його створюватимемо!

Нам допоможе безкоштовна програма «Dataram RAMDisk»

Її безкоштовної версії буде достатньо для створення диска розміром 4 Гб. (Більше платно ~ $ 21).

У групі LinkedIn “Storage Professionals” (до речі рекомендую звернути увагу на існування дискусійних груп у LinkedIn, буває цікаво) ось уже який тиждень обговорюється тема:
SSD drives failure rates
Деякі цитати звідти, які я наведу без перекладу, благо все зрозуміло (кожен абзац - цитата-фрагмент із повідомлення окремої людини у цьому треді).
I'm working as contractor at bank in the midwest and we have SSD's in EMC VMAX's for about 9 months. We haven’t seen any failures yet
I once ran a multi week attempt to burn out various vendors’ SSDs. I ran them flat out 100% random writes for about a month. Fusion IOs at something like 30k IOPs per drive, STECs / Intels around 7k. Never був able to get any of them to fail.
The Fusion IO did as many writes that month as single SAS drive could do in over a decade.
Мають приблизно 150 SSD drives and have seen 1 failure during the past 12 months.
I've been using SSDs в cx4-960 clariion для just under 12 months with no failures (covering large ms sql tempdb).
З моїх своїх випробувань (перші з'єднані SSD системи 2 та перші роки), SLC SSD failure rate is in the same range as rotating drives.
Ось такі справи. Є над чим подумати тим, хто досі вважає, що ресурс SSD на запис жахливо обмежений, що SSD ненадійний, і при роботі Enterprise Flash Drives дихне як палена китайська USB-флешка Kinqston.

Питання продуктивності 1С у файловому режимі стоїть досить гостро, особливо перед невеликими фірмами, які можуть собі істотних вкладень у устаткування. Проте "апетити" докладання від релізу до релізу лише зростають і завдання підвищення швидкодії при помірних витратах бюджету стає дедалі актуальнішим. У цьому випадку гарним рішенням буде придбання та розміщення баз на SSD.

Один із наших клієнтів, невелика фірма з бухгалтерського обслуговування, почав скаржитися на повільну роботу 1С:Підприємство. Власне і так не дуже швидка робота програми стала дуже тужною після переходу з Бухгалтерії 2.0 на Бухгалтерію 3.0.

Наявний був простий термінальний сервер на Core i3 2120, 8 Гб RAM, з дисковим масивом RAID 1 із двох Western Digital RE4, який обслуговував від трьох до шести користувачів, кожен з яких працював з двома - трьома базами одночасно.

Аналіз продуктивності відразу виявив вузьке місце - дискова підсистема (скриншот зроблено вже після установки SSD, тому RAID масиву відносяться логічні диски C: і E:).

Нескладні розрахунки показали, що запуск навіть однієї інформаційної бази практично повністю використовує продуктивність масиву близько 150 IOPS при поточному співвідношенні читання/запис - фактична межа для дзеркала з двох не найшвидших дисків. На що опосередковано вказує розмір черги.

Одночасний запуск кількох баз на початку робочого дня призводив до суттєвого уповільнення роботи сервера та знижував чуйність системи. Також спостерігалася неприємна задумка під час роботи з журналами, для формування звітів тощо.

Тест продуктивності масиву також показав низький результат, за сьогоднішніми мірками найбільш відповідний портативним дискам.

Стало зрозуміло – потрібна модернізація дискової підсистеми. Навіть за попередніми прикидками, створення продуктивного масиву на основі масових HDD упиралося як у доступний бюджет, так і у фізичні можливості заліза, яке просто не мало необхідної кількості портів SATA і дискових кошиків в корпусі. Тому було ухвалено рішення про придбання SSD.

Оскільки високих дискових навантажень не передбачалося, то вибір проводився насамперед із міркувань ціни. Швидкісні характеристики також відходили другого план, оскільки вузьким місцем ставав інтерфейс SATA-II. У результаті було придбано 128Gb Corsair Neutron LAMD, який був встановленим на сервер показав наступні швидкісні характеристики:

Як бачимо, операції послідовного доступу очікувано вперлися в пропускну здатність інтерфейсу, але в нашому випадку це має другорядне значення. Основну увагу слід звернути на операції випадкового доступу, які значно перевершують аналогічні показники традиційних HDD.

Наступне питання, яке потрібно вирішити: це створити чи "дзеркало" з SSD і пожертвувати TRIM заради відмовостійкості або залишити одиночний диск, вибравши швидкість замість відмовостійкості. Слід зазначити, що сучасні SSD, крім команди TRIM, використовують власні технології боротьби з деградацією, такі як збір сміття, що дозволяє досить ефективно працювати навіть на системах без TRIM. Використовуваний у цій серії SSD контролер LAMD (Link_A_Media Devices) якраз відрізняється дуже ефективними технологіями збору сміття, на рівні накопичувачів корпоративного рівня, що загалом не дивно, тому що його розробники давно працюють в enterprise-сегменті.

Оскільки обсяг документів, що щодня вводяться, невеликий, то ми обмежилися єдиним SSD при обов'язкових щоденних бекапах. Побічно ефект від застосування твердотільного диска можна оцінити за монітором продуктивності:

Кількість операцій вводу-виводу істотно зросла, як і швидкість обміну з диском, у своїй довжина черги вбирається у одиниці. Це дуже непогані показники, залишилося перевірити, наскільки наші дії прискорили роботу безпосередньо з 1С:Підприємство.

Для цього ми провели невелике експрес-тестування, під час якого вимірювали час завантаження інформаційної бази та час групового переведення комплекту документів за певний період часу. У ході тестування застосовувалася конфігурація 1С:Бухгалтерія 3.0.27.7на платформі 8.3.3.721 .

Також у ході аналізу продуктивності ми звернули увагу на той факт, що у своїй роботі 1С:Підприємство активно використовує тимчасові папки, які в нашому випадку були розташовані на жорсткому диску. Тому для досягнення максимальної продуктивності їх варто також перенести на SSD, проте для любителів економити ресурс твердотільних дисків ми включили в тест обидва варіанти: коли бази розташовані на SSD, а тимчасова папка на HDD і коли для роботи програми повністю використовується SSD.

Як бачимо, перенесення інформаційних баз на SSD відразу зменшило час їх завантаження більш ніж удвічі, а переведення прискорилося приблизно на 30%. При цьому повністю зняла проблема з падінням продуктивності при спільній роботі.

Перенесення на SSD тимчасових папок дозволяє скоротити час завантаження більш ніж утричі та приблизно вдвічі прискорити проведення документів. Тут є над чим подумати навіть переконаним прихильникам заощадження ресурсів диска. Наша думка з цього питання така, якщо ви купили SSD - то слід використовувати його по повній програмі.

Зробимо невеликий відступ. Використовуваний нами диск Corsair Neutronмає ресурс 2-3K циклів стирання/запису. Нескладні розрахунки показують, що й щодня повністю перезаписувати всю ємність диска, то вичерпання ресурсу потрібно 5-8 років. Крім того статистика показує, що основна причина виходу з ладу SSD протягом гарантійного терміну не пов'язана з вичерпанням ресурсу, а є виробничим шлюбом або помилками в прошивці.

Насамкінець хочеться сказати, що застосування SSD на сьогоднішній день мабуть єдиний ефективний спосіб істотно підвищити продуктивність 1С: Підприємство у файловому режимі. І що особливо важливо, доступний за ціною навіть для невеликих підприємств.