Ограничить максимальное использование процессора SQL SERVER с WSRM

У меня есть физический сервер, на котором запущен один экземпляр SQL Server.

Я заметил, что довольно часто этот сервер работает на 100% загрузки процессора.

Моя ИТ-команда не довольна этим и предложила зарезервировать 2 из 32 ядер для ОС.

Это прекрасно работает, теперь максимальный пик использования чуть менее 90%. Кроме того, более медленный поиск данных от различных пользователей больше не сообщается.

Есть ли причина НЕ использовать WSRM (диспетчер системных ресурсов Windows) таким образом - вместо регулятора ресурсов SQL?

Есть ли причина НЕ использовать тот подход, который вы определили? Абсолютно.

Представьте, что вы купили автомобиль - автомобиль, который, когда вы набираете 50 миль в час, начинает перегреваться. Будет ли ваша реакция на эту ситуацию искусственным ограничением автомобиля до 49 миль в час или выяснением неисправности двигателя?

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

Автомобиль, который вы купили, тоже был очень дорогим. Каждый цилиндр двигателя должен быть использован по максимуму, чтобы вы не тратили эти деньги впустую!

Искусственно ограничивая доступ SQL-серверов к процессору, вы теряете производительность. Возможно, вы временно решили проблемы с производительностью, убедившись, что ЦП доступен для использования ОС, но вы не ответили на реальный вопрос - ПОЧЕМУ SQL Server использует 100% ЦП?

Мой совет заключается в следующем:

Узнайте, какова реальная проблема, и исправьте ее. Не закрывайте вопрос тем, что фактически является клуджем. Вопрос БУДЕТ вновь и пороть вас в лице вниз линия , когда нагрузка на сервере , естественно , увеличивается с ростом.

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

Эрик Дарлинг упомянул самую большую практическую причину отказа от использования WSRM в комментарии к вашему вопросу:

... нет взаимного ограничения использования процессора в других процессах. SQL Server может не использовать эти два ядра, но другие 30 могут использовать другие 30 SQL Server. Это дерьмо, правда.

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

Эрик продолжает говорить

Кроме того, вы платите за них лицензию на SQL Server.

С точки зрения бизнеса, это, вероятно, худшая часть соглашения WSRM - вы платите за ядро ​​лицензирование для двух ядер, которые явно не используются. На момент написания этой статьи на столе оставалось $ 3 000 или $ 14 000 (в зависимости от Standard vs Enterprise).