Гилева - Переклад конфігурації на керовані блокування. Гилева - Переклад конфігурації на керовані блокування Установка 1с на ssd диск

До нас часто приходять питання про те що гальмує 1с, особливо при переході на версію 1с 8.3, завдяки нашим колегам з ТОВ "Інтерфейс", ми детально розповідаємо:

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

Невелике дослідження російськомовних ресурсів по 1С показало, що дане питання старанно обходиться стороною, у разі виникнення проблем зазвичай радиться перехід до клієнт-серверному або термінального режиму. А також практично загальноприйнятим є думка, що конфігурації на керованому додатку працюють значно повільніше звичайних. Як правило аргументи наводяться "залізні": "ось Бухгалтерія 2.0 просто літала, а" трійка "ледве ворушиться", безумовно, для істини в цих словах є, тому спробуємо розібратися.

Споживання ресурсів, перший погляд

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

Для тестування ми взяли дві віртуальні машини під управлінням Windows Server 2012 R2 і Windows 8.1 відповідно, виділивши їм по 2 ядра хостового Core i5-4670 і 2 ГБ оперативної пам'яті, що відповідає приблизно середньої офісної машині. Сервер розмістили на RAID 0 масиві з двох WD Se, а клієнт на аналогічному масиві з дисків загального призначення.

У якості піддослідних баз ми вибрали кілька конфігурацій Бухгалтерії 2.0, релізу 2.0.64.12 , Яку потім поновили до 3.0.38.52 , Все конфігурації запускалися на платформі 8.3.5.1443 .

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

Ми вже готові почути звичне: "так чого вони там такого додали в цю трійку", але давайте не будемо поспішати. На відміну від користувачів клієнт-серверних версій, які вимагають наявності більш-менш кваліфікованого адміністратора, користувачі файлових версій вкрай рідко замислюються про обслуговування баз. Також рідко про це думають обслуговуючі (читай - оновлюють) ці бази співробітники спеціалізованих фірм.

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

Після застосування обраних дій база різко "схудла", ставши навіть менше "двійки", яку теж ніхто ніколи не оптимізував, також трохи зменшилось споживання ОЗУ.

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

Мережа

Пропускна здатність мережі - один найбільш важливих параметрів для мережевих додатків, особливо, як 1С в файловому режимі, які переміщують через мережу значні обсяги даних. Більшість мереж невеликих підприємств побудовані на базі недорогого 100 Мбіт / с устаткування, тому ми почали тестування саме з порівняння показників продуктивності 1С в мережах 100 Мбіт / с і 1 Гбіт / с.

Що відбувається при запуску файлової бази 1С по мережі? Клієнт викачує в тимчасові папки досить велика кількість інформації, особливо якщо це перший, "холодний", запуск. На 100 Мбіт / с ми очікувано впремося в ширину каналу і завантаження може зайняти значний час, в нашому випадку близько 40 секунд (ціна поділки графіка - 4 сек).

Другий запуск відбувається швидше, так як частина даних зберігається в кеші і знаходиться там до перезавантаження. Перехід на гигабитную мережу здатний значно прискорити завантаження програми, як "холодний", так і "гарячий", причому співвідношення значень при цьому дотримується. Тому ми вирішили висловити результат у відносних значеннях, взявши за 100% саме велике значення кожного виміру:

З викладеного вище графіків, Бухгалтерія 2.0 завантажується при будь-якій швидкості мережі вдвічі швидше, перехід зі 100 Мбіт / с на 1 Гбіт / с дозволяє прискорити час завантаження в чотири рази. Різниці між оптимізованої і неоптимізованою базами "трійки" в даному режимі не спостерігається.

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

Тут вже цікавіше, оптимізована база "трійки" в 100 Мбіт / с мережі працює з такою ж швидкістю, як і "двійка", а неоптимізованими показує вдвічі гірший результат. На гігабіт співвідношення зберігаються, неоптимізованими "трійка" також вдвічі повільніше "двійки", а оптимізована відстає на третину. Також перехід на 1 Гбіт / с дозволяє скоротити час проведення в три рази для редакції 2.0 і в два рази для 3.0.

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

Власне, для повсякденних завдань пропускна здатність мережі не є вузьким місцем, неоптимізованими "трійка" всього лише на 20% повільніше двійки, а після оптимізації виявляється приблизно настільки ж швидше - позначаються переваги роботи в режимі тонкого клієнта. Перехід на 1 Гбіт / с не дає оптимізованої базі ніяких переваг, а неоптимізованими і двійка починають працювати швидше, показуючи невелику різницю між собою.

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

Так чому ж 1С гальмує? Будемо розбиратися далі.

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

У минулому матеріалі ми домоглися збільшення продуктивності 1С розмістивши бази на SSD. Можливо недостатньо продуктивності дискової підсистеми сервера? Ми зробили заміри продуктивності дискової сервера під час групового проведення відразу в двох базах і отримали досить оптимістичний результат.

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

