Несколько постов в нашей группе телеграмм послужили причиной для написания данной
статьи.
В этой статье попытаюсь дать ответы на выше перечисленные вопросы так, чтоб и новичкам
было понятно и пользователи с опытом также могли, что-то почерпнуть из публикации.
Все просто.
1С Предприятие по своей «натуре» создает много временных таблиц, которые вынуждают
MS SQL брать больше ОЗУ, заполнять свой буферный пул теми данными, которые в 1С часто
востребованы, чтоб обеспечить максимальною производительность.
Другими словами, MS SQL не виноват в том, что 1С «дает повод» брать больше ОЗУ и не
дает основания ее освобождать.
Благо в MS SQL есть инструмент позволяющий «руками» ограничить потребление ОЗУ, что
собственно в самом начале статьи и продемонстрировали на скрине.
Конечно, помимо инструментов есть, и советы от Microsoft касательно MS SQL:
Физика работы MS SQL, проста в базовом плане потребления ОЗУ, помещаем в буфер то, что
часто используется, чтоб обеспечить как можно лучшую производительность.
Если «сиквел» обнаружит, что у него всего 30% ОЗУ он будет просто больше писать и
читать с диска и обходится тем, что есть. Да, конечно, всему есть придел и слишком
большой дефицит ОЗУ приведет сперва к падению производительности (хорошо будет
заметно при формировании отчетов в 1С), а потом и к различным ошибкам, вплоть до
«вылета» программы.
В рамках данной статьи, попытаюсь дать ответ и на этот не простой вопрос, или как
минимум указать верное направление)
Дело в том, что определяя потребление ОЗУ «сиквелом», мы в основном работаем только с
«симптомами» и лишь сопоставив показания нескольких, можно предполагать, что
проблема в нехватке ОЗУ или наоборот ОЗУ в избытке.
И так «симптомы»:
Симптом №1
«Buffer cache hit ratio» – какой процент страниц MS SQL прочитали из буферного пула.(кэша)
Расшифруем подробно, что это за показатель «Коэффициент обращений к буферному кэшу»,
как его посмотреть, конечно, разберем и его нюансы. (Они есть у всех «симптомов»).
И так идем на сервер, где у Вас установлен MS SQL .При его установке будет добавлен
счѐтчик в Performance Monitor, собственно там и можно смотреть показатель.
Создадим новую группу сборщика (Можете использовать и существующей, если у Вас есть).
Далее создадим новую группу сборщиков данных. (Можно только добавить показатель если
у Вас уже создан свой сборщик).
Имя указываем на выбор (Для теста пишу “MS SQL ОЗУ 1С”)
Выберем “Создать вручную” (для опытных) и клик по кнопке “Далее”
На следующем этапе укажем “Счетчик производительности” и “Далее”.
И добавим сам “счетчик”
Нам нужно найти: SQLServer:BufferManager (Развернем его).
И сам счетчик: Buffer cache hit ratio он же на русском “Коэффициент обращений к буферному
кэшу”
Клик “Добавить >>” и “OK”
После еще раз “Далее”
―Далее‖
“Сохранить и закрыть” затем “Готово”
После создания счетчика включаем его, чтоб он собрал данные. (Пары минут его работы
будет достаточно, так как мы установили по умолчанию интервал сбора каждые 15 сек.).
ВАЖНО!
Замеры проводим только в конце рабочего дня, чтоб получить правдоподобные результаты.
И не перезапускаем на протяжении дня MS SQL, иначе данные показателя будут обнулены!
Включить сбор достаточно просто, надо лишь выделить в списке наш “сборщик” и кликнув
правой клавишей мышки – “Пуск”, также можно нажать на зеленый треугольник вверху (как
на картинке ниже).
После пары минут работы “Сборщика” остановим его и будем смотреть результаты.
Для остановки, также выполняем простые действия как и выше, только на этот раз с
кнопкой “Стоп”.
Buffer cache hit ratio – показывает процент страниц которые MS SQL считал из кэша
(буферного пула).
Это значит, что обращений к диску в нашем случаи не было и все поместилось в кэш.
Если бы “сиквелу” не хватило ОЗУ, он бы сбрасывал страницы на диски и оттуда бы читал
эти данные (процент BCHR был бы значительно ниже 100%) , но раз это не происходит,
значит, у нас есть основания полагать, что ОЗУ MS SQL достаточно.
А теперь собственно, почему не стоит полагаться на один “симптом” Buffer cache hit ratio:
Проблема в том, что счетчик Buffer cache hit ratio легко “накрутить”, если скажем
пользователь будет много раз формировать один и тот же отчет в 1С (с темы же данными),
то мы получим высокий процент чтения из кэша, даже если ОЗУ уже не хватает MS SQL.
При этом если сформировать в таких условиях другой “большой” отчет, он уже может
выполняться долго, сколько бы раз мы его не формировали (Так как ОЗУ MS не хватило,
данные берутся с диска, а Buffer cache hit ratio все еще покажет нам высокий процент).
Очень рекомендую почитать статью Джонатана Кехайяса.
И всегда считать Buffer cache hit ratio только одним из симптомов возможной проблемы с
ОЗУ!
Симптом №2
Page Life Expectancy
ОЗУ. Page Life Expectancy – «ожидаемый срок жизни страниц в кэше», и дальше мы будем
называть его просто PLE.
Мы уже разобрались как посмотреть процент страниц в кэше, а теперь можем узнать и
среднее время их нахождения там, что еще на шаг приблизит нас к верному “Диагнозу” )
Чем выше PLE тем больше вероятность, что при обращении к данным, они найдутся в кэше,
и не придется обращаться к диску, чтобы их прочитать.
Если страницы будут находится в кэше слишком мало времени (меньше 300 сек) тогда стоит
“начать разбираться”, так как это также может свидетельствовать что MS SQL не хватает
ОЗУ.
,[object_name]
,[counter_name]
FROM master.sys.sysprocesses
ELSE ''
END
, [cntr_value] AS PLE_SECS
,[cntr_value]/ 60 AS PLE_MINS
,[cntr_value]/ 3600 AS PLE_HOURS
FROM sys.dm_os_performance_counters
Но как и всегда “один в поле не воин” и данный показатель также стоит смотреть в
комплексе с другими, а еще лучше “понаблюдать” за ним, чтоб понять его нормальное
состояние для ваших баз и к примеру этот же показатель “промониторить” в нагрузках.
Рекомендация Microsoft о 300 сек была опубликована в те времена когда, MS SQL был 32х )
И по факту на сегодня 300 сек слишком малое значение (Для многих во всяком случаи).
Сегодня этот показатель будет верным только если Вы к примеру установили значение max
server memory в 4096 МБ (4 Гб) или ваш размер кэша, также не больше этого значения. Если
выше стоит использовать вот такую формулу:
(DataCacheSizeInGB/4GB *300)
Опять же по рекомендации Джонатана Кехайяса
Симптом №3
Смотрим Total Server Memory и Target Server Memory
select
counter_name, cntr_value
from
sys.dm_os_performance_counters
where
Target Server Memory – это значение на которое “рассчитывает получить” при нужде MS SQL.
Бывает также, что значения почти одинаковы (Total Server Memory и Target Server Memory)
это также хороший показатель, MS SQL на что рассчитывал то и получил.
————–