Тормозит 1С на сервере: что проверить и в каком порядке

Чаще всего на медленную 1С отвечают покупкой более мощного сервера. Деньги уходят, а проведение документа занимает те же сорок секунд. Причина обычно в другом: в запросе, который читает всю таблицу, в настройках СУБД по умолчанию или в одном «тяжёлом» регламентном задании, которое запускается днём.

Чтобы ускорить работу 1С на сервере, сначала измерьте, где именно теряется время, и только потом меняйте настройки. Ниже порядок действий от безопасных к тем, что требуют остановки сервера. Речь о клиент-серверной базе на платформе 8.3 с интерфейсом «Такси», где СУБД — Microsoft SQL Server или PostgreSQL.

Сначала измерьте: где база тратит время

Без цифр любая «оптимизация» превращается в гадание. Понадобятся три источника.

1. Журнал регистрации. Он открывается из раздела Администрирование (в конфигурациях на БСП ищите команду «Журнал регистрации»). Отфильтруйте события по уровню «Ошибка» и «Предупреждение» за последние сутки. Повторяющиеся таймауты блокировок и ошибки фоновых заданий — первые кандидаты на разбор.
2. Замеры производительности. В типовых конфигурациях есть подсистема оценки производительности с показателем APDEX. Она фиксирует время выполнения ключевых операций и показывает, какие из них проседают. Если подсистема отключена, включите её на неделю: нужна динамика, а не разовый снимок.
3. Технологический журнал. Это текстовые логи платформы. Настраиваются файлом logcfg.xml в каталоге conf рядом с установленной платформой. Для поиска долгих запросов хватает событий DBMSSQL (для PostgreSQL — DBPOSTGRS) с порогом длительности, а для блокировок — событий TLOCK и TTIMEOUT.

Параллельно посмотрите на сервер как на железо: загрузка процессора, очередь к диску, свободная память. Монитор ресурсов Windows или top и iostat в Linux покажут, что упирается — процессор, память или диск. От ответа зависит, какой из следующих разделов вам нужен.

Индексы и структура базы: что чинится без железа

Платформа 1С сама создаёт индексы под таблицы конфигурации, но на практике ломается обслуживание, а не структура.

Статистика и перестроение индексов. Планировщик СУБД выбирает план запроса по статистике. Устаревшая статистика — классическая причина, когда вчера отчёт строился минуту, а сегодня двадцать. Для MS SQL Server настройте задания обслуживания: обновление статистики по всем таблицам ежедневно ночью, реорганизация или перестроение сильно фрагментированных индексов раз в неделю. Для PostgreSQL то же делают ANALYZE и VACUUM (автовакуум включён по умолчанию, но на больших базах его параметры стоит подкрутить).

Тяжёлые запросы в своих доработках. Если тормозит конкретный отчёт или форма, а остальное летает, дело в запросе. Типичные причины:

• соединение с подзапросом в условии вместо временной таблицы;
• условие по полю без индекса или с функцией над полем;
• выборка всех реквизитов, когда нужны два;
• запрос в цикле — по одному обращению к базе на каждую строку документа.

Исправляет такое программист, но находите вы: технологический журнал укажет модуль и строку.

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

Параметры сервера 1С:Предприятия: кластер и рабочие процессы

Сервер 1С — это агент (по умолчанию порт 1540), менеджер кластера (1541) и рабочие процессы, диапазон портов которых задаётся в свойствах рабочего сервера. Настройки по умолчанию подходят для небольшой базы, но не для сотни пользователей.

Что стоит проверить в консоли администрирования серверов (свойства кластера и рабочего сервера):

• Количество рабочих процессов. Один процесс на сорок-пятьдесят активных сеансов — разумная отправная точка. Слишком мало: процессы упираются в память. Слишком много: растут накладные расходы.
• Допустимый объём памяти рабочих процессов. Когда процесс превышает лимит, он помечается на перезапуск. Если лимит занижен, процессы перезапускаются слишком часто, и пользователи теряют сеансы.
• Интервал перезапуска. Рабочие процессы 1С со временем «раздуваются». Плановый перезапуск раз в сутки ночью — обычная практика.
• Проблемные процессы. Настройте, чтобы зависшие процессы завершались автоматически.

Отдельно проверьте версию платформы. Разница между старым релизом и актуальным на одной и той же базе бывает заметной, особенно в работе с блокировками и памятью. Обновляйте платформу на тестовой копии и сравнивайте время ключевых операций.

А вот чего делать не стоит: «пересоздавать кластер» ради ускорения. Лишняя работа и риск потерять настройки публикаций и списки баз.

Тонкая настройка СУБД под 1С

Здесь выигрыш бывает самым большим, потому что стандартные настройки СУБД рассчитаны на универсальную нагрузку.

Microsoft SQL Server

Автоматическое сжатие и автоувеличение файлов на малый шаг отключите: база сжимается и растёт десятками мелких кусков, диск фрагментируется. Размер файлов задавайте с запасом вручную.

