Ситуация, когда сервер 1С внезапно начинает потреблять 100% ресурсов процессора при низкой загрузке оперативной памяти, является классической проблемой для связки 1С:Предприятие 8.3 и SQL Server 2014. Особенно критично это проявляется в базах с большим количеством активных пользователей (от 100 и выше), где любая задержка приводит к эффекту «снежного кома». Разберем подробно, почему это происходит и как вернуть систему в рабочее состояние.
Проанализируем ситуацию: сервер работает нормально первые 20 минут после перезагрузки, а затем процессор уходит в «полку» на 100%. Это явный признак того, что проблема не в аппаратной части, а в накопительном эффекте неоптимальных запросов или сбоях в системных механизмах. Основным потребителем ресурсов в данном случае выступает процесс sqlservr.exe.
Первым делом нам необходимо выяснить, какой именно запрос или процесс внутри SQL вызывает такую нагрузку. Для этого рассмотрим использование встроенных инструментов мониторинга. Запустим SQL Server Profiler (вызывается через Ctrl+Alt+A в SQL Management Studio) или воспользуемся стандартным монитором активности. Нам нужно обратить внимание на колонку CPU и Duration. Если мы видим повторяющиеся тяжелые запросы к таблицам Config или ConfigSave, значит, мы столкнулись с последствиями так называемого «демонического» (динамического) обновления.
Рассмотрим подробнее механизм динамического обновления. Программисты часто используют его, чтобы не выгонять 200 пользователей из базы. Однако в 1С 8.3 этот механизм иногда дает сбой. В таблицах конфигурации SQL Server могут появиться записи, которые заставляют систему бесконечно перечитывать метаданные, что и вызывает 100% нагрузку на CPU.
Как вылечить последствия динамического обновления:
DBCfgEvnts. В некоторых случаях помогает только выгрузка информационной базы в формат .dt и ее последующая загрузка в новую чистую базу SQL.Config через SQL-запросы, но это крайне рискованная операция, требующая предварительного создания бэкапа.Важный совет: Постараемся полностью отказаться от динамических обновлений на крупных продуктивных базах. В 99% случаев изменения могут подождать технологического окна (ночного времени), когда всех пользователей можно выгнать и обновить конфигурацию корректно.
Выясним причину, специфичную именно для версии SQL Server 2014. В этой версии Microsoft внедрила новый механизм оценки планов запросов — Cardinality Estimator. Для логики 1С этот механизм часто работает некорректно, выбирая крайне тяжелые планы для простых операций.
Рассмотрим, как это исправить. Попробуем переключить уровень совместимости базы данных на предыдущую версию (SQL Server 2012 — уровень 110). Это заставит оптимизатор использовать старые, проверенные алгоритмы. Также можно применить флаг трассировки 9481, который отключает новый оценщик для всех запросов.
Другой критический параметр — MAXDOP (Maximum Degree of Parallelism). Проанализируем настройки вашего SQL-сервера. Если MAXDOP установлен в 0, SQL Server пытается распараллелить каждый запрос на все доступные ядра процессора. Для 1С это губительно. Установим значение MAXDOP = 1. Это гарантирует, что один тяжелый отчет одного пользователя не парализует работу всей системы, захватив все ресурсы CPU.
Также проверим параметр Cost Threshold for Parallelism. Если вы все же решите оставить параллелизм включенным (например, MAXDOP = 4 на многоядерном сервере), поднимите значение Cost Threshold со стандартных 5 до 50. Это предотвратит попытки сервера распараллеливать мелкие запросы, на управление которыми уходит больше ресурсов, чем на само выполнение.
Посмотрим на ситуацию со стороны фоновых задач. Часто тормоза вызваны тем, что в других базах на том же сервере, где «никто не сидит», продолжают работать регламентные задания. Проанализируем консоль администрирования кластера 1С. Выполним следующие действия:
rphost не «раздуты». Настроим автоматическую перезагрузку рабочих процессов в консоли кластера 1С при достижении ими определенного порога памяти или раз в сутки.Проанализируем системные настройки Windows и BIOS. Часто серверы по умолчанию работают в режиме Balanced Power (сбалансированное электропитание). Это приводит к тому, что процессор постоянно меняет тактовую частоту, создавая микрозадержки, которые в 1С превращаются в «жуткие тормоза». Установим режим High Performance (высокая производительность) на уровне BIOS и в настройках электропитания Windows.
Для оптимизации работы TempDB (временной базы данных SQL), которая активно используется 1С для временных таблиц, применим следующие рекомендации:
TempDB на несколько файлов данных равного размера (обычно по количеству ядер процессора, но не более 8).T1118, который помогает избежать конкуренции за страницы распределения в TempDB.T4199, который активирует все последние исправления оптимизатора запросов Microsoft.Разберем по шагам план спасения сервера, если он «вешается»:
DBCC FREEPROCCACHE. Это даст временную передышку, сбросив плохие планы запросов.Config — планируем монопольное обновление.MAXDOP = 1 и проверим режим электропитания сервера.9481.Соблюдение этих рекомендаций позволит стабилизировать работу системы и убрать пиковую нагрузку на процессор, обеспечив комфортную работу пользователям даже в условиях высокой нагрузки.