Что такое хорошо и что такое плохо? Или кратко об увеличении количества оперативной памяти на сервере

Кратко об увеличении количества оперативной памяти на сервере

По мотивам статьи: Problems from having lots of server memory  By: Paul Randal

Около месяца назад я провел опрос о том, сколько оперативной памяти установлено у вас на самом «тяжелом» сервере для SQL Server.

Вот результаты:

ram

В ответах «other» были:

  • 3 ответа: 128 ГБ или больше, но меньше 256 ГБ.
  •  1 ответ: меньше 16 ГБ.
  • И у кого-то на сервере установлено 512 МБ оперативной памяти.

Очень интересные результаты:

  • Я ожидал, что большинство серверов будут находиться где-то в середине (имеют около 128 ГБ), но в диапазоне от 64 ГБ до 256 ГБ только 37% серверов.
  • Я удивлен, что довольно большой процент серверов (41%) имеют больше 256 ГБ оперативной памяти.
  • Я не знал, какой процент серверов с более 1 ТБ оперативной памяти, но оказалось почти 10%, что, довольно, неплохо.

О чем это говорит? Ну, количество серверов с 128 ГБ и более оперативной памяти составляет больше половины от всех. Чем больше оперативной памяти, тем более важно то, что нужно убедиться в эффективности ее расхода. Например, что буферный пул не расходуется почем зря и не забивается плохими запросами с огромным количеством чтений.

Какие могут быть проблемы при наличии такого большого объема оперативной памяти?

  • Выключение инстанса вызовет процесс чекпоинта, который может выполняться весьма долго (от минут до часов), если в базах данных имеется очень много грязных страниц, ведь их все необходимо сбросить на диск. Продолжительное время выключения инстанса может повлиять на временное окно для технологических работ, например, для установки нового SP или CU.
  • Во время включения инстанса придется подождать, если серверный процесс POST Memory Manager проверяет оперативную память в это время.
  • Выделение памяти под буферный пул может затянуться. Мы работали с клиентами, у которых под буферные пулы было выделено 1ТБ+, и наткнулись на баг в версии 2008 R2 (а также в 2008 и 2012), связанный с выделением памяти NUMA, что приводило к долгому времени запуска SQL Server. Баг был исправлен в KB 2819662 (http://support.microsoft.com/kb/2819662)
  • Прогрев буферного пула. Если вы не столкнулись с проблемой, описанной в предыдущем пункте, то как вы собираетесь прогревать такой большой буферный пул, чтобы не ждать, пока «рабочий набор» используемых страниц не окажется в оперативной памяти? Первый способ – проанализировать буферный пул, когда он уже прогрет и, тем самым, выяснить, какие таблицы и индексы находятся в памяти, а затем написать несколько скриптов, которые сразу после старта инстанса будут считывать данные этих объектов в память.
  • При доступном большом объеме оперативной памяти нельзя забывать про неиспользуемые индексы/кэши планов/лишнего занятого места в буферном пуле. Не стоит думать, что оперативной памяти все равно много, и лишние объекты не будут мешать. Если что-то из вышеперечисленного было замечено на сервере, то необходимо решить проблему в обязательном порядке.
  • Обычно большое количество оперативной памяти на сервере говорит о том, что база данных действительно большая. Необходимо рассмотреть разделение базы данных по файловым группам, чтобы можно было проводить восстановление выбранных файлов/файловых групп за меньшее количество времени, чем восстановление полного бэкапа. Возможно, стоит разделять большие таблицы, архивировать старые данные или выносить их в другую базу.

Добавление оперативной памяти в сервер – это один из самых легких путей убрать повысить производительность базы данных. Однако, нельзя считать, что этот способ (как и добавление любого «железа») является панацеей от всех бед и проблем. Напротив, увеличение оперативной памяти приводит к потенциальным проблемам и рискам, поэтому требует тщательного рассмотрения.

Запись опубликована в рубрике Полезно и интересно с метками , . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Войти с помощью: