Как найти основную причину сбоя давления памяти на сервере SQL 2008?
Один из серверов, мониторинг которых я выполнял, начал выдавать следующие предупреждения от Resource-Exhausted-Detector:
Windows успешно диагностировала низкое состояние виртуальной памяти. Следующие программы использовали больше всего виртуальной памяти: sqlservr.exe (1560) - 14960812032 байта, ReportingServicesService.exe (1936) - 506359808 байтов, а w3wp.exe (7376) - 273764352 байта.
SystemCommitLimit 38068215808 SystemCommitCharge 37800669184 ProcessCommitCharge 16727490560 PagedPoolUsage 359088128 PhysicalMemorySize 17098584064 PhysicalMemoryUsage 16881131520 NonPagedPoolUsage 221425664 Процессы 481425664 Процессы
Этот сервер является Windows Server 2008, работает под управлением MSSQL 2008 R2, имеет 16 ГБ ОЗУ и 24 процессора. Он запускает SQL и веб-сервис, который обращается к SQL для данных.
Числа, которые я включил в цитату, взяты из раздела сведений о программе просмотра событий. Я не смог определить основную причину. Я уже знаю, что для работы SQL требуется много памяти, и в то время он использовал много памяти, но я также установил ограничение на 14000 МБ.
SQL начал получать ошибку "Недостаточно памяти" в дополнение к предупреждениям "Resource-Exhausted-Detector".
Каков наилучший подход к поиску первопричины этого? Я не видел ничего, что выглядит необычным в журналах. После нескольких часов повторения этой ошибки снова и снова память окончательно исчерпывалась, и службы начинали отказывать, пока служба не была перезапущена.
Разве SQL не достаточно умен, чтобы освободить часть памяти, когда есть давление? Файл подкачки (виртуальная память) занимал 20 ГБ, а SQL использовал только 16 ГБ физической памяти. Что заполняло остальную часть виртуальной памяти? Действительно ли SQL использовал весь этот файл подкачки?
Стоит ли искать утечку памяти? Рост файла журнала?
.Mdf используется больше всего на сервере растет около 100 МБ каждый день. Файл журнала увеличивался на 3 ГБ за один раз и теперь составляет 40 ГБ.
Обычно, когда есть нехватка памяти, мы никогда не доходили до точки, когда сервер просто падает. Обычно он работает мучительно медленно, пока давление не исчезнет.
Есть ли способ эффективно предотвратить возникновение этой проблемы?
3 ответа
Чтобы правильно диагностировать это, нам нужно больше информации.
SQL-сервер похож на любой другой процесс Windows; его виртуальное адресное пространство может быть намного больше, чем физическое ОЗУ. Он может быть даже больше, чем файлы подкачки RAM +, если какая-либо его часть использует файлы, отображенные в памяти.
Параметр настройки в SQL-сервере - это способ указать ему никогда не использовать больше, чем "х" МБ. Вы должны посмотреть на пиковую стоимость фиксации всех других сервисов на коробке, вычесть это из вашего физического объема оперативной памяти, а затем отдать остаток SQL Server. Насколько я знаю, ограничение памяти относится только к СУБД, а не к зверинцу связанных служб SQL-сервера. Я могу ошибаться здесь.
Итак, нам нужно больше цифр для остальных процессов. Например, у вас есть рабочий процесс IIS, потребляющий 273 МБ; есть только один рабочий процесс? У вас установлено антивирусное или резервное ПО?
Вы можете использовать WSRM для профилирования происходящего, а затем рассмотреть возможность применения ограничений памяти. В качестве альтернативы, и это была бы моя рекомендация, установить больше оперативной памяти.
Чтобы получить графическое представление о том, куда движется ваша память, обратите внимание на утилиту RAMMap от Microsoft SysInternals.
Возможно, вам придется увеличить размер файла подкачки, чтобы иметь возможность обрабатывать периодические пики в размере фиксации памяти. Мы часто сталкиваемся с этой проблемой в вычислениях Azure, где Pagefile по умолчанию слишком низко установлен для приложений, интенсивно использующих память.
Вы можете прочитать больше здесь: http://mvolo.com/low-pagefile-can-cause-503-service-unavailable-on-azure-web-roles/
Это не решит проблему, если вашему экземпляру SQL требуется намного больше памяти, чем у вас, но это может помочь лучше выдержать временные пики.
Есть ли способ эффективно предотвратить возникновение этой проблемы?
Глупым ответом было бы предложить вам купить больше памяти. Это может не решить вашу проблему, но, вероятно, не повредит.
SQL Server любит память. SQL Server любит кэшировать вашу базу данных или фрагменты ваших баз данных в памяти, чтобы они были доступны быстрее. Если вы хотите увидеть, что у вас в памяти прямо сейчас, вы можете получить эту информацию из DMV: http://www.mssqltips.com/sqlservertip/2393/determine-sql-server-memory-use-by-database-and-object/. Один из моих коллег однажды получил рекомендацию поставщика, чтобы размер базы данных для БД их продукта никогда не превышал размер памяти сервера. Это непрактично для большинства людей, но если вы пытаетесь обслуживать сильно запрашиваемую базу данных объемом 10 ТБ с 16 ГБ ОЗУ, это может быть проблемой.
Попробуйте запустить sp_blitz на вашем сервере - это хранимая процедура, которая проверяет ваш сервер на наличие проблем. http://www.brentozar.com/blitz/
Также попробуйте perfmon: http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/
Это должно помочь вам отследить причину.