Почему тормозит 1С: 7 частых причин и как их найти

«1С опять тормозит» — фраза, которую слышит любой, кто отвечает за учётную систему в компании. За одной и той же жалобой могут стоять очень разные причины: от устаревшей статистики в базе данных до одной неудачной доработки, из-за которой медленно проводится конкретный документ. Без диагностики легко потратить бюджет не на то — например, купить более мощный сервер, когда узкое место в неоптимальном запросе одного отчёта.

Ниже — семь причин, которые мы чаще всего встречаем в работе, признаки, по которым их можно заподозрить, и замеры, с которых стоит начинать поиск. Речь в основном о клиент-серверном варианте 1С:Предприятия 8 с MS SQL Server или PostgreSQL.

1. Не выполняется регламентное обслуживание базы данных

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

Для MS SQL Server методические материалы 1С рекомендуют регулярно выполнять обновление статистик, очистку процедурного кэша, дефрагментацию индексов и реиндексацию таблиц. В PostgreSQL за актуальность статистики и очистку устаревших версий строк отвечают VACUUM и ANALYZE — важно, чтобы автоочистка была включена и успевала за нагрузкой.

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

2. Тяжёлые отчёты, обработки и фоновые задания

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

Важно: обычный отчёт, как правило, не блокирует данные для остальных пользователей — он мешает им тем, что отнимает ресурсы сервера. Этим такая ситуация отличается от конфликтов блокировок (причина 5).

Признаки: замедление возникает эпизодически и совпадает по времени с запуском определённых отчётов, обработок или фоновых заданий; в эти моменты заметно растёт загрузка сервера СУБД. Расписание регламентных заданий 1С стоит проверить отдельно: обмены и обновление полнотекстового индекса в рабочие часы — частый источник периодических «тормозов».

3. Нехватка ресурсов сервера и настройки СУБД

Растут объём базы и число пользователей, а сервер приложений и сервер СУБД остаются прежними. Нагрузка постепенно перерастает возможности оборудования: процессор работает на пределе в часы пик, дисковая подсистема не успевает обрабатывать запросы, оперативной памяти не хватает для рабочего набора данных.

Отдельная частая проблема — СУБД работает с настройками по умолчанию. Для MS SQL Server 1С в общем случае рекомендует устанавливать параметр max degree of parallelism равным 1. Microsoft рекомендует задавать верхний предел памяти SQL Server (параметр max server memory), чтобы операционной системе и другим приложениям, включая сервер 1С на том же компьютере, хватало памяти. Для PostgreSQL параметры памяти, например shared_buffers и work_mem, тоже стоит настраивать под фактическую нагрузку.

Признаки: процессор подолгу загружен до предела, к дискам выстраивается длинная очередь, операционная система активно использует файл подкачки; медленнее работает всё подряд, и сильнее всего — в часы наибольшей нагрузки. При этом высокий объём занятой памяти на сервере MS SQL сам по себе не признак нехватки: при нормальной работе SQL Server занимает память вплоть до заданного предела. В отличие от блокировок (причина 5), здесь сервер действительно перегружен.

4. Сеть и удалённый доступ

Если часть сотрудников работает через тонкий клиент по интернету или через удалённый рабочий стол, ощущение «тормозов» бывает связано не с базой, а с удалённым доступом: узкий или нестабильный канал связи, перегруженный терминальный сервер, неудачные настройки подключения.

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

Признаки: жалобы приходят от конкретных удалённых пользователей или филиалов, а у сотрудников в офисе та же операция выполняется быстро. Для проверки полезно сравнить время одной и той же операции у локального и удалённого пользователя.

5. Блокировки при одновременной работе

Чтобы данные не противоречили друг другу, во время транзакции — например, при проведении документа — изменяемые данные блокируются, и другие пользователи, которым нужны те же данные, ждут. Если блокируется больше данных, чем нужно, пользователи начинают «упираться» друг в друга, особенно при массовом проведении документов, например при закрытии месяца.

