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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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