Zabbix кричит про память, а сервер 1С в порядке

Серверы наших клиентов под присмотром Zabbix: если что-то идёт не так, нам приходит сообщение в Telegram. Однажды один из серверов 1С начал присылать тревогу по несколько раз в день:

Memory Pages/sec is too high (over 1000 for 5m): 4012

Порог 1000, а у нас 4000. Звучит как «срочно добавьте памяти». При этом в сервере 64 ГБ оперативной памяти, два SSD по 2 ТБ, и на нём вместе живут Microsoft SQL Server и сервер 1С. Пользователи на скорость не жалуются. Разбираемся, кто прав: Zabbix или пользователи.

Почему этот счётчик врёт

Счётчик Windows Memory\Pages/sec считает не только ситуации, когда системе не хватает памяти и она выгружает её на диск. В него попадает весь обмен с диском через файлы, отображённые в память: чтение баз, файловый кэш, резервное копирование, перестроение индексов. На связке SQL + 1С он спокойно уходит в тысячи на совершенно здоровом сервере.

Порог «1000» в стандартном шаблоне Zabbix родом из эпохи жёстких дисков, когда каждое обращение к диску было дорогим. На SSD эта цифра почти ничего не значит.

На что смотреть вместо него

Чтобы понять, хватает ли памяти на самом деле, нужны четыре показателя. Три из них — в Windows:

• Memory\Available MBytes — свободная память, должна стабильно держаться выше 2–4 ГБ;
• Paging File(_Total)\% Usage — использование файла подкачки, не должно расти;
• PhysicalDisk(_Total)\Avg. Disk sec/Read — время чтения с диска, меньше 10–20 мс.

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

perf_counter_en["\Memory\Available MBytes"]
perf_counter_en["\Paging File(_Total)\% Usage"]
perf_counter_en["\PhysicalDisk(_Total)\Avg. Disk sec/Read"]

Четвёртый показатель — внутри самого SQL Server:

SELECT RTRIM(object_name) AS obj, RTRIM(counter_name) AS counter, cntr_value
FROM sys.dm_os_performance_counters
WHERE (object_name LIKE '%Buffer Manager%' AND counter_name = 'Page life expectancy')
   OR (object_name LIKE '%Memory Manager%' AND counter_name = 'Memory Grants Pending');

Page Life Expectancy — сколько секунд страница данных живёт в памяти, прежде чем её вытеснят. Чем больше, тем лучше, и важно, чтобы значение росло, а не проваливалось. Memory Grants Pending — сколько запросов стоят в очереди за памятью; нормальное значение — ноль.

На нашем сервере все четыре показателя были в норме. Тревога — шум.

Но мы всё равно нашли, что настроить

Раз уж залезли в SQL, проверили, сколько памяти ему разрешено брать:

SELECT physical_memory_in_use_kb / 1024 AS used_mb FROM sys.dm_os_process_memory;
SELECT value_in_use FROM sys.configurations WHERE name = 'max server memory (MB)';

Ответ: 2147483647. Это не опечатка, а значение по умолчанию, которое означает «бери сколько хочешь». SQL Server так и делает: со временем забирает почти всю память, а рабочим процессам 1С (rphost) остаётся то, что он не успел занять. Пользователи видят это как «во второй половине дня проведение документов тормозит», и никто не связывает это с настройкой, которую никто не трогал с момента установки.

Ограничиваем. При 64 ГБ ориентир — 32–40 ГБ под SQL, остальное серверу 1С и системе. Точное значение подбирается по нагрузке, а применяется без перезапуска:

EXEC sp_configure 'show advanced options', 1;  RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 36864;  RECONFIGURE;

Второе — даём учётной записи службы SQL право «Блокировка страниц в памяти» (secpol.msc → Локальные политики → Назначение прав пользователя), чтобы Windows не выгружала кэш SQL на диск в неудачный момент. После перезапуска службы проверяем, что право применилось:

SELECT sql_memory_model_desc FROM sys.dm_os_sys_info;   -- ожидаем LOCK_PAGES

Файл подкачки при этом не отключаем: оставляем на SSD с размером, которым управляет система. Отключённый файл подкачки на сервере — частый «совет из интернета», который однажды заканчивается падением в самый неудобный момент.

Как убрать ложную тревогу

В Zabbix: Data collection → Hosts → нужный сервер → Triggers → «Memory Pages/sec is too high» → Disable. Порог триггера, унаследованного из шаблона, на уровне хоста не поменять, только отключить. Если хочется оставить контроль с другим порогом, правьте выражение в шаблоне или сделайте его копию под серверы с SSD.

Что из этого вынести

Шаблон мониторинга «из коробки» — это стартовая точка, а не истина. Пороги надо проверять под конкретное железо, иначе мониторинг превращается в будильник, который все научились выключать не глядя. А ложная тревога иногда полезна: она приводит к настройкам, которые действительно влияют на скорость. Ограничение памяти SQL сэкономило пользователям больше нервов, чем любое уведомление.

Отдельно мы сказали заказчику то, что ему не очень хотелось слышать: этот сервер работает на Windows 10, а клиентская система — не лучший выбор для продуктивного SQL и 1С. К тревоге это отношения не имеет, но в план модернизации попало.