Почему загрузка процессора настолько асимметрична на нашем сервере SQL Server с 8 процессорами?
Я заметил, что загрузка ЦП на нашем сервере баз данных с 8 процессорами, работающем под управлением SQL Server 2008, совершенно не сбалансирована.
Вот средние значения за 1 день для случайного дня назад, что является типичным и постоянно асимметричным:
9, 15, 10, 21, 18, 21, 14, 9
(здесь только миниатюра, потому что изображение очень высокое, но кликните на изображение для увеличения)
По сравнению с нашими четырехпроцессорными веб-серверами, которые все время практически точно и идеально сбалансированы, это показалось мне странным.
Теперь это выделенный сервер, поэтому на нем работает только SQL Server 2008 (и встроенная полнотекстовая индексация, которую мы довольно интенсивно используем), поэтому я не уверен, почему загрузка ЦП будет такой асимметричной, Мысли?
5 ответов
Как настроены ваши файлы / файловые группы?
Я сам плагиат
Еще одна мысль о IO: мы старались настроить наши самые часто используемые таблицы, чтобы они находились в файловых группах с несколькими файлами в них. Одним из улучшений производительности является то, что SQL будет направлять запросы к каждому файлу в файловой группе - поэтому, если BigOverUsedTable находится в FileGroup1, а FileGroup1 содержит четыре файла, а ваша БД имеет 8 ядер, он фактически будет использовать четыре ядра для выбора. большое число хрустит грязный запрос от BigOverUsedTable" - тогда как в противном случае он будет использовать только один процессор. Мы получили эту идею из этой статьи MSDN:
http://msdn.microsoft.com/en-us/library/ms944351.aspx
Из ТФА:
"Файловые группы используют параллельные потоки для улучшения доступа к данным. Когда к таблице обращаются последовательно, система создает отдельный поток для каждого файла параллельно. Когда система выполняет сканирование таблицы для таблицы в файловой группе с четырьмя файлами, она использует четыре отдельных Потоки для параллельного чтения данных. Как правило, использование нескольких файлов на отдельных дисках повышает производительность. Слишком большое количество файлов в файловой группе может вызвать слишком большое количество параллельных потоков и создать узкие места ".
Благодаря этому совету у нас есть четыре файла в нашей файловой группе на 8-ядерном компьютере. Это хорошо работает.
Изменить: теперь есть другой (возможно) лучший ответ. Графики были не в масштабе - если вы внимательно посмотрите, каждый процессор загружен примерно на 20%, как отмечают узбоны.
Изменить: мы можем сказать, что использование нескольких файловых групп помогает, потому что мы не поместили все наши таблицы в файловую группу с четырьмя файлами. Большие запросы к файловой группе "один файл" используют только один ЦП, но запросы к таблице в четырех файловой группе работают с 4 ЦП.
Шкалы различны для всех из них, кроме скачка на 4 графиках, ваши средние значения будут примерно 10-25%.
Проверь это:
http://blogs.technet.com/mat_stephen/archive/2005/02/02/365325.aspx
SQL может записывать только несколько файлов, и каждый процессор использует каждый файл.
Первое, что я проверяю на такие вещи, это драйверы. У меня было много проблем с сетевым объединением и драйверами iSCSI MPIO, работающими на определенных ядрах. Могу поспорить, что это не проблема здесь, хотя, похоже, что это происходит на 4 ядрах - я обычно вижу это только с 2 ядрами. Я спрошу вокруг, чтобы увидеть, видел ли кто-нибудь это так широко.
Я также видел это с блоками NUMA, где есть несоответствие памяти - скажем, половина ядер подключена до 16 ГБ оперативной памяти, а остальные - до 8. Google для IBM x460 NUMA, если вы хотите увидеть некоторую забавную информацию об этом. Модели 460 и связанные с ними модели позволяют объединить несколько серверов в цепочку, чтобы создать большое железо - что-то вроде укрупнения в блоге. Они классные машины.
Потому что очистка кэшей ЦП настолько невероятно дорога, что ядро пытается избежать этого любой ценой.
(Примечание: по крайней мере, Linux это делает; я был бы удивлен, если бы у Windows не было такого поведения)