Жалобы «1С тормозит на сервере» сыплются регулярно: пользователи висят, отчёты строятся часами, сохранение документа занимает полминуты. Хочется сразу что-то «подкрутить» и это худшее, что можно сделать. Сначала диагностика: где именно тормозит и в каких условиях. Без этого любая оптимизация - гадание на кофейной гуще.
Дальше - последовательность шагов: с чего начать, какие системные счётчики смотреть, где искать логи в платформе и СУБД, какие типичные причины встречаются и что с ними делать. Подойдёт сисадмину, который получил жалобу и должен за день локализовать причину.
С чего начать диагностику тормозов 1С
Прежде чем открывать счётчики и логи, уточните жалобу. Тормозит у одного пользователя или у всех? Всегда или только при отчётах? В одной базе или во всех? Без этой конкретики искать причину почти бессмысленно. Зафиксируйте сценарий воспроизведения: какая операция, какая база, в какое время. Если тормозит непостоянно, попросите пользователя сообщить, как только повторится.
Замерьте «до»: загрузка процессора rphost, объём занятой памяти, время выполнения тестовой операции, тест Гилёва. Без этих чисел нечего сравнивать с «после». Не лезьте менять параметры реестра, СУБД и платформы, пока не понятно, где тормоз - случайный твик может ухудшить ситуацию и спрятать настоящую причину. И проверьте очевидное: место на диске, состояние RAID, переполненный журнал транзакций. Часто проблема здесь.
Системные счётчики 1С: с чего начать
Windows: Performance Monitor и Task Manager
Диагностика 1С на Windows начинается со штатных инструментов.
- Task Manager - быстрая проверка. Загрузка rphost (рабочие процессы 1С), sqlservr.exe (MS SQL), ragent.exe и rmngr.exe. Если rphost постоянно держит CPU около 100% - упёрлись в процессор.
- Performance Monitor - детальная диагностика. Счётчики: % Processor Time, Available MBytes (свободная память), Disk Queue Length (очередь к диску), Network Bytes/sec.
- Просадка Page Life Expectancy ниже 300 секунд - памяти СУБД мало, кэш не успевает.
- Event Viewer → System и Application - ошибки от 1С:Платформы, MSSQLSERVER, диска. Часто проблема записывается в журнал до того, как пользователь её замечает.
- Resource Monitor - посмотреть, какой процесс конкретно генерирует IO и сетевой трафик в момент тормозов.
Linux: vmstat, iostat, top и htop
На Linux набор другой, но логика та же - найти, во что упёрлись.
- htop - общая картина: загрузка ядер, память, swap, активные процессы. Подсветка io и d-state процессов сразу подскажет, что блок IO.
- vmstat 5 - динамика: us и sy (CPU user/system), wa (iowait), si/so (swap). Высокий wa - упёрлись в диски, si/so - не хватает памяти.
- iostat -xz 5 по дискам: %util (загрузка), await (среднее ожидание IO), r/s и w/s. %util около 100 - диск перегружен.
- PostgreSQL: pg_top, pg_activity или SELECT * FROM pg_stat_activity. Видно активные запросы, время выполнения, ожидания и блокировки.
- dmesg и /var/log/messages - поискать ошибки железа и драйверов сетевых карт. Бывает, что тормоза - это деградирующий диск или флапающий сетевой интерфейс.
Логи платформы 1С: где искать и что в них смотреть
Технологический журнал 1С - мощный инструмент, но открывать его сразу не нужно. Сначала - более простой журнал регистрации. Открывается через консоль администрирования сервера 1С или через тонкий клиент. Фильтр по «Ошибка» и «Предупреждение» сразу покажет инциденты. «Длительные операции» подсветит события дольше нескольких секунд.
Журнал регистрации до версии платформы 8.3.14 хранится в SQLite, в более новых версиях - в формате .lgd, на крупных базах в обоих случаях он сам становится тормозом. Перевод журнала в хранилище на базе СУБД (SQL Server или PostgreSQL) убирает эту просадку и упрощает диагностику. Дальше идёт собственно технологический журнал: настраивается через logcfg.xml в каталоге conf сервера 1С. События CALL (серверные вызовы), DBMSSQL (запросы к СУБД), EXCP (исключения), TLOCK и TTIMEOUT (блокировки и таймауты). Включать осторожно - тяжёлый журнал быстро забивает диск.
Минимум для диагностики: DBMSSQL, CALL и TLOCK с длительностью от 5–10 секунд, иначе журнал будет неподъёмным. Парсинг - отдельный навык: grep по EXCP и сортировка по длительности, для серьёзного анализа есть утилиты GiliaTorba и Пирамидион. Файлы trace в srvinfo нужны редко, но если падает rphost - причина обычно там.
Логи СУБД: блокировки, длинные запросы, ожидания
После платформенных логов - СУБД: там видны запросы, блокировки и ожидания.
- MS SQL Activity Monitor - встроенный инструмент Management Studio. Показывает активные запросы, заблокированные сессии, длительность. Хватает для типового инцидента.
- Extended Events заменили Profiler в современных версиях SQL Server. Шаблон под долгие запросы и блокировки поднимается за пять минут, нагрузка на сервер минимальная.
- DMV-представления: sys.dm_exec_requests (текущие запросы), sys.dm_os_wait_stats (типы ожиданий), sys.dm_db_index_usage_stats (использование индексов). Один SELECT и понятно, во что упёрся сервер.
- PostgreSQL: pg_stat_activity (что выполняется сейчас), pg_locks (кто кого блокирует), pg_stat_statements (агрегированная статистика по запросам). Расширение pg_stat_statements ставится заранее.
Что искать: долгие запросы, массовые блокировки на одних таблицах, deadlock-и, ожидания PAGEIOLATCH (упёрлись в диск) или LCK_M (блокировки 1С на уровне ИБ). На уровне 1С блокировки видно через журнал регистрации (TLOCK/TTIMEOUT). Связка «таймаут в 1С плюс блокировка в pg_locks или sys.dm_tran_locks» - главный сценарий разбора пользовательских жалоб.
Типичные причины тормозов и быстрые решения
Топ причин и что с ними делать прямо сейчас
- Высокий CPU на rphost, медленные операции у всех пользователей. Проверьте, не идёт ли регламентное задание в рабочее время, сместите тестирование и исправление, реструктуризацию, индексацию на ночь.
- Долгие запросы в DBMSSQL, при этом CPU невысокий. Фрагментированные индексы или устаревшая статистика. Запустите REORGANIZE или REBUILD индексов и UPDATE STATISTICS на нужных таблицах.
- Ожидания PAGEIOLATCH или высокий iowait на Linux. Упёрлись в диск. Проверьте здоровье RAID, перенесите tempdb или PostgreSQL temp_tablespaces на более быстрый диск.
- Массовые блокировки и таймауты в журнале регистрации. Ищите длинные транзакции в коде конфигурации. Отчёты, открывающие весь регистр без отбора - типичный кандидат.
- Тормоза только у удалённых пользователей. Проблема в сети или в тонком клиенте, не в сервере. Проверьте пинг, потери, MTU. Предложите терминальный сервер вместо прямого тонкого.
Когда уже не справиться своими силами
Бывают сценарии, где штатной диагностики не хватает. Проблема стабильно воспроизводится, а логи и счётчики не показывают понятного узкого места, нужны более глубокие методы: трассировка плана выполнения SQL, профайлинг кода 1С. Подозрение на дефект конфигурации - длинная транзакция или неоптимальный запрос, без 1С-разработчика не разберёшь.
Симптомы плавают: «утром норм, в обед легло, к ужину прошло» - похоже на конкуренцию за ресурсы с другими сервисами или виртуалками на хосте. Когда тормоза начались после изменения, но непонятно какого, нужен «свежий взгляд»: обновления Windows, антивируса, версии 1С - вариантов много.
Если симптомы плавают по времени, а логи не дают однозначного ответа, проще привлечь внешний аудит ИТ-инфраструктуры, чем третью неделю крутить параметры наугад: свежий взгляд часто видит то, что замылилось у внутренней команды.
Профилактика: как не доводить до тормозов
Четыре базовых вещи, которые экономят сутки разбора при инциденте.
- Постоянный мониторинг (Zabbix, Prometheus) на CPU, RAM, диск, сеть и счётчики СУБД. Алерты - до жалоб пользователей, не после.
- Регламентные операции 1С на ночь, без исключений. Тестирование и исправление, реиндексация, обновление статистики СУБД.
- Регулярная ревизия конфигурации - раз в полгода смотреть, не появились ли пользовательские отчёты, которые тащат всю базу.
- Журналы и метрики хранить минимум за месяц, иначе после инцидента непонятно, что было до.
Заключение
Тормоза 1С - это симптом, у которого почти всегда есть конкретная причина в логах или счётчиках. Лечить надо причину, а не симптом, и не «по списку оптимизаций». Если по итогам диагностики узкое место - само железо, дальше уже не настройки: замеры стабильно упёрлись в потолок CPU, памяти или диска, и пришло время апгрейда.
Когда диагностика стабильно показывает потолок CPU или диска и оптимизация уже не двигает картину, разумно посмотреть готовые серверы для 1С под текущую нагрузку и спланировать миграцию вместо ещё одного раунда настроек.