Так чи потрібен SSD на сервері? Найкраще відповісти на це питання допоможе тестування, яке ми провели за аналогічною методикою, підключення до мережі всюди 1 Гбіт / с, результат також виражений у відносних значеннях.

Почнемо зі швидкості завантаження бази.

Може бути комусь і здасться дивним, але на швидкість завантаження бази SSD на сервері не впливає. Основний стримуючий фактор тут, як показав попередній тест, пропускна здатність мережі і продуктивність клієнта.

Перейдемо до перепроведення:

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

На повсякденних завданнях картина аналогічна:

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

Дискова підсистема клієнта і SSD

Вплив SSD на швидкість роботи локально встановленої 1С ми розбирали в попередньому матеріалі, багато що зі сказаного справедливо і для роботи в мережевому режимі. Дійсно, 1С достатньо активно використовує дискові ресурси, в тому числі і для фонових і регламентних задач. На малюнку нижче можна бачити, як Бухгалтерія 3.0 досить активно звертається до диска протягом близько 40 секунд після завантаження.

Але при цьому слід усвідомлювати, що для робочої станції де активна робота проводиться з однією - двома інформаційними базами ресурсів продуктивності звичайного HDD масової серії цілком достатньо. Придбання SSD здатне прискорити деякі процеси, але радикального прискорення в повсякденній роботі ви не помітите, так як, наприклад, завантаження буде обмежуватися пропускною спроможністю мережі.

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

Оперативна пам'ять

Незважаючи на те, що оперативка зараз непристойно дешева, багато робітників станції продовжують працювати з тим обсягом пам'яті, який був встановлений при покупці. Ось тут і підстерігають перші проблеми. Уже виходячи з того, що в середньому "трійці" потрібно близько 500 МБ пам'яті можна припустити, що загального обсягу оперативної пам'яті в 1 Гб для роботи з програмою буде недостатньо.

Ми зменшили пам'ять системи до 1 Гб і запустили дві інформаційні бази.

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

До чого це призведе? Подивимося, як використовуються ресурси системи в важких операціях, наприклад, запустимо групове перепроведення відразу в двох базах. Спочатку на системі з 2 ГБ оперативної пам'яті:

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

Тепер зменшимо пам'ять до 1 ГБ:

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

При цьому навіть суб'єктивна робота з двома відкритими базами на системі з 1 ГБ пам'яті виявилася вкрай некомфортною, довідники і журнали відкривалися зі значною затримкою і активним зверненням до диска. Наприклад, відкриття журналу Реалізація товарів і послуг зайняло близько 20 секунд і супроводжувалося все це час високої дискової активністю (виділено червоною лінією).

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

Результат говорить сам за себе, якщо час завантаження виростає приблизно на третину, що ще цілком терпимо, то час виконання операцій в базі виростає в три рази, ні про яку забезпечення зручності користування в таких умовах говорити не доводиться. До речі, цей той випадок, коли покупка SSD здатна поліпшити ситуацію, але набагато простіше (і дешевше) боротися з причиною, а не з наслідками, і просто купити потрібну кількість оперативної пам'яті.

Недолік оперативної пам'яті - основна причина по якій робота з новими конфігураціями 1С виявляється некомфортною. Мінімально підходящими слід вважати конфігурації з 2 ГБ пам'яті на борту. При цьому враховуйте, що в нашому випадку були створені «тепличні» умови: чиста система, запущені тільки 1С і диспетчер задач. У реальному житті на робочому комп'ютері як правило відкриті браузер, офісний пакет, працює антивірус і т.д, і т.п., тому виходьте з потреби 500 МБ на одну базу плюс деякий запас, щоб при важких операціях ви не зіткнулися з нестачею пам'яті і різким зниженням продуктивності.

процесор

Центральний процесор без перебільшення можна назвати серцем комп'ютера, так як саме він, в кінцевому підсумку, здійснює обробку всіх обчислень. Щоб оцінити його роль ми провели ще один набір тестів, такий же, як і для оперативної пам'яті, зменшивши кількість доступних віртуальній машині ядер з двох до одного, при цьому тест виконувався два рази з обсягами пам'яті в 1 ГБ і 2 ГБ.

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

висновки

Отже, чому гальмує 1С? В першу чергу це недолік оперативної пам'яті, основне навантаження в цьому випадку лягає на жорсткий диск і процесор. А якщо вони не блищать продуктивністю, як це зазвичай буває в офісних конфігураціях, то отримуємо ситуацію, описану на початку статті - "двійка" працювала нормально, а "трійка" безбожно гальмує.

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

Потім слід звернути увагу на дискову, покупка SSD навряд чи буде хорошим вкладенням грошей, а от замінити диск на більш сучасний буде не зайвим. Різницю між поколіннями жорстких дисків можна оцінити по наступного матеріалу: Огляд двох недорогих дисків серії Western Digital Blue 500 ГБ і 1 ТБ.

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

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