PostgreSQL

Для PostgreSQL используйте сборку, рекомендованную для 1С, — со специальными патчами. Базовые параметры: shared_buffers порядка четверти ОЗУ, effective_cache_size около 70% ОЗУ, work_mem умеренный (он выделяется на операцию, а не на сеанс — не завышайте), max_connections без избытка. Точные значения подбирайте под ваше железо, а не копируйте из чужих конфигураций.

Уровень изоляции и блокировки

Если в журнале много TLOCK/TTIMEOUT, дело в блокировках на уровне 1С. Проверьте режим управления блокировками данных: управляемый режим снижает конфликты по сравнению с автоматическим. Для конфигураций, которые давно работают в автоматическом режиме, переход выполняется в конфигураторе — это работа для программиста, а не для администратора.

Железо, диск и память под базу

Если цифры из первого раздела показали, что упираетесь в ресурсы, действуйте так.

Диск — главное. Для базы и tempdb нужен SSD, лучше NVMe. Журнал транзакций держите на отдельном томе: запись в него последовательная, и смешивать её со случайным чтением данных незачем. Ориентир по задержке: средняя задержка чтения и записи на томе с базой — единицы миллисекунд. Если счётчик показывает десятки, диск — ваше узкое место.

Процессор. Для сервера 1С важна частота ядра, а не их число. Операции проведения и многие запросы выполняются в один поток. Поэтому восьмиядерный процессор на 4 ГГц нередко обгоняет шестнадцатиядерный на 2,2 ГГц.

Память. Ориентир: сервер СУБД должен вмещать «горячую» часть базы в оперативную память. Если база занимает 200 ГБ, а активно читается пятая часть, под СУБД нужно 40–64 ГБ. Сервер приложений 1С считайте отдельно: по несколько сотен мегабайт на рабочий процесс плюс запас.

Виртуализация. В виртуальной машине зарезервируйте память и процессор под гостя, не допускайте «перепродажи» ресурсов. План электропитания в Windows поставьте в режим высокой производительности: по умолчанию ядра могут снижать частоту, и это заметно на однопоточных операциях.

Антивирус. Исключите из проверки каталоги данных СУБД, каталоги сервера 1С и каталог технологического журнала. Антивирус, проверяющий каждый файл базы, замедляет сервер заметно.

Клиентские места и сеть

Если тормозит только у части пользователей, начинайте с клиента.

1. Кэш. Папки временных файлов клиента (%LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8) со временем разрастаются. Закройте 1С и очистите кэш — штатно это делается запуском с параметром /ClearCache или удалением содержимого каталогов с именами из GUID.
2. Режим запуска. Тонкий клиент работает быстрее толстого. Толстый клиент нужен только для редких операций.
3. Сеть. Между клиентом и сервером важна задержка, а не пропускная способность. Для работы по VPN или через интернет с высоким пингом используйте терминальный сервер : клиент 1С запускается рядом с сервером, а пользователь получает только картинку.
4. Терминальный сервер. Для 20–30 пользователей на одном сервере приложений закладывайте 1–2 ГБ ОЗУ на сеанс и контролируйте число одновременных запусков.
5. Веб-клиент и публикация. Если используете веб-доступ, проверьте, что публикация настроена с сжатием на веб-сервере, а на самом сервере не включено подробное журналирование.

Регламентные операции и фоновые задания

Фоновые и регламентные задания выполняются на том же сервере, что и работа пользователей, и порой съедают его днём.

Что проверить:

• Расписание. Откройте в разделе Администрирование список регламентных заданий и найдите те, что выполняются днём и долго. Загрузка курсов, обновление индексов полнотекстового поиска, групповое проведение, обмены с другими базами — всё это лучше сдвинуть на ночь.
• Полнотекстовый поиск. Если он включён, но не нужен, отключите. Если нужен — следите, чтобы слияние индексов не шло в рабочие часы.
• Обмены. Обмены, которые запускаются каждые две минуты и каждый раз обходят всю таблицу изменений, создают постоянную фоновую нагрузку. Увеличьте интервал или перейдите на обмен по событию.
• Закрытие месяца . Блокируйте на это время плановые операции, чтобы не получать ожидания на блокировках в самый ответственный период.
• Резервное копирование . Копию делайте ночью, а не в течение дня. Если копирование идёт в рабочее время, задержки по диску заметят все.

Когда ускорять не нужно

Не всякая медленная операция — проблема сервера.

• Закрытие месяца и перепроведение документов за год по определению тяжелы. Их ускоряют разбиением по периодам и запуском ночью, а не тюнингом СУБД.
• Если база небольшая, пользователей меньше десяти и они не жалуются, оптимизировать нечего. Лучше потратить время на резервное копирование.
• Если тормозит один отчёт, а его автор — внешний подрядчик, настройки сервера ничего не изменят. Нужен разбор запроса.

Частые вопросы