SQL Server 2005: недостаточно системной памяти для выполнения этого запроса


13

Один из наших SQL-серверов, который работал стабильно в течение довольно долгого времени (лет), недавно выдавал недостаточные ошибки памяти. Из журнала событий приложения мы видим:

Код события: 701

Описание. Недостаточно системной памяти для выполнения этого запроса.

Наша команда, которая управляет этим сервером, состоит в основном из разработчиков, которые выполняют обязанности системного администратора. Тем не менее, наша основная экспертиза - разработка. При этом мы затрудняемся с тем, как мы решаем эту проблему. Мы обыскивали форумы и еще много чего и не нашли ничего подходящего

Итак, вот еще несколько деталей, которые помогут в устранении неполадок:

  • Минимальная память нашего сервера установлена ​​на 0.
  • Максимальная память нашего сервера установлена ​​на 2000.
  • Общая физическая память составляет 3 325,85 МБ (из sysinfo).
  • Общая виртуальная память составляет 7,10 ГБ (из sysinfo).
  • Мы не использовали AWE для выделения памяти, но теперь мы должны увидеть, если это имеет значение.
  • Эта ошибка была вызвана заданием, которое выполняло резервное копирование журнала транзакций, но не выполняло запрос.
  • У нас много связанных серверов. Типами СУБД с другой стороны являются системы SQL Server (2005 и 2000), Oracle 10g и OSI PI.
  • Это прерывисто в этой точке. Мы не можем связать какое-либо время или событие с ошибками.
  • Конечно, перезагрузка, кажется, на некоторое время уходит, что имеет смысл из-за характера сообщения об ошибке.
  • Этот сервер утраивается как сервер приложений (пара служб Windows) и веб-сервер, а также сервер базы данных.

РЕДАКТИРОВАТЬ:

Мы находимся на SP3. Большинство найденных нами постов были до SP1, что не относится к нам.

SELECT  SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

возвращается

9.00.4035.00 SP3 Standard Edition


Можете ли вы просмотреть журнал ошибок SQL Server, так как могут быть дополнительные сведения об этой ошибке.
Джон Сансом

Ответы:


4

Я бы также предложил использовать параметр запуска -g. Кажется, что это работает для большинства людей и, вероятно, будет работать для вас. Единственное, что меня беспокоит, - это то, что основная проблема не может быть решена. Например, если есть утечка памяти из-за связанного сервера, а MTL увеличен до 512 Мб, это будет просто более длительный период между проблемами памяти? Я не знаю ответа на этот вопрос, но я склонен согласиться с UndertheFold в том, что Perfmon может быть хорошим началом.


7

Сообщение об ошибке «Недостаточно системной памяти для выполнения этого запроса». относится к виртуальному адресному пространству (VAS), которое недоступно, а не к памяти в обычном смысле, то есть в пространстве процесса SQL Server.

Учитывая, что вы работаете только с 3 ГБ на этом сервере, а SQL Server было назначено до 2 ГБ, это означает, что ОС и что-либо еще на коробке имеет менее 1 ГБ для воспроизведения. Это не много памяти.

Если эта проблема действительно является следствием утечки памяти, то используется VAS вне пространства процесса SQL Server (memToLeave).

Я бы предложил использовать параметр запуска -g, чтобы выделить больше памяти для части memToLeave.

См. Следующую статью для получения дополнительной информации:

http://www.johnsansom.com/sql-server-memory-configuration-determining-memtoleave-settings/

Вы также можете уменьшить максимальный объем памяти SQL Server, но я бы сделал это в крайнем случае.


Хорошая статья Спасибо, что написали это! У нас есть несколько доменов выгрузки в наших журналах SQL. У нас есть только 2 хранимые процедуры CLR, и они в основном просто получают и помещают данные в / из веб-службы. Кажется странным, что эти 2 хранимых процедуры CLR будут использовать слишком много VAS из коробки.
Аарон Дэниелс

Пожалуйста. Как вы, возможно, знаете, выделение по умолчанию для memToLeave составляет всего 256 МБ. Это довольно маленькая песочница для ваших доменов приложений, всего CLR / управляемого кода, запросов к связанному серверу, служб SSIS и т. Д., Особенно если вы используете всю доступную память на сервере. Я бы предложил удвоить его до 512 МБ, используя параметр запуска -g.
Джон Сэнсом

1

Это может быть связано с утечкой памяти драйвера связанного сервера, согласно этой ветке форума :

Вот что Microsoft сказала нам.

Очевидно, обработка данных с использованием связанного сервера, в частности, драйвер fox pro, вызывает утечку памяти, которая со временем накапливается.


0

Этот сервер утраивается как сервер приложений (пара служб Windows) и веб-сервер, а также сервер базы данных.

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

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


0

Ссылка взята из этого блога!

Есть разные альтернативы для решения этой проблемы.

Во-первых, проверьте настройки SQL Server для «минимальной памяти сервера» и «максимальной памяти сервера». Если вы обнаружили очень маленькую разницу в обоих значениях, увеличьте «max server memory».

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

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

В-четвертых, проверьте размер файла подкачки виртуальной памяти и увеличьте размер этого файла.

В-пятых, проверьте размер «минимальной памяти на запрос», на самом деле он равен 1024 КБ, но в редких случаях вы можете уменьшить размер этого параметра. На самом деле, это не рекомендуется, но вы можете попробовать.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.