Долгосрочный запрос SQL Server с часами, но с использованием низкого процессора

Question

Я запускаю некоторые хранимые процедуры в SQL Server 2012 под Windows Server 2012 на выделенном сервере с 32 ГБ оперативной памяти и 8 ядер процессора. Использование ЦП всегда ниже 10%, а объем использования ОЗУ - 80%, поскольку SQL Server имеет 20 ГБ (32 ГБ).

Существует несколько хранимых процедур, которые занимают 4 часа в несколько дней и в другие дни с почти одинаковыми данными, занимают 7 или 8 часов.

Я использую наименее ограничительный уровень изоляции, поэтому я думаю, что это не должно быть проблемой блокировки. Размер базы данных составляет около 100 ГБ, а в самой большой таблице - около 5 миллионов записей.

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

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

У меня есть несколько вопросов:

1. Можно ли повысить производительность запросов с использованием параллелизма?
2. Почему загрузка процессора настолько низка?
3. Каковы наилучшие методы настройки SQL Server?
4. Каковы лучшие бесплатные инструменты для аудита сервера? Я попробовал один от Microsoft под названием SQL Server 2012 BPA, но в отчете всегда пустым без предупреждений.

EDIT: Я проверил журнал, и я нашел это:

03/18/2015 11: 09: 25, spid26s, Unknown, SQL Server обнаружена 82 возникновения (ов) из I/O запросы, занимающие более 15 секунд, для завершения в файле [C: \ Program Files \ Microsoft SQL Server \ MSSQL11.HLSQLSERVER \ MSSQL \ DATA \ templog.ldf] в базе данных [tempdb] (2). Файл дескриптора ОС - 0x0000000000000BF8. Смещение последнего длинного ввода-вывода: 0x00000001fe4000

Answer 1

1. Увеличение максимальной памяти до 24 ГБ.
2. Переместите tempdb с диска c и рассмотрите файлы с несколькими tempdb, с автоматическим увеличением не менее 128 Мбит/с или 256 Мбит/с.
3. Установите панель показателей производительности и запустите отчет служебной панели, чтобы узнать, какие запросы запущены и проверьте ожидания.
4. Если вы используете альт-бросок в логах пользовательских данных и лог-файлах на 10%, измените это на что-то похожее на рост темпдб выше.
5. Использование контрольной панели Performance Performance для очевидных отсутствующих индексов, которые прогнозируют 95% -ное повышение эффективности.
6. Не обращайте внимания на всех людей, говорящих, что они не делают то, что я предлагаю. Если вы делаете эти 5 вещей, и у вас по-прежнему возникают проблемы, вы можете опубликовать некоторые результаты с панели управления эффективностью, которая, кстати, бесплатна.
7. Еще одна вещь, которая может быть полезной, загрузить и установить sp_whoisactive сохраненный процесс, запустить его и посмотреть, какие процессы запущены. Изучите запросы, которые вы найдете после запуска sp_whoisactive.

Answer 2

запрос с использованием часов, но низкий CPU

Вы говорите, что, как если процессор будет иметь значения для большинства операций БД. СОВЕТ: Они этого не делают.

Базы данных нуждаются в IO. RAM в некоторых случаях помогает смягчить это, но в конце он работает до IO.

И вы знаете, что я вижу в вашем вопросе? CPU, Memory (так или иначе, предполагая, что 32gb впечатляет), но НИЖЕ СЛОВО НА ДИСКАХ.

И это важно. Диски, распространение файлов для распространения нагрузки.

Если вы посмотрите на счетчики производительности, то вы увидите, что латентность является сверхвысокой на дисках, - потому что любой «жалкий» (в sql server terms) формат диска у вас там, это просто не соответствует задаче.

Время, чтобы начать покупать. SSD намного дешевле дисков. Вы можете сказать: «О, как они дешевле». Ну, вы не покупаете GB - вы покупаете IO. И последний раз, когда я проверил SSD, не стоил в 100 раз больше цены на диски, но у них есть 100 и более раз IO. и мы всегда говорим о случайном IO.

Затем изолируйте Tempdb на отдельном SSD-накопителе - tempdb либо не много, либо TON, и вы хотите это увидеть.

Затем изолируйте файл журнала.

Сделайте несколько файлов данных для базы данных и tempdb (в частности, tempdb - столько, сколько у вас есть).

И да, это будет стоить денег. Но в конце - вам нужно IO, и, как и большинство разработчиков, вы получили CPU. Плохо для базы данных.