Чому 1С/BAS повільно працює

З чого починати: три питання

Найпоширеніша помилка — одразу купувати потужніший сервер. У більшості випадків це не допомагає, бо вузьке місце було не в процесорі. Перш ніж щось міняти, дайте відповідь на три питання — вони одразу відсікають половину варіантів.

• Повільно у всіх чи в однієї людини? Якщо в однієї — справа в її комп'ютері, мережі або правах. Якщо у всіх — у базі, сервері чи мережі загалом.
• Повільно завжди чи в певний час? Гальмує після обіду — схоже на накопичення сеансів або на регламентні завдання. Гальмує вранці — можливо, уночі не завершилося обслуговування.
• Повільно все чи одна конкретна дія? Один звіт формується десять хвилин, а решта літає — проблема в самому звіті, а не в системі.

1. Файлова база, яку відкривають через мережу

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

Симптом: у того, хто сидить за комп'ютером з базою, все швидко, а в решти повільно. Особливо помітно на звітах і журналах документів.

Рішення: перехід на клієнт-серверний режим із СУБД. Це найдорожча зміна зі списку, але й найрадикальніша: різниця для бази на кілька гігабайт відчувається одразу. Проміжний варіант — термінальний сервер, коли всі працюють на одній машині через віддалений робочий стіл, а мережею йде тільки картинка.

2. Базу роками ніхто не обслуговував

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

Симптом: система деградувала поступово, за рік-два, без різкого моменту «стало погано».

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

3. Розрослий журнал реєстрації

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

Як перевірити: подивіться розмір каталогу журналу реєстрації в папці бази. Кілька гігабайт — це вже проблема.

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

4. Диск, а не процесор

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

Як перевірити: у диспетчері завдань подивіться, що завантажене на сто відсотків під час повільної операції. Якщо диск — причина знайдена.

Рішення: SSD під базу й під файли СУБД. Оперативної памʼяті має бути достатньо, щоб база вміщалася в кеш — це друге за важливістю після диска.

5. Один поганий звіт або обробка

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

Симптом: «як тільно Оля формує свій звіт, у всіх усе стає».

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

6. Блокування: усі чекають одного

Коли хтось проводить документ або запускає закриття місяця, система блокує частину даних, щоб не було суперечливих записів. Якщо операція довга, решта стоїть у черзі. Зовні виглядає як «зависла база», хоча технічно все працює за правилами.

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

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

7. Антивірус, який перевіряє файли бази

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

Рішення: додати каталоги бази, тимчасових файлів і файлів СУБД у винятки антивірусу. Це стандартна практика, а не порушення безпеки.

8. Сеанси, які ніхто не закрив

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

Симптом: зранку швидко, до вечора нестерпно, після перезапуску сервера знову нормально.

Рішення: налаштувати автоматичне завершення неактивних сеансів і перезапуск робочих процесів за розкладом уночі.

У якому порядку це перевіряти

Порядок нижче побудований за принципом «дешево й швидко спочатку». Не варто починати з покупки сервера, поки не пройдені перші чотири пункти.

Якщо пройшли список і швидшої роботи не побачили — напишіть, подивлюся вашу базу. Часто причина виявляється в конкретному доопрацюванні, яке колись зробили «щоб працювало», і про яке вже ніхто не помʼятає.