НАСТРОЙКА ПАМЯТИ В MS SQL ДЛЯ 1С ПРЕДПРИЯТИЯ

Несколько постов в нашей группе телеграмм послужили причиной для написания данной
статьи.

И хоть вопросы немного разнятся, но проблема как оказалось у всех одинакова:

«MS SQL скушал, забрал, использовал всю оперативку»

Действительно не редкие случаи, когда MS SQL чрезмерно употребляет ОЗУ и если не

убавить его аппетиты можно и совсем остаться без свободной оперативной памяти.

Первое так сказать быстрое и «почти универсальное» решение проблемы чрезмерного

употребления ОЗУ в MS SQL это указать в свойствах MS SQL (вкладка «Память») тот объем
ОЗУ, который мы можем отдать на нужды «сиквела». (Не забывайте после перезапустить MS
SQL)
Более подробная информация по вопросу выделения ОЗУ, есть на курсе: Администратор 1С.

На картинке выше указанно 4 Гб которые может употребить MS SQL (И обычно за

«Максимальный размер памяти сервера он и не выходит»).
Таким образом, мы снимаем «острую» проблему с потреблением ОЗУ в MS SQL.

Конечно, при всем этом сразу возникает много вопросов:

1. Почему MS SQL не освобождает память ?
2. Сколько ОЗУ для моего MS SQL установить ?
3. Как определить сколько ОЗУ нормально для MS SQL ?
4. Можно-ли не наращивать объем ОЗУ для MS SQL ?
5. Чем грозит ОЗУ в MS SQL ?

В этой статье попытаюсь дать ответы на выше перечисленные вопросы так, чтоб и новичкам
было понятно и пользователи с опытом также могли, что-то почерпнуть из публикации.

Главный вопрос: «Почему MS SQL не освобождает память, неужели он не умеет

это делать ?
Умеет!

MS SQL умеет динамически работать с ОЗУ!

Вот что пишет MS:

Когда SQL Server использует память динамически, он периодически опрашивает систему,
чтобы определить объем свободной физической памяти. SQL Server использует API
уведомления памяти QueryMemoryResourceNotification, чтобы определить, когда можно
выделить и освободить память буферного пула.
Но почему же это не всегда происходит?

Все просто.
1С Предприятие по своей «натуре» создает много временных таблиц, которые вынуждают
MS SQL брать больше ОЗУ, заполнять свой буферный пул теми данными, которые в 1С часто
востребованы, чтоб обеспечить максимальною производительность.

Безусловно, это нормально поведение не только MS SQL, но и большинства других СУБД.

Только сведя к минимуму операции ввода /вывода с диска (работая с ОЗУ) можно добиться
максимальной производительности, что собственно и пытается делать MS SQL.

К сожалению не только «природа» 1С Предприятия способствует чрезмерным аппетитам

«сиквела», тут здорово помогают и «кривые запросы» и «ошибки» в коде, и конечно все это
ведет к тому, что MS SQL употребляет ОЗУ больше чем мы рассчитывали, (часто всю что
видит).

Другими словами, MS SQL не виноват в том, что 1С «дает повод» брать больше ОЗУ и не
дает основания ее освобождать.
Благо в MS SQL есть инструмент позволяющий «руками» ограничить потребление ОЗУ, что
собственно в самом начале статьи и продемонстрировали на скрине.
Конечно, помимо инструментов есть, и советы от Microsoft касательно MS SQL:

Рекомендуется устанавливать MS SQL единственным (кроме системы) софтом.

Так он не будет конфликтовать за ресурсы с другими программами и сможет взять ОЗУ
сколько ему потребуется.

Объем ОЗУ (в идеале) должен быть равен размеру всех баз.

Другими словами если у Вас 3 базы по 10 Гб, размер ОЗУ для MS SQL в идеале 30 Гб.
Безусловно в идеале и «миллион» долларов вряд ли бы кого расстроил ) но исходим от того
что имеем ), и 30% процентов от баз также будет очень хорошо! (Во многих случаях и
меньше того).

