Ситуация, когда стабильно работающая система 1С:Управление торговлей 11 (УТ 11) внезапно начинает «тормозить» без видимых причин, знакома многим администраторам. Особенно неприятно, когда ресурсы сервера (процессор, оперативная память 32 Гб и более, SSD-диски) кажутся свободными, а простые операции, такие как открытие накладной, занимают 10–15 секунд. Перезагрузка сервера временно решает проблему, но это лишь борьба с симптомами, а не с причиной. В этой статье мы подробно разберем, как выявить источник проблем и настроить систему для стабильной работы.
Первым делом нам необходимо понять, что происходит на стороне СУБД в момент замедления. Перезагрузка сервера очищает кэши и сбрасывает планы запросов, поэтому она помогает, но лишает нас возможности провести диагностику. Вместо перезагрузки, когда система «встала», выполним следующие шаги.
Запустим SQL Server Management Studio (SSMS) и откроем Монитор активности (Activity Monitor). Нас интересуют два раздела: «Активные ресурсоемкие запросы» и «Последние ресурсоемкие запросы». Проанализируем колонки CPU (ms/sec) и Logical Reads/sec. Если мы видим запрос, который потребляет аномально много ресурсов, мы можем получить его текст и понять, какая операция в 1С его породила.
Часто причиной внезапных тормозов становится эффект Parameter Sniffing. Это ситуация, когда SQL-сервер строит план выполнения запроса, основываясь на первом наборе параметров, и этот план оказывается крайне неэффективным для всех последующих вызовов. Проверим эту гипотезу: в момент тормозов выполним команду очистки процедурного кэша для конкретной базы:
-- Очистка кэша планов для текущей базы данных
DECLARE @DBID INT = DB_ID();
DBCC FLUSHPROCINDB (@DBID);
Если после выполнения этой команды скорость работы 1С мгновенно восстановилась — мы нашли причину. В этом случае следует обратить внимание на настройки статистики и флаги трассировки SQL (например, флаг 4199).
Одной из скрытых причин «клина» системы в УТ 11 является механизм полнотекстового поиска. В современных конфигурациях 1С поиск в динамических списках (списки документов, справочники) часто завязан на индекс ППД. Если индекс поврежден или регламентные задания по его обновлению работают некорректно, система может уходить в глубокую задумчивость при попытке любого пользователя что-то найти.
Рассмотрим порядок действий для проверки ППД:
ПолнотекстовыйПоиск.ОчиститьИндекс();
ПолнотекстовыйПоиск.ОбновитьИндекс(Истина); // Истина - полное обновление
Важно настроить регламентные задания ОбновлениеИндексаППД (каждые 1-5 минут) и СлияниеИндексаППД (раз в сутки ночью), чтобы избежать деградации производительности.
Посмотрим на настройки самого SQL Server. Ошибка многих администраторов — оставлять параметр Max Degree of Parallelism (MAXDOP) в значении "0" (по умолчанию). В этом режиме SQL Server пытается распараллелить один тяжелый запрос на все доступные ядра процессора. Для 1С, которая генерирует множество коротких запросов, это губительно: накладные расходы на управление потоками превышают пользу от параллелизма.
Рекомендуется установить MAXDOP = 1 для большинства систем на базе 1С. Если ядер очень много (больше 16), можно попробовать значение 2 или 4, но только при условии настройки Cost Threshold for Parallelism в значение не менее 50. Это исключит ситуацию, когда один неоптимальный отчет «вешает» весь сервер, забивая очередь процессора.
Объем оперативной памяти 32 Гб для сервера, где одновременно работают SQL и сервер приложений 1С с конфигурацией УТ 11.4, является пограничным. Процессы rphost имеют тенденцию накапливать память (утечки), особенно при выполнении тяжелых фоновых заданий или работе с большими табличными частями.
Проанализируем настройки кластера 1С. Вместо перезагрузки всего сервера настроим автоматический перезапуск рабочих процессов:
Это позволит платформе 1С самостоятельно «мягко» перезапускать процессы rphost, когда они становятся слишком прожорливыми, не прерывая работу пользователей.
Разберем еще одну частую причину внезапных тормозов — новый формат журнала регистрации на базе SQLite (файл 1cv8.lgd). При достижении размера в несколько десятков гигабайт любая запись в журнал (а 1С пишет туда почти каждое действие) начинает вызывать блокировки операционной системы на уровне файлового ввода-вывода.
Выясним размер файла журнала в папке srvinfo. Если он критический, выполним сокращение журнала:
Также проверим, не включено ли версионирование объектов для всех документов подряд. Если пользователь открывает «Технические сведения» в истории версий, платформа может начать сканировать огромные массивы данных в журнале регистрации, что «положит» дисковую подсистему даже на SSD.
Если сервер приложений 1С и MSSQL установлены на одной физической машине, обязательно проверим использование протокола Shared Memory. Это позволяет процессам обмениваться данными через оперативную память, минуя сетевые протоколы. Настройку нужно выполнить в SQL Server Configuration Manager в разделе Client Protocols.
Напоследок проверим схему электропитания Windows Server. По умолчанию там часто стоит «Сбалансированная». Это приводит к тому, что процессор снижает частоту в моменты коротких простоев. Когда от 1С приходит пакет запросов, процессору требуется время на «прогрев», что субъективно воспринимается пользователями как «фризы» на 1–2 секунды. Установим режим «Высокая производительность» (High Performance) как в ОС, так и в настройках BIOS сервера (отключив C-states).
Подводя итог, можно сказать, что внезапные тормоза — это всегда следствие накопления очереди ожиданий (на диске, на процессоре или на блокировках). Систематический мониторинг через Activity Monitor и регламентное обслуживание базы (индексы, статистика, ППД) позволяют избавиться от необходимости ежедневных перезагрузок.