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

Сервер 1С обычно замечают только тогда, когда пользователи уже жалуются, а ситуация к этому моменту стоит ремонта на горящем: переработки, недовольство, срочный бюджет. Регулярный аудит сервера 1С - спокойный взгляд на цифры до жалоб. Он отвечает на простой вопрос: хватает ли серверу ресурсов под реальную нагрузку, или запас уже подъеден.

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

Пять поводов запустить проверку - каждый из них момент, когда цифры важнее ощущений.

1. Регулярно - раз в год, для крупных инсталляций раз в квартал. Парк живёт долго, нагрузка растёт постепенно, запас уходит молча.

2. Перед сезонным пиком - отчётностью, инвентаризацией, концом финансового года. Если сейчас сервер на грани, в пик он ляжет. Замерить заранее дешевле, чем потом восстанавливать.

3. После крупных изменений - обновление платформы, новые подсистемы, рост числа пользователей, новый филиал. Любое из этих событий смещает профиль нагрузки, и старые нормы перестают работать.

4. При обсуждении бюджета на следующий год. Цифры аудита - главный аргумент за или против апгрейда. Без них разговор с финдиректором - спор по ощущениям.

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

Нагрузка на сервер 1С раскладывается на четыре ресурса, с CPU обычно начинают - процессор первым показывает потолок. Смотрим среднюю и пиковую загрузку rphost (рабочие процессы 1С), sqlservr.exe (MS SQL) или postgres (PostgreSQL). Здоровый сервер держит пик не выше 70–80% даже в рабочий час.

Если CPU rphost постоянно у 100% - упёрлись в потолок. Любая новая нагрузка приведёт к деградации, дальше только апгрейд или оптимизация регламентных заданий.

По памяти - процент использования RAM и объём свопа. Активный своп в Windows или si/so в Linux выше сотен страниц в секунду - память расширять, это самый дешёвый апгрейд. Для MS SQL - Page Life Expectancy: меньше 300 секунд значит, что кэш мал и СУБД перечитывает с диска. Для PostgreSQL - shared_buffers против реальной памяти и buffer cache hit ratio через pg_stat_database.

Эти две зоны чаще всего упускают, и в них прячется большая часть «непонятных» тормозов. По дискам - глубина очереди (Disk Queue Length) и задержки чтения и записи. Очередь стабильно выше 2 на диск - узкое место. Average Disk sec/Read и Write больше 20 мс - диски не справляются, пора в сторону NVMe.

На Linux эквивалент - %util и await в iostat: %util около 100 - диск перегружен, await выше 20 мс - то же. По сети - загрузка канала между сервером 1С и СУБД, если они на разных машинах. Стабильная загрузка выше 60% на гигабите - пора в сторону 10 Gb. На томах с данными и журналами СУБД держим минимум 20% свободного места, иначе производительность падает.

Оценка производительности 1С не сводится к системным счётчикам, платформа сама собирает много данных, читать их полезно вместе с CPU, памятью и дисками. Журнал регистрации открываем через консоль администрирования, фильтруем по «Ошибка», «Длительные операции», «Таймаут». Регулярные таймауты - сигнал, что ресурсов уже не хватает.

Технологический журнал (logcfg.xml) собираем на ограниченное время под конкретную задачу. Минимум - DBMSSQL с длительностью от 5–10 секунд и TLOCK для блокировок. Полный сбор не стоит: нагрузка и объём логов дают больше вреда, чем пользы.

Синтетический бенчмарк производительности 1С — запускаем на эталонной базе и фиксируем результат в условных единицах. Сравнение раз в квартал даёт метрику динамики: показатель упал на 20–30% — что-то изменилось. Активные пользователи и пиковая нагрузка по часам видны в журнале регистрации, сравнение с пропускной способностью даёт картину запаса.

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