Физика работы MS SQL, проста в базовом плане потребления ОЗУ, помещаем в буфер то, что
часто используется, чтоб обеспечить как можно лучшую производительность.

Если «сиквел» обнаружит, что у него всего 30% ОЗУ он будет просто больше писать и
читать с диска и обходится тем, что есть. Да, конечно, всему есть придел и слишком
большой дефицит ОЗУ приведет сперва к падению производительности (хорошо будет
заметно при формировании отчетов в 1С), а потом и к различным ошибкам, вплоть до
«вылета» программы.

(Рекомендую время от времени просматривать журнал MS SQL не сыпется ли уже ошибки

связанные с памятью, особенно обратить внимание на строки memory pressure).

Вот мы и подошли к еще одному Важному вопросу:

«Так сколько ОЗУ надо для счастливой» жизни «сиквелу» ) ?

В рамках данной статьи, попытаюсь дать ответ и на этот не простой вопрос, или как
минимум указать верное направление)

Дело в том, что определяя потребление ОЗУ «сиквелом», мы в основном работаем только с
«симптомами» и лишь сопоставив показания нескольких, можно предполагать, что
проблема в нехватке ОЗУ или наоборот ОЗУ в избытке.

Помните в начале статьи мы говорили о «почти универсальном» способе навести порядок с

чрезмерным потреблением ОЗУ» ?
Да, в большинстве случаев ограничение поможет, но не в 100% случаев, так как действует
оно только на «буферный пул»!

Вот что по этому поводу пишет MS:

Сам SQL Server как процесс занимает больше памяти, чем указано в параметре max server
memory. И внутренние, и внешние компоненты могут занимать память за пределами
буферного пула, что также входит в ее общий расход, однако буферный пул обычно
составляет наибольшую часть общего объема памяти, потребляемого SQL Server.
Известны случаи, когда MS SQL употребил ОЗУ, что значительно превышает объем всех баз
1С, и даже если указали max server memory ограничили потребление.
К сожалению, и такое бывает, особенно когда в конфигурации 1С есть «кривые запросы».
Что еще раз подтверждает факт отсутствия «универсальной таблетки».

По-хорошему нужно включить «доктора», который по «симптомам» определяет болезнь на

первом этапе, а на втором определяет и причину заболевания.
К сожалению, другого более точного определения «мало или много ОЗУ» в MS SQL как по
«симптомам» нет, так как не все зависит от него самого.

И так «симптомы»:
Симптом №1
«Buffer cache hit ratio» – какой процент страниц MS SQL прочитали из буферного пула.(кэша)
Расшифруем подробно, что это за показатель «Коэффициент обращений к буферному кэшу»,
как его посмотреть, конечно, разберем и его нюансы. (Они есть у всех «симптомов»).
И так идем на сервер, где у Вас установлен MS SQL .При его установке будет добавлен
счѐтчик в Performance Monitor, собственно там и можно смотреть показатель.
Создадим новую группу сборщика (Можете использовать и существующей, если у Вас есть).

Запускаем команду «Perfmon» нажав комбинацию клавиш «WIN+R»

Далее создадим новую группу сборщиков данных. (Можно только добавить показатель если
у Вас уже создан свой сборщик).
Имя указываем на выбор (Для теста пишу “MS SQL ОЗУ 1С”)
Выберем “Создать вручную” (для опытных) и клик по кнопке “Далее”
На следующем этапе укажем “Счетчик производительности” и “Далее”.
И добавим сам “счетчик”
Нам нужно найти: SQLServer:BufferManager (Развернем его).
И сам счетчик: Buffer cache hit ratio он же на русском “Коэффициент обращений к буферному
кэшу”
Клик “Добавить >>” и “OK”
После еще раз “Далее”
―Далее‖
“Сохранить и закрыть” затем “Готово”
После создания счетчика включаем его, чтоб он собрал данные. (Пары минут его работы
будет достаточно, так как мы установили по умолчанию интервал сбора каждые 15 сек.).

