Почему 1С тормозит на сервере: как по симптомам понять “узкое место”

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

Ниже — практический чек-лист, который помогает быстро понять, что именно ограничивает производительность, и как это подтвердить.

Сначала уточняем «где болит»: всё или конкретно?

Один и тот же «тормоз» на стороне пользователя может означать разные уровни проблемы. Разделите жалобу на два типа:

• «Тормозит всё» (у многих и сразу). Если интерфейс, проведение, отчёты и любые действия становятся медленнее у большинства пользователей одновременно — это чаще всего инфраструктура или база: CPU/RAM/диск/сеть/СУБД.
• «Тормозит конкретное» (один отчёт/проведение/операция, часть пользователей). Если «падает» одна операция или у одной группы пользователей — это часто прикладное: тяжёлые запросы, неудачный алгоритм, долгие транзакции, конкуренция за ресурсы, блокировки.

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

Быстрая шпаргалка: симптомы → вероятное узкое место

CPU (процессор)

• Как проявляется: подвисания рывками, деградация пропорционально росту числа пользователей, «всем стало медленно» в одно и то же время.
• Что подтверждает: высокая загрузка CPU, рост очереди процессора, перекос нагрузки по ядрам (одно ядро «в потолок»).
• Типичные причины: пики активности, регламентные задания/обмены/отчёты, «тяжёлый» сеанс или процесс.

RAM (оперативная память)

• Как проявляется: после перезапуска «нормально», потом всё медленнее; задержки без явных пиков CPU.
• Что подтверждает: мало свободной RAM, появляется подкачка/пейджинг (ОС начинает «тасовать» память на диск).
• Типичные причины: раздувание рабочих процессов 1С (например, rphost), неудачное распределение процессов, накопительный эффект нагрузки.

Диск (I/O)

• Как проявляется: «замирания» на секунды при записи/проведении; ухудшение во время бэкапов, антивируса, снапшотов, регламентов.
• Что подтверждает: рост времени чтения/записи (latency), рост очередей диска, нехватка свободного места на разделах.
• Типичные причины: медленное хранилище/перегруженный RAID/виртуализация, смешивание потоков (логи/БД/темпы) на одном диске.

Сеть

• Как проявляется: удалённым пользователям плохо, в офисе терпимо; задержки «плавают»; зависимость от VPN/канала.
• Что подтверждает: пики трафика на интерфейсах, ошибки/потери, нестабильная задержка (RTT).
• Типичные причины: узкий канал, перегруженный VPN, проблемы маршрутизации/провайдера, конкуренция с другими сервисами.

СУБД (ожидания, блокировки, «узкие места» базы)

• Как проявляется: «то встаёт, то отпускает»; отдельные операции иногда резко замедляются; пики в закрытие месяца.
• Что подтверждает: рост ожиданий (waits), блокировки и взаимоблокировки, долгие транзакции, конкуренция за одни и те же объекты.
• Типичные причины: неудачные планы выполнения, нехватка индексов, длинные транзакции в прикладном коде, конфликты массовых операций.

Как отличить «не хватает железа» от «тормозит из-за конкретной операции»

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

Типовой алгоритм диагностики

• Зафиксируйте окно проблемы: когда пользователи жалуются (минуты/часы) и насколько массово.
• Проверьте инфраструктуру в эти минуты: CPU (очередь/ядра), RAM (свободная/подкачка), диск (время и очереди), сеть (пики).
• Если инфраструктура «чистая» — переходите на слой 1С: время отклика/обращений, распределение ресурсов по сеансам, «кто грузит».
• Если видно, что 1С «ждёт» — идите в СУБД: ожидания, блокировки, долгие транзакции.
• После исправлений измеряйте эффект теми же метриками (иначе невозможно доказать результат).

Как Metrika42 помогает найти проблемы быстрее (и связать симптомы с причиной)

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

1) Сводный дашборд: понять масштаб и момент деградации

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

Рисунок 1 — Сводный дашборд: статус, доступная производительность, сеансы и базовые ресурсы

2) «Серверы»: быстро определить узкое место CPU/RAM/диск/сеть

Следующий шаг — локализовать «узкое горлышко» инфраструктуры. В разделе «Серверы» удобно смотреть нагрузку CPU по ядрам и длину очереди процессора (часто это честнее, чем «средний % CPU»), графики RAM (процент и свободная память), диск (заполненность разделов, время чтения/записи, очереди), сеть (загрузка интерфейсов). По сути, вы проходите по статье: подозреваете CPU — проверяете очередь и ядра; подозреваете диск — смотрите latency/очереди; подозреваете сеть — видите пики по интерфейсу.

Рисунок 2 — «Серверы»: ядра/очередь CPU, RAM, диск (очереди/время), сеть

3) «Состояние сервера 1С»: найти «кто тормозит» по сеансам и пользователям

Если инфраструктура выглядит нормально или нужно разобраться с точечными замедлениями, важно перейти на уровень самой 1С. В «Состоянии сервера 1С» видно время обращения сеанса к серверу и распределение утилизации ресурсов по сеансам — это помогает быстро заметить «шумного соседа» (конкретного пользователя/процесс), который в момент жалоб съедает CPU/память или вызывает всплески активности.

Рисунок 3 — «Состояние сервера 1С»: время обращения сеансов и утилизация ресурсов по сессиям

4) Контроль процессов 1С: увидеть раздувание и накопительную деградацию

Для кейсов «после перезапуска нормально, потом хуже» полезно смотреть потребление ресурсов ключевыми процессами 1С (rphost, rmngr, ragent и т. п.). Это помогает отличить нормальную нагрузку от ситуации, когда процессы разрастаются и система начинает «спотыкаться».

Итог

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