На стороне СУБД свои инструменты, они показывают то, чего не видно в счётчиках Windows и журнале 1С. Для MS SQL первая остановка - Activity Monitor в Management Studio: активные сессии, ожидания, IO-нагрузка. Этого хватает для регулярного аудита.

Глубже - DMV-представления. sys.dm_os_wait_stats показывает, что тормозит сервер. sys.dm_db_index_usage_stats - используются ли индексы. sys.dm_exec_query_stats выдаёт топ медленных запросов: три-пять из них съедают часть CPU.

На PostgreSQL принцип тот же: pg_stat_activity для текущих запросов, pg_stat_statements для агрегированной статистики, pg_stat_database для общей картины. Расширение pg_stat_statements ставится заранее, без него аудит сильно беднее.

Размер базы и темп роста - отдельный показатель: резкий рост значит мусор в регистрах или переполнившийся журнал. Фрагментация индексов проверяется через sys.dm_db_index_physical_stats для MS SQL и pg_stat_user_indexes для PostgreSQL: регулярное превышение 30% значит, что не хватает обслуживания. Deadlock-и в рабочее время - это архитектурные проблемы конфигурации или мощности сервера.

Мониторинг сервера 1С во время аудита разворачивается в шесть шагов.

Шаг 1 - сбор системных счётчиков: на Windows Performance Monitor, на Linux sar или Prometheus с node_exporter. Минимум на неделю, чтобы поймать цикл со всеми пиками.

Шаг 2 - сторона 1С: экспорт журнала регистрации за месяц, краткий запуск технологического журнала под нагрузку, прогон бенчмарка производительности на эталонной базе. Эти три источника закрывают платформенный уровень.

Шаг 3 - сторона СУБД: снимок состояния через DMV или pg_stat_*, экспорт топ-50 запросов, проверка фрагментации индексов.

Шаг 4 - анализ. Загружаем счётчики в Excel или специализированный инструмент, считаем средние и пики, ищем превышения порогов. Обычно сразу понятно, в какой ресурс упёрлись.

Шаг 5 - сводный отчёт. Одна страница: цветовая карта по четырём ресурсам, три-пять проблемных мест, рекомендация по шагам. Финдиректор читает за пять минут.

Шаг 6 - сохранить отчёт в архив с датой. Через квартал - повтор и сравнение динамики. Так аудит становится процессом, а не разовым мероприятием.

«Ресурсов не хватает» - это не ощущение, а превышение порогов. Нехватка CPU: rphost и sqlservr или postgres стабильно держат потолок в часы пиковой нагрузки, ни одно ядро не отдыхает. Без апгрейда CPU будет только хуже.

Нехватка памяти - активный своп, низкий Page Life Expectancy у MS SQL или buffer cache hit ratio меньше 90% у PostgreSQL. RAM - самый лёгкий апгрейд. Нехватка диска: длинная очередь, высокие задержки IO, %util около 100, лечится переходом на NVMe и отдельным томом под tempdb.

Нехватка сети - загрузка 1 Gb-канала больше 60–70% в пик плюс лаги между сервером 1С и СУБД. Переход на 10 Gb решает на годы. Запас 30% по четырём ресурсам - норма для прод-1С: меньше - повод задуматься, больше - повод оптимизировать конфигурацию, а не докупать железо.

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

Когда нужно не просто проверить «что и где», а получить документ, на основе которого защищать бюджет или планировать миграцию, проще заказать внешний аудит ИТ-инфраструктуры с фиксированным регламентом и итоговым отчётом по понятной методике.

Аудит - это четыре базовых ресурса (CPU, память, диск, сеть) плюс метрики платформы и СУБД и короткий отчёт с цветовой картой. Делается раз в квартал и занимает несколько часов - работа, которая экономит ремонт на горящем в пиковые периоды. Цифры либо подтверждают запас, либо показывают узкое место. Дальше - оптимизация или планирование апгрейда, но уже по фактам, а не по жалобам.

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