ВАЖНО!

Замеры проводим только в конце рабочего дня, чтоб получить правдоподобные результаты.
И не перезапускаем на протяжении дня MS SQL, иначе данные показателя будут обнулены!
Включить сбор достаточно просто, надо лишь выделить в списке наш “сборщик” и кликнув
правой клавишей мышки – “Пуск”, также можно нажать на зеленый треугольник вверху (как
на картинке ниже).
После пары минут работы “Сборщика” остановим его и будем смотреть результаты.
Для остановки, также выполняем простые действия как и выше, только на этот раз с
кнопкой “Стоп”.

И идем смотреть отчеты…

Как видим значение нашего Buffer cache hit ratio равно 100%
Теперь подробно что это значит:

Buffer cache hit ratio – показывает процент страниц которые MS SQL считал из кэша
(буферного пула).

Это значит, что обращений к диску в нашем случаи не было и все поместилось в кэш.
Если бы “сиквелу” не хватило ОЗУ, он бы сбрасывал страницы на диски и оттуда бы читал
эти данные (процент BCHR был бы значительно ниже 100%) , но раз это не происходит,
значит, у нас есть основания полагать, что ОЗУ MS SQL достаточно.

Принято считать “хорошим” показателем 90% и выше.

А теперь собственно, почему не стоит полагаться на один “симптом” 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, проста!

Чем выше PLE тем больше вероятность, что при обращении к данным, они найдутся в кэше,
и не придется обращаться к диску, чтобы их прочитать.

Если страницы будут находится в кэше слишком мало времени (меньше 300 сек) тогда стоит
“начать разбираться”, так как это также может свидетельствовать что MS SQL не хватает
ОЗУ.

И так, как определить PLE ?

Самый простой вариант это использовать скрипт:

SELECT @@servername AS INSTANCE

,[object_name]

,[counter_name]

, UPTIME_MIN = CASE WHEN[counter_name]= 'Page life expectancy'

THEN (SELECT DATEDIFF(MI, MAX(login_time),GETDATE())

FROM master.sys.sysprocesses

WHERE cmd='LAZY WRITER')

ELSE ''

END

, [cntr_value] AS PLE_SECS

,[cntr_value]/ 60 AS PLE_MINS
,[cntr_value]/ 3600 AS PLE_HOURS

,[cntr_value]/ 86400 AS PLE_DAYS

FROM sys.dm_os_performance_counters

WHERE [object_name] LIKE '%Manager%'

AND [counter_name] = 'Page life expectancy'

Смотрим показатель PLE_SECS если больше 300 сек, тогда хорошо )

Но как и всегда “один в поле не воин” и данный показатель также стоит смотреть в
комплексе с другими, а еще лучше “понаблюдать” за ним, чтоб понять его нормальное
состояние для ваших баз и к примеру этот же показатель “промониторить” в нагрузках.

Безусловно и здесь не обошлось без “ложки дегтя” )

Рекомендация 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

counter_name in (N'Total Server Memory (KB)', N'Target Server Memory (KB)')

Здесь все просто.

Если Total Server Memory длительное время больше Target Server Memory также есть повод
подозревать нехватку памяти в MS SQL.
Total Server Memory – показывает общее количество динамической памяти, которую в
данный момент использует MS SQL. Если значения, продолжительное время, больше чем
физическая память, надо увеличивать физическую память.

Target Server Memory – это значение на которое “рассчитывает получить” при нужде MS SQL.
Бывает также, что значения почти одинаковы (Total Server Memory и Target Server Memory)
это также хороший показатель, MS SQL на что рассчитывал то и получил.
————–

Конечно в “базовых” случаях достаточно применить советы из данной статьи, чтоб

определить есть ли проблемы с ОЗУ в MS SQL или нет. Но безусловно это не все “приемы”
которые можно и нужно применять, ждите продолжение статьи будет!