Несколько постов в нашей группе телеграмм послужили причиной для написания данной статьи.
И хоть вопросы немного разнятся, но проблема как оказалось у всех одинакова:
«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:
Зарегистрируйтесь, чтоб продолжить чтение статьи
Зарегистрироваться / Войти
Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>
