Я пытаюсь определить узкое место в новой реализации SQL Server (2012 Enterprise). Я выполнял несколько сложных запросов / заданий ETL, которые занимают много времени, но мне трудно определить, что является ограничивающим фактором.
Сервер представляет собой Dell R720 с двумя процессорами Intel (R) Xeon (R) E5-2609 0 @ 2,40 ГГц (по 4 ядра). Он имеет 384 ГБ оперативной памяти.
Хранилище данных - это массив MD1220, заполненный 24 твердотельными накопителями Dell по 400 Гбайт. Массив подключается через 2 соединения SAS по 6 Гбайт к H810 с кеш-памятью 1 Гбайт.
Хранилище для журналов - это 15 вращающихся дисков Dell по 600 ГБ 15K во внутренних отсеках R720, подключенных к внутреннему контроллеру H710P.
База данных, с которой я работаю, составляет 200 ГБ, поэтому должна полностью уместиться в ОЗУ. Коэффициент попадания в кэш составляет 99,997%, что позволяет предположить, что это так. Поэтому я ожидал, что ограничивающим фактором будет ЦП, но ЦП работает примерно на 10%. Ни одно из отдельных ядер не нагревается. Использование ввода-вывода для обоих массивов (данные и журнал) и в обоих направлениях (чтение и запись) также составляет менее 50 МБ / с - и я считаю, что он должен быть в состоянии приблизиться к насыщению SAS.
Я поигрался с MAXDOP (в настоящее время установлен на 4) безрезультатно.
Запросы, которые я использую, в основном манипулируют данными, а не извлекают данные и не отправляют их по сети, а пропускная способность сети минимальна.
Есть идеи, где может быть узкое место? Может быть, скорость памяти или внутренней шины? Есть предложения относительно того, где я должен искать дальше?
Спасибо,
Майк
а. Вы проверяли состояние ожидания запущенного запроса? Выберите * из sys.sysprocesses. B. есть ли на месте губернатор ресурсов? c. вы использовали подсказку перекомпиляции, чтобы проверить это? d. вы проверили план запроса? е. Вы пытались заставить план работать в параллельном режиме с помощью dbcc cpuweight? f. вы обновляли статистику таблиц?