Ширина блокировок зависит от того, как устроены регистры и алгоритмы проведения. Отдельный случай — конфигурации, работающие в автоматическом режиме управления блокировками (например, 1С:УПП): в нём блокировки, как правило, шире, чем в управляемом режиме, который используют современные типовые решения.

Признаки: пользователи получают сообщения, которые начинаются со слов «Конфликт блокировок при выполнении транзакции» (дальше текст зависит от режима блокировок и СУБД), встречаются взаимоблокировки. При этом загрузка сервера может быть невысокой: пользователи ждут не ресурсов, а друг друга.

6. Устаревшая платформа и конфигурация

В новых версиях платформы 1С:Предприятие нередко появляются оптимизации производительности, а в релизах типовых конфигураций — исправления медленных мест. Если компания годами не обновляется, чтобы «не трогать то, что работает», она может мириться с проблемами, которые в новых версиях уже исправлены.

При этом обновление требует затрат. Для получения обновлений нужен действующий договор 1С:ИТС; обновление доработанной конфигурации требует объединения изменений и тестирования; часть оптимизаций платформы начинает работать только после смены режима совместимости конфигурации.

Признаки: версия платформы и релиз конфигурации заметно отстают от актуальных; конфигурация работает в старом режиме совместимости; в описаниях изменений новых версий упоминается исправление именно той проблемы, с которой вы сталкиваетесь.

7. Доработки, которые нагружают систему

Накопленные за годы доработки — особенно сделанные разными подрядчиками без общей архитектуры — одна из частых причин снижения производительности. Нестандартная логика не обязательно живёт в отдельных документах: она может находиться в подписках на события, расширениях и изменённых модулях типовых объектов. Дублирующие друг друга обработчики, лишние проверки при записи и «тяжёлые» действия при открытии форм накапливаются незаметно.

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

Как искать причину: сначала замеры

Перебирать причины по одной долго и дорого. Диагностику лучше начинать с объективных данных:

• замер показателя APDEX по ключевым операциям — методика, которую 1С рекомендует для оценки производительности (в конфигурациях на основе Библиотеки стандартных подсистем для этого есть подсистема «Оценка производительности»). Замеры нужно включить и задать целевое время операций; APDEX показывает, где пользователям плохо, но не объясняет почему;
• технологический журнал платформы, если его настроить (файл logcfg.xml), — в нём видны длительные запросы к СУБД, ожидания и таймауты блокировок, взаимоблокировки;
• проверка регламентного обслуживания СУБД — когда и с каким результатом последний раз выполнялись операции из причины 1;
• мониторинг загрузки серверов СУБД и 1С в течение нескольких дней, а не в момент единичной жалобы;
• расписание регламентных и фоновых заданий 1С.

Итог

«Тормозит 1С» — это симптом, а не диагноз. За ним может стоять одна причина или несколько сразу, и без замеров легко выбрать не те меры: купить новый сервер, когда пользователи ждут друг друга на блокировках, или заказать доработку, когда достаточно наладить обслуживание СУБД. Сбор данных занимает время, но позволяет выбирать меры по фактам, а не наугад.

Если 1С стала работать медленнее, а причина не очевидна, — напишите нам: подскажем, с каких замеров начать, и поможем найти узкое место.

Источники

• Регламентные операции на уровне СУБД для MS SQL Server — методические материалы 1С:ИТС для разработчиков и администраторов — its.1c.ru
• Настройка параметра max degree of parallelism при выполнении реструктуризации информационной базы (включая общую рекомендацию для рабочего режима) — методические материалы 1С:ИТС — its.1c.ru
• Методика расследования ошибок блокировок — методические материалы 1С:ИТС — its.1c.ru
• Оценка производительности и оптимизация многопользовательской системы: общий подход — методические материалы 1С:ИТС — its.1c.ru
• Параметры конфигурации памяти сервера — Microsoft Learn, «Server memory configuration options» — learn.microsoft.com
• Регулярная очистка базы данных (VACUUM, ANALYZE) — документация PostgreSQL, «Routine Vacuuming» — postgresql.org