Проблема производительности SQL IA64

Question

Проблема производительности SQL IA64

У нас проблемы с производительностью.

Среды QA и DEV представляют собой 2 экземпляра на одном физическом сервере: Windows 2003 Enterprise SP2, 32 ГБ ОЗУ, 1 четырехъядерный 3,5 ГГц Intel Xeon X5270 (4 ядра x64), SQL 2005 SP3 (9.0.4262), диски SAN

Продукт: Windows 2003 Datacenter SP2, 64 ГБ ОЗУ, 4-ядерный процессор семейства Intel 80000002 с частотой 1,6 ГГц, модель 6 Itanium (8 ядер IA64), SQL 2005 с пакетом обновления 3 (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, логическое чтение с 0, физическое чтение с 0, чтение с опережением 0.

Как вы можете видеть, это просто логические чтения: QA: 0:48 Prod: 2:18

Так что это похоже на проблему с процессором, однако я не уверен, куда идти дальше, есть идеи?

Спасибо,

Аарон

1

sql-server performance itanium

Источник

Vendoran 09 дек '09 в 17:13

4 ответа

Другие вопросы по тегам sql-server performance itanium

Vendoran 14 апр '10 в 01:14 2010-04-14 01:14 · Answer 1 · 2010-04-14 01:14

Это было вызвано двумя проблемами - индексами, различными для prod и QA, а также неправильно настроенным maxdop.

2

Источник

Vendoran 14 апр '10 в 01:14

ConcernedOfTunbridgeWells 18 фев '10 в 15:32 2010-02-18 15:32 · Answer 2 · 2010-02-18 15:32

У меня есть пара предложений для вещей, которые вы можете исследовать в сети SAN:

Видите ли вы значительную страницу защелки ввода / вывода в производственной сети SAN?
Журналы БД заняты общим томом?

В первом случае может быть конфигурация SAN или другие проблемы с производительностью, относящиеся к контроллерам SAN. Я видел это на оборудовании IBM shark; переход на DS8000 существенно смягчил проблему.

В последнем случае у вас могут возникнуть проблемы со случайным поиском, что может нарушить процесс записи журнала. Запись в журнал - это в основном последовательный процесс с большим количеством небольших последовательных записей. На тихих дисках это быстро, так как шаблоны доступа к диску в основном последовательные. На занятых дисках другой дисковый трафик превращает последовательные записи журнала в случайные записи, которые намного медленнее. Это может превратить диски журналов в существенное узкое место производительности.

Обратите внимание, что SQL Server требует, чтобы записи журнала были записаны на диск до того, как транзакция будет зафиксирована, и большинство поставщиков SAN зарегистрировались в программе сертификации, где они гарантируют, что контроллеры будут соблюдать этот стандарт. Это означает, что никакое количество кэш-памяти не уменьшит эту проблему, если ваши журналы находятся на занятом общем томе.

Remus Rusanu 09 дек '09 в 17:38 2009-12-09 17:38 · Answer 3 · 2009-12-09 17:38

Что-нибудь еще происходило на сервере Prod? Похоже, что на сервере QA должен был выполняться только этот запрос, в то время как система Prod должна была обрабатывать данные для ЦП, в то время как другие запросы выполнялись одновременно. Как сравнить elapsed_time и worker_time в QA и Prod?

Также убедитесь, что планы точно такие же, включая DOP.

xenny 26 мар '10 в 12:48 2010-03-26 12:48 · Answer 4 · 2010-03-26 12:48

"Так что это похоже на проблему с процессором, однако я не уверен, куда идти дальше, есть идеи?"

Мне кажется вполне разумным, что процессор Core 2 с архитектурой 3,5 ГГц, возможно, на 100% быстрее, чем Itanium 1,6 ГГц (не семейство Intel 80000002, оригинальное семейство Itanium 2, Fanwood или Madison?). Если вам нужна большая скорость, обратите внимание на обновление процессора, возможно, до Xeon серии x5600.