У групі LinkedIn "Storage Professionals" (до речі рекомендую звернути увагу на існування дискусійних груп в LinkedIn, буває цікаво) ось уже котрий тиждень обговорюється тема:
SSD drives failure rates
Деякі цитати звідти, які я наведу без перекладу, благо все зрозуміло (кожен абзац - цитата-фрагмент з повідомлення окремої людини в даному тред).
I'm working as a contractor at a bank in the midwest and we have SSD's in EMC VMAX's for about 9 months. We have not 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 was able to get any of them to fail.
The Fusion IO did as many writes that month as a single SAS drive could do in over a decade.
We have approximately 150 SSD drives and have seen 1 failure during the past 12 months.
I've been using SSDs in a cx4-960 clariion for just under 12 months with no failures (covering large ms sql tempdb).
From my own experience (first shipped SSD systems 2 and half years ago), SLC SSD failure rate is in the same range as rotating drives.
Ось такі справи. Є над чим подумати тим хто до сих пір вважає, що ресурс SSD на запис жахливо обмежений, Що SSD ненадійний, і при роботі Enterprise Flash Drives дохне як палена китайська USB-флешка Kinqston.

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

Один з наших клієнтів, невелика фірма з бухгалтерського обслуговування, почав скаржитися на повільну роботу 1С: Підприємство. Власне і так не дуже швидка робота програми стала зовсім тужливої \u200b\u200bпісля переходу з Бухгалтерії 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С: Підприємство в файловому режимі. І, що особливо важливо, доступний за ціною навіть для невеликих підприємств.

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

Якщо у Вас комп'ютер гірше, ніж пентіум на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 ядро \u200b\u200bпроцесора. Відповідно, якщо при тестуванні у вас ядро \u200b\u200bпроцесора завантажено в повному обсязі - шукайте слабкі місця. Трохи емоційно, але в цілому коректно, вплив процесора на роботу 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 досить погано паралелі, і під час роботи він цілком спокійно може «з'їсти» одне ядро \u200b\u200bпроцесора, і більше не споживати.

І ще. З настройками за замовчуванням 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 варіантами - більш ніж в два рази. Це не помилка. Якщо під час тесту на САТА дисках дивитися на монітор продуктивності. то там явно видно "Активне час роботи диска (в%)" 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 \u003d	1С: Xeon 5650 \u003d Shared memory	1С: Xeon 5650 \u003d	1С: Xeon 5650 \u003d	1С: Xeon 5650 \u003d
	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, наприклад zztest \\ zztest. (Інакше буде помилка СУБД: Microsoft SQL Server Native Client 10.0: Постачальник загальної пам'яті: Не знайдено бібліотека загальної пам'яті, що використовується для встановлення з'єднання з SQL Server 2000. HRESULT \u003d 80004005, HRESULT \u003d 80004005, HRESULT \u003d 80004005, SQLSrvr: SQLSTATE \u003d 08001, state \u003d 1, Severity \u003d 10, native \u003d 126, line \u003d 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:% Committed Bytes In Use», « Пам'ять:% використання виділеної пам'яті ». Високе значення даного лічильника вказує на те, що в системі спостерігається велике навантаження на оперативну пам'ять. Вкрай бажано, щоб цей параметр був нижче 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 \u003d 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 диск;

65 000 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 ( Intel RST).
У ньому операції по введенню-висновку на апаратному рівні виконує чіпсет материнської плати, практично не задіюючи ресурси CPU. А управління масивом здійснюється на програмному рівні, за рахунок драйверів під Windows.
Як будь-який компромісне рішення, у Intel RST є деякий недоліки.
а) Робота Intel RST залежить від драйверів, що завантажуються в операційну систему. І це несе певний потенційний ризик, що при оновленні драйверів або OS може виникнути ситуація, що диск RAID буде недоступний. Вона надзвичайно малоймовірна, тому що компанії Intel і Microsoft вельми дружні і дуже якісно тестують своє ПО, але не виключена.
б) Виходячи з результатів експериментів, за непрямими ознаками можна припустити, що драйверного модель Intel RST для кешування на запис використовує ресурси RAM. Це дає приріст продуктивності, але при цьому несе деякі ризики втрати даних при незапланований відключенні електроживлення сервера.
Є у даного рішення і переваги.
Одне з них - завжди дуже висока продуктивність, що знаходиться на рівні, а іноді і вище ніж у повністю апаратних RAID-контролерів.
Друге - підтримка апаратно-програмного RAID1 для дисків NVMe (на момент написання матеріалу - не для завантажувальних дисків). І ось тут криється цікава особливість для тих, у кого використовуються високонавантажені дискові підсистеми. На відміну від Windows Storage Spaces, яка «довантажує» зайняте введенням / висновком ядро \u200b\u200bпрактично до 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 prm (SATA Raid Edition), SAS HDD Enterprise 15 000 prm, SATA SSD Enterprise.

параметр	Тип дисків
параметр	Enterprise SATA \\ SAS NL 7200 prm	Enterprise SAS 15 000 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 15 000 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 він ще буде і досить спритно працювати.

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