Вызывает ли большое использование памяти SQL Server ошибки?

Question

Просто начал получать кучу ошибок в нашем приложении C # .Net, которые, казалось, происходили без причины. Такие вещи, как System.IndexOutOfRangeException для объекта SqlDataReader для индекса, который должен быть возвращен и возвращался в течение некоторого времени.

В любом случае, я посмотрел на диспетчер задач и увидел, что sqlservr.exe работал на 150000000 K Mem Usage. Я ни в коем случае не администратор баз данных, но такое большое использование памяти выглядело мне неправильно на Win Server 2003 R2 Enterprise с Intel Xeon 3,33 ГГц с 4 ГБ оперативной памяти. Поэтому я перезапустил экземпляр SQL Server. После перезагрузки все вернулось на круги своя. Ошибки внезапно перестали происходить. Так что такое большое использование основной памяти в конечном итоге вызывает ошибки?

Кроме того, я сделал быстрый Google для высокого использования памяти mssql . Я обнаружил, что если оставить настройки по умолчанию; SQL Server может стать таким большим. Также нашел ссылку на MS о Как настроить использование памяти с помощью параметров конфигурации в SQL Server .

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

Answer 1

Я, конечно, был бы очень удивлен, если это сама база данных, SQLServer - чрезвычайно надежный продукт - намного лучше, чем что-либо в Office или самой Windows, и на него можно полностью и полностью положиться.

1,5 ГБ - это ничего для rdbms - и все они будут просто заполнять свои доступные буферы кэшированными данными. Чтение в ядре, как правило, в 1000 раз и более быстрее, чем доступ к диску, поэтому оптимальным вариантом является использование каждого куска памяти, доступного для него. Фактически, если вы посмотрите на любую теорию проектирования СУБД, вы увидите, что алгоритмам, используемым для определения того, что следует выбрасывать из ядра, уделяется значительное внимание, поскольку это сильно влияет на производительность.

Большинство выделенных серверов БД будут работать с 4 ГБ памяти (при условии 32-битной), при этом 90% выделено для SQL Server, поэтому вы, конечно, не смотрите здесь на какие-либо граничные условия.

Ваша наиболее вероятная проблема - ошибка кодирования или структурная проблема (например, блокировка)

Хотя у меня есть одно предупреждение. Очень (очень, очень - как два раза в 10 лет) иногда я видел ошибки возврата страниц SQL Server из-за повреждения файлов базы данных, оба раза вызванные периодическим аппаратным отказом. К счастью, в обоих случаях они были на страницах, содержащих индексы, и, удалив индекс, восстановив базу данных, сделав резервную копию и восстановив на новый диск, я смог восстановить ее, не возвращаясь к резервным копиям. Я не уверен относительно того, как ошибка разрыва страницы будет передаваться в API C #, но, возможно, если у вас есть ошибка диска, которая проявляется только после заполнения ядра (то есть где-то в некотором пространстве подкачки), то ошибка индекса вне границ это действительно то проявление, которое я ожидал, так как вызов мог возвращать ненужную информацию - следовательно, выходить за пределы диапазона массива.

Answer 2

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

Если блок является выделенным блоком SQL, нередко можно настроить его на использование примерно 90% ОЗУ на блоке ....

Однако, если это общий ящик, имеющий другие цели, могут быть и другие соображения.

Answer 3

1,5 ГБ из 4,0 ГБ вряд ли обременительны ... Один из наших серверов обычно работает на 1,6 ГБ из 2,5 ГБ без проблем. Я думаю, что я был бы более обеспокоен, если бы он не использовал так много.

Я не хочу показаться грубым, но я бы не стал так быстро обвинять SQL Server в ошибках приложений. Исходя из моего опыта, каждый раз, когда я пытался переложить ответственность на SQL Server, это укусило меня в задницу. Обычно это системные администраторы или мошеннические запросы, которые ставят наш сервер на колени.

Было несколько раз, когда решение медленного запроса состояло в том, чтобы перезапустить сервер вместо проверки запроса, которые почти всегда были ошибочными. Я знаю, что лично переписал около десятка запросов, стоимость которых была значительно выше 100.

Это действительно звучит так, как будто "select" не работает ", поэтому мне любопытно, можете ли вы найти какие-либо улучшения в вашем коде.

Answer 4

сколько основной памяти должно быть MSSQL должно быть ограничено до

Столько, сколько вы можете дать, при этом обеспечивая правильную работу других системных служб. Да, это неопределенный ответ, но на выделенной коробке БД MSSQL будет вполне доволен 90% ОЗУ или около того. По замыслу это займет столько памяти, сколько может.

Answer 5

SQL нужен оперативная память, которую он принимает. Если он использовал 1,5 гигабайта, то использовал его для кеширования данных, кеша процедур и т. Д. Как правило, лучше оставить его в покое - если вы установите слишком низкое ограничение, это приведет к снижению производительности. Если он использует 1,5 гигабайта на 4-гигабайтном веб-боксе, я бы не назвал это ненормальным.

Скорее всего, ваши ошибки могли быть вызваны блокировкой - мне было бы трудно сказать, что использование памяти SQL, которое вы определили в вопросе, вызывало ошибки, которые вы получали.