Почему использование ЦП так несимметрично на нашем сервере SQL Server с 8 процессорами?
Я заметил, что использование ЦП на нашем сервере базы данных с 8 процессорами, на котором работает SQL Server 2008, совсем не сбалансировано.
Вот средние значения за один день для случайного дня некоторое время назад, что типично и неизменно асимметрично:
9, 15, 10, 21, 18, 21, 14, 9
(здесь только эскиз, потому что изображение действительно высокий, но нажмите, чтобы просмотреть изображение в полный размер)
По сравнению с нашими веб-серверами с 4 процессорами, которые почти точно и идеально сбалансированы все время, это показалось мне странным.
Теперь это выделенный сервер, поэтому единственное, что на нем работает, - это SQL Server 2008 (и встроенная полнотекстовая индексация, которую мы довольно часто используем), поэтому я не уверен почему использование процессора было бы таким асимметричным. Мысли?
Шкалы у всех разные, кроме пика на 4 графиках, ваши средние значения будут примерно 10-25%.
Как настроены ваши файлы / файловые группы?
Я буду заниматься плагиатом себя:
Еще одна мысль о вводе-выводе: мы тщательно настроили наши самые часто используемые таблицы в файловых группах с несколькими файлами в них. Одно из улучшений производительности заключается в том, что SQL будет направлять запросы к каждому файлу в файловой группе, поэтому, если BigOverUsedTable находится в FileGroup1, а FileGroup1 имеет четыре файла в нем, а ваша БД имеет 8 ядер, он фактически будет использовать четыре ядра для выбора большое число, обрабатывающее неприятный запрос из BigOverUsedTable "- в противном случае он будет использовать только один процессор. Мы получили эту идею из этой статьи MSDN:
http://msdn.microsoft.com/en-us/library/ms944351.aspx
Из TFA:
«Файловые группы используют параллельные потоки для улучшения доступа к данным. При последовательном доступе к таблице система создает отдельный поток для каждого файла параллельно. Когда система выполняет сканирование таблицы для таблицы в файловой группе с четырьмя файлами, она использует четыре отдельных потоков для параллельного чтения данных. В общем, использование нескольких файлов на отдельных дисках повышает производительность. Слишком много файлов в файловой группе может вызвать слишком много параллельных потоков и создать узкие места ».
Благодаря этому совету у нас есть четыре файла в нашей файловой группе на 8-ядерном компьютере. Это хорошо работает.
Изменить: теперь у этого есть другой (возможно) лучший ответ. Графики были не в масштабе - если вы присмотритесь, каждый процессор фактически загружен примерно на 20%, как указывает uzbones.
Изменить: мы действительно можем сказать, что использование нескольких файловых файловых групп помогает, потому что мы не поместили все наши таблицы в файловую группу с четырьмя файлами. Большие запросы к файловой группе "один файл" используют только один ЦП, но запросы к таблице в файловой группе с четырьмя файлами затрагивают 4 ЦП.
Проверь это:
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 не было такого же поведения)