Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

  • нет или плохие индексы
  • функции для столбцов в предложении WHERE (= игнорируемые индексы)
  • преобразование типов данных / приоритет (= игнорируемые индексы)
  • Скалярные udf с доступом к таблицам в предложениях SELECT (= влияние CURSOR)
  • Запросы представлений / СОЕДИНЕНИЕ с представлениями (представление - это макрос, который расширяется)

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

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