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.