У нас проблемы с производительностью.
Среды QA и DEV - это 2 экземпляра на одном физическом сервере: Windows 2003 Enterprise SP2, 32 ГБ ОЗУ, 1 Quad 3,5 ГГц Intel Xeon X5270 (4 ядра x64), SQL 2005 SP3 (9.0.4262), диски SAN
Продукт: Windows 2003 Datacenter SP2, 64 ГБ ОЗУ, 4 двухъядерных процессора Intel Family 80000002 с тактовой частотой 1,6 ГГц, модель 6 Itanium (8 ядер IA64), SQL 2005 SP3 (9.0.4262), диски SAN, кластер Veritas
Я наблюдаю завышенные проценты ожидания сигнала (> 250%), а количество операций чтения страниц (> 50) и операций записи страниц (> 25) иногда бывает высоким.
Я тестировал этот запрос как в QA, так и в PROD, и у него одинаковый план выполнения и даже одинаковая статистика:
SELECT
top 40000000 *
INTO
dbo.tmp_tbl
FROM
dbo.tbl
GO
Счетчик сканирования 1, логических чтений 429564, физических чтений 0, упреждающих чтений 0, логических чтений lob 0, физических чтений lob 0, упреждающих чтений lob 0.
Однако, как видите, это всего лишь логическое чтение: QA: 0:48 Prod: 2:18
Похоже, проблема связана с процессором, но я не уверен, что делать дальше, есть идеи?
Спасибо,
Аарон
Это было вызвано двумя проблемами: разные индексы между prod и QA, а также неправильно настроенный maxdop.
У меня есть несколько предложений по поводу того, что вы могли бы исследовать в SAN:
Вы видите значительное ожидание защелки ввода-вывода страницы в производственной сети SAN?
Находятся ли журналы БД на занятом общем томе?
В первом случае может быть конфигурация SAN или другая проблема производительности, связанная с контроллерами SAN. Я видел, как это происходило на оборудовании акулы IBM; переход на DS8000 существенно смягчил проблему.
В последнем случае у вас могут возникнуть проблемы со случайным поиском, нарушающим активность записи журнала. Запись в журнал - это в основном последовательный процесс с большим количеством небольших последовательных записей. На тихих дисках это происходит быстро, поскольку шаблоны доступа к диску в основном последовательны. На занятых дисках другой дисковый трафик превращает последовательные записи журнала в случайные записи, которые выполняются намного медленнее. Это может превратить диски журналов в серьезное узкое место для производительности.
Обратите внимание, что SQL Server требует, чтобы записи журнала были сброшены на диск до того, как транзакция будет зафиксирована, и большинство поставщиков SAN зарегистрировались в программе сертификации, где они гарантируют, что контроллеры будут соблюдать этот стандарт. Это означает, что никакой объем кэш-памяти не решит эту проблему, если ваши журналы находятся на занятом общем томе.
Что-нибудь еще происходило на сервере Prod? Похоже, что у QA-сервера был только этот запрос для выполнения, в то время как система Prod должна была загружать контент для ЦП с другими запросами, выполняемыми в то же время. Как elapsed_time и worker_time сравнить в QA и Prod?
Также убедитесь, что планы полностью идентичны, включая DOP.
«Так что, похоже, проблема связана с процессором, но я не уверен, что делать дальше, есть идеи?»
Мне кажется вполне разумным, что процессор с архитектурой Core 2 с тактовой частотой 3,5 ГГц, возможно, на 100% быстрее Itanium с тактовой частотой 1,6 ГГц (разве семейство Intel 80000002 не является исходным семейством Itanium 2, Fanwood или Madison?). Если вам нужно больше скорости, подумайте об обновлении ЦП, возможно, до Xeon серии x5600.