Проблема производительности sql IA64
Там что-либо еще происходило на сервере Напоминания? Похож на сервер QA, имел только этот запрос для выполнения, в то время как система Напоминания должна была удовлетворить для ЦП другими запросами, работающими одновременно. Как elapsed_time и worker_time выдерживают сравнение в QA и Напоминании?
Кроме того, удостоверьтесь, что планы точно идентичны, включая МЕДНЫЙ ЗАЖИМ.
-
1Оба сервера имели другие вещи, работающие одновременно, однако Напоминание в целом значительно медленнее. Это был просто Запрос в качестве примера, который я выполнил для пользы сравнения, планы являются тем же, включая МЕДНЫЙ ЗАЖИМ и даже оцененные строки, предполагаемый io, и т.д. С высоким сигналом ожидают %, я согласовал бы это there' s давление ЦП однако I' m не уверенный, как начать диагностировать его кроме сказать, что 29% ожидают, CXPacket parralelism – Vendoran 9 December 2009 в 21:13
-
2МЕДНЫЙ ЗАЖИМ был тем же на обоих наборах в 2, однако я действительно изменял напоминание на 0 для тестирования, однако никакой реальный эффект, который я видел – Vendoran 9 December 2009 в 21:14
-
3С 8 ядрами, набор maxdop к 4. Затем протестируйте свой запрос снова. Порог стоимости является другим животным - пробуют 5, 25, 50, 75 и сравнивают результаты. Другой вещью, на которую Вы могли посмотреть, является SAN. Можно ли сделать сравнительные тесты для исключения этого? – 9 December 2009 в 21:26
-
4Существует много мест, которые можно искать. Ваш тест является записью (ВЫБОР... В), таким образом, это могла быть Ваша HBA/Fiber/SAN возможность соединения, перегружается на Напоминании. Могла быть местность NUMA (возможно, Вам нужно affinitize клиентам). У поставщиков есть настраивающиеся бумаги, как docs.hp.com/en/8875/WIE-SQLTuning-1006-00.pdf . – Remus Rusanu 9 December 2009 в 21:34
-
5Я проверил бы подсистему ввода-вывода сначала. bandwith проблема с SAN могла привести к очевидному давлению ЦП, потому что запросы остаются дольше в системе, таким образом создавая давление планировщика (многие рабочие заняты). Сравните ' В среднем. sec/Transfer' на Физических дисках в этих двух системах. – Remus Rusanu 9 December 2009 в 21:36
У меня есть несколько предположений для вещей, что Вы могли бы заняться расследованиями на SAN:
Вы видите, что значительная страница I/O фиксироваться ожидает на производстве SAN?
Действительно ли вход в систему DB является занятым совместно используемым томом?
В бывшем случае могла быть конфигурация SAN или другая проблема производительности, касающаяся контроллеров SAN. Я видел, что это происходит на аппаратных средствах акулы IBM; перемещение в DS8000 существенно смягчило проблему.
В последнем случае Вы могли получать проблемы со случайным поиском, разрушающим действие записи журнала. Записи журнала являются главным образом последовательным процессом с большими количествами маленьких последовательных записей. На тихих дисках это быстро, поскольку шаблоны доступа к диску главным образом последовательны. На занятых дисках другой дисковый трафик превращает последовательные записи журнала в случайные записи, которые намного медленнее. Это может превратить диски журнала в значительное узкое место производительности.
Обратите внимание, что SQL Server требует, чтобы записи журнала были сброшены к диску, прежде чем транзакция будет фиксировать, и большинство поставщиков SAN зарегистрировалось в программе сертификации, где они гарантируют, что контроллеры будут соблюдать этот стандарт. Это означает, что никакая сумма кэш-памяти не смягчит эту проблему, если Ваши журналы будут находиться на занятом совместно используемом томе.
"Таким образом, Это походит на связанную с процессором проблему, однако я не уверен, куда пойти затем, какие-либо идеи?"
Кажется весьма разумным мне, что Архитектура Core 2 на 3.5 ГГц, ЦП, возможно, на 100% быстрее, чем Itanium на 1.6 ГГц (разве Intel Family 80000002 не является исходным семейством Itanium 2, Фанвудом или Мадисоном?). Если Вы нуждаетесь в большей скорости, смотрите на обновление ЦП, возможно, к x5600 серии Xeon.