Нещодавно зіткнувся з незвичайним випадком, у замовника огидно працював сервер 1с, щоб було зрозуміло про що йде мова, наведу такий приклад - запуск товстого клієнта міг займати десяток хвилин. Коли виміряли тестом Гілева, то результат був нижче гіршого. Подивившись найближчі результати замірів інших користувачів, я зрозумів, що це не єдиний випадок.
Мова не йде про оптимізацію, коли треба підняти на 10-20% продуктивність, мова йде про пошук причин низької продуктивності, і її усунення. Погодьтеся це дещо різні речі. На просторах інтернету безліч статей якраз про підвищення продуктивності, які обмежуються тільки налаштуванням сервера 1с і (або) налаштуванням сервера баз даних. А ось статей, що розглядають випадки низької продуктивності, особливо якщо причин кілька, і ці причини знаходяться на різних рівнях, я не зустрічав.
Зазвичай адміністратори кидаються дивитися результати моніторингу. Той випадок, з яким я зіткнувся, показував практично нульове завантаження процесора, наявність вільної ОЗУ, відсутність черги у мережевого інтерфейсу, і тільки черга до диска показувала, що не все в порядку. Довелося влаштувати перевірку за повною програмою, це, звичайно, займає багато часу, вимагає виключення сервера з робочого процесу, але зате дає результат. Можливо для когось подібний підхід неприпустимий, більш того, деякі вважають це непрофесійним підходом, але їм я нічим допомогти не зможу.
Апаратний рівень
Звучить банально, але саме з перевірки працездатності заліза варто почати. Справа в тому, що можна тільки здогадуватися про проблеми з обладнанням, якщо дивитися на рівні операційної системи. У моєму випадку, не працював один з дисків в дисковому масиві. Як не дивно жорсткий диск виявився справним і, після водворіння його на місце, заробив, правда довелося почекати деякий час, поки не синхронізуються всі дані (бачити давно він був відключений). Якби все цим і закінчилося, тоді б і не було цієї статті. Про всяк випадок сервер зазнав апаратного тестування (стрес-тести, тест пам'яті, фізичної перевірки дисків і контролерів), які не виявили жодних проблем.
Рівень операційної системи
Другим пунктом нашої програми стала перевірка і налаштування операційної системи, суть якої полягає в наступному:
- привести до ладу файлову систему;
- відключити непотрібні служби, видалити непотрібні і, найголовніше, шкідливі програми;
- перевірити оптимальність параметрів операційної системи.
Під порядком файлової системи передбачаються найочевидніші операції, які, як це не дивно виглядає, багатьма адміністраторами вважаються непримінними до серверних операційних систем. Мова йде про:
- перевірці логічної структури диска;
- вилучення тимчасових і непотрібних файлів;
- дефрагментації файлової системи.
Справедливості заради, треба зауважити, що для SSD-дисків дефргаментація дійсно нічого не дає, а тільки збільшує кількість циклів запису. У моєму випадку, після приведення файлової системи до ладу сервер трохи «ожив», але цього все одно було недостатньо.
Я думаю, не потрібно пояснювати, навіщо потрібна антивірусна перевірка і відключення невикористовуваних служб, але нехтувати цим не варто. Подивіться, може були встановлені якісь програми, які зараз вже не потрібні на цьому сервері. Ну і зробіть оновлення системи і програм.
Що стосується оптимальності налаштувань операційної системи, то в моєму випадку був виставлений економний режим електроживлення. Після включення режиму максимальної продуктивності тест Гілева показував задовільні результати, але той конкретний сервер повинен був показувати більш високі результати.
Для з'ясування причин був проведений моніторинг використання ресурсів, хоча з самого початку було зрозуміло, що шукати треба ті процеси, які багато займають дискову підсистему. У моєму випадку найкращим показником став «Довжина черги до диска». Нагадаю, що інші показники були в нормі, вони звичайно трохи змінилися в порівнянні з початковими, але в цілому індикатором так і залишилася довжина черги до диска. Результати моніторингу були очевидні: «розкрадачами» ресурсів виявилися процеси сервера 1С і сервера баз даних.
Рівень служб
У моєму випадку сервер 1с знаходився разом з сервером баз даних MS SQL на одній машині, але апаратна конфігурація сервера цілком забезпечувала їх спільну діяльність, а ось налаштування цих двох служб були зовсім не оптимальними. Цим параметрам присвячено безліч статей, наприклад, ця, тут ми сфокусуємо увагу тільки на тих, що не потребують додаткових вкладень, наприклад, придбання жорсткого диска.
Для сервера MS SQL в кожній базі було збільшено значення параметра авторозширення бази до 500 МБ, оскільки бази 1С є швидкозростаючими. Також був налаштований щоденний план обслуговування, в якому крім створення дампа бази додано оновлення статистики, очищення процедурного кешу і дефрагментація індексів. У моєму випадку, це помітно зменшило кількість операцій запису. В якості додаткових заходів можна порекомендувати щотижня виробляти дефрагментацію бази та реорганізації індексів.
Для сервера 1С було змінено параметри «Кількість ШБ на процес» і «Кількість з'єднань на процес» робочого сервера, перший отримав значення 1, а другий 25. Подібні поради більше схожі на «танці з бубном», але вони дають результат. У розглянутому випадку зміна цих параметрів призвела до значного зменшення операцій читання-запису на сервері, і він запрацював в очікуваному режимі. Тест Гілева також підтвердив приріст продуктивності.
Рівень баз
Зробивши заміри під робочим навантаженням і після виходу користувачів, я зіткнувся з дивним результатом - під навантаженням тест Гілева показував кращі результати, ніж при простому! Було також помічено величезну кількість фонових завдань виконуваних на тестових базах. Тестові бази використовувалися сисадмінами для проведення різних тестових завдань. Я попросив видалити їх - і все стало на свої місця. Чи слід тримати тестові бази на робочому сервері, вирішувати звичайно вам, але краще для цього знайти якесь інше рішення, наприклад, використовувати файловий варіант.
В одній з баз не вдавалося зменшити журнал транзакцій, а в іншої бази не пересвідомлювалися індекси. Для обох випадків є одне просте і ефективне рішення. Перш ніж його описати, слід уточнити, що тут має місце однакове найменування різних об'єктів: бази 1С і бази MS SQL, перші можуть бути не базами MS SQL, а, наприклад, базами PostgreSQL. У свою чергу другі не обов'язково будуть базами для 1С. Виходячи з цього резервні копії баз 1С (dt-файл) можуть бути розгорнуті і на інших СУБД, але ні хто не забороняє вам з цієї ж копії розгорнути на MS SQL. Знімаємо резервні копії баз 1С засобами 1С, після чого видалити 1С-бази з сервера 1С, а потім створити їх знову, заливши вміст з dt-файлу.
Привівши всі бази в порядок, мені вже немає до чого було причепитися: сервер працював рівно, дискова підсистема працювала в штатному режимі, користувачі раділи швидкій роботі в 1с, адміністратори дивувалися як тепер швидко проходять оновлення.
Ув'язнення
Якщо використовувати тільки один рівень для пошуку причин низької продуктивності, то можна залишити без уваги причини, що лежать на інших рівнях, тобто результат буде не досягнутий. Наведений приклад показує, що причин може бути кілька, і кожна з них може лежати на своєму рівні. Сподіваюся, що даний матеріал допоможе комусь побороти проблему низької продуктивності 1С-сервера.
