Проблема доступности SQL-сервера: большой запрос останавливает подключение других соединений

У меня есть сервер высокой спецификации (многоядерный, RAID) под управлением MS SQL 2008 с несколькими базами данных на нем. У меня процесс с низкой пропускной способностью, которому периодически требуется небольшое количество информации из одной из БД, и код, кажется, работает нормально.

Однако иногда, когда один из моих коллег делает огромный запрос к одной из других БД, я вижу полную загрузку ЦП на машине и время ожидания соединений из моего приложения.

Почему это происходит? Я бы подумал, что многие ядра и жесткие диски каким-то образом (вместе с грамотно написанным сервером БД) смогут оставить хотя бы некоторые ресурсы свободными для других приложений? Я почти уверен, что он не использует несколько соединений для своего запроса.

Что я могу сделать, чтобы предотвратить это?

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

У меня нет особых подробностей об оборудовании. Он использует обычные жесткие диски, рейдерские, с сервером 2k3. Это HP, возможно, пару лет. В принципе, для меня нет смысла в том, что проблема в аппаратном обеспечении, поэтому я решил, что, возможно, что-то настроил неправильно?

Источник

2 ответа

Пока вы уверены, что вы оптимизировали настолько, насколько вы можете, вы можете посмотреть на свои настройки для параллелизма; по умолчанию используются все процессоры для параллельных запросов, вы можете изменить его на максимальное при меньшем числе в зависимости от количества процессоров, которое у вас есть, запрос может занять немного больше времени, но он должен оставить достаточную вычислительную мощность свободной для Сервисные запросы на вход. Если проблема связана с этим одним запросом, а не для изменения общесистемных настроек, вы можете попросить коллегу изменить его / ее запрос, добавив параметр MAXDOP, чтобы посмотреть, поможет ли это.

Источник

Это означает, что у вас чрезвычайно субоптимальный запрос. Обычные подозреваемые:

  • нет или плохие показатели
  • функции для столбцов в предложении WHERE (= игнорируемые индексы)
  • преобразования типов данных / приоритет (= игнорируемые индексы)
  • Скалярные udf с доступом к таблице в предложениях SELECT (= CURSOR влияет)
  • Представления, запрашивающие / объединяющиеся с представлениями (представление - это макрос, который расширяется)

Это также может быть простой проблемой с ресурсами: возвращаются ли возвращаемые данные ко всей базе данных, поэтому она использует слишком много памяти для подкачки? Или вы получаете ASYNC_NETWORK_IO ожидания, которые могут означать, что клиент не принимает результаты так быстро, как следовало бы?

Как правило, если вы максимально используете сервер, то это плохой код и / или дизайн, а не механизм БД.

Источник
Другие вопросы по тегам