Странные ошибки памяти SQL Server после обновления до 64-битной

Question

Мы только что "обновили" наш сервер производственной базы данных с 32-разрядного на 64-разрядный. Он работает под управлением SQL Server 2005 Standard на Windows Server 2003. В течение ночи после обновления сервер был недоступен в течение почти часа - запросы клиентов истекали. Тогда проблема, казалось, решалась сама собой. Единственное, что я имею к этой проблеме, это то, что находится в журналах сервера SQL:

LazyWriter: предупреждение, свободные буферы не найдены.

диспетчер памяти VM Reserved = 8470288 КБ VM Committed = 2167672 КБ Распределено AWE = 0 КБ Резервная память = 1024 КБ Зарезервированная память в использовании = 0 КБ

Сообщение Идентификатор узла памяти = 0 ВМ зарезервировано = 8464528 КБ VM Committed = 2162000 КБ Распределено AWE = 0 КБ SinglePage Allocator = 103960 КБ MultiPage Allocator = 31832 КБ

MEMORYCLERK_SQLGENERAL (всего) ВМ зарезервировано = 0 КБ VM Committed = 0 КБ Распределено AWE = 0 КБ SM зарезервировано = 0 КБ SM Committed = 0 КБ SinglePage Allocator = 4352 КБ

Тогда есть еще много подобных сообщений, начинающихся с MEMORYCLERK.

Кто-нибудь знает, что происходит? Кажется, что он исчерпал память и, конечно, сервер имеет только 2 ГБ физической памяти, что не очень по сегодняшним меркам, но, конечно, это не должно просто полностью ОСТАНОВИТЬ РАБОТУ? Должен ли я установить максимальный объем памяти, который разрешено использовать SQL, до 1,6 ГБ или около того? Есть ли что-то еще, что я могу сделать (ДРУГОЕ, чем установка большего количества RAM, очевидно)?

Answer 1

2ГБ это конечно не очень много. На самом деле я считаю, что Microsoft рекомендует иметь 2 ГБ памяти только для запуска ОС и других задач.

Проверьте это сообщение в блоге и это сообщение на форуме Microsoft для получения дополнительной информации.

Память дешевая, добавьте больше, если можете.

_{(источник: wordpress.com )}

Answer 2

Были отдельные сообщения о том, что MSSQL выделяет достаточно памяти для сбоя страницы на диске 1 , что, конечно, приводит к резкому снижению производительности.

Хотя я не видел ничего официального от MS, но сообщения о том, что установка максимальной памяти должна быть где-то между 512M и 1G меньше физической памяти, должны помочь.

Enterprise Edition позволяет не допускать, чтобы страницы MSSQL были выгружены, что также должно решить проблему. И, очевидно, больше ОЗУ поможет - но, вероятно, не может облегчить его.

1 Есть некоторые споры относительно того, пытается ли MSSQL выделить слишком много ОЗУ, ОС выгружает ее или MSSQL просто выделяет неправильные пулы. В любом случае, max mem должен помочь в случаях 1 и 2, а SP2 должен решить 3.

Редактировать: коллега указал мне на связанную статью КБ с несколькими исправлениями в списке. Он ссылается на различные сообщения об ошибках (у вас работает SP2?), Но симптомы и поведение соответствуют вашей ситуации.