На производстве у нас есть несколько серверов, 4 из которых имеют очень похожую конфигурацию оборудования. Dell PowerEdge R620, единственное отличие состоит в том, что 2 новейших (купленных и настроенных 3 месяца назад) имеют RAID-контроллер v710, 256 ГБ ОЗУ и ЦП 2 физических Xeon E5-2680 2,80 ГГц. Старые (купленные и настроенные около 1 года назад) имеют RAID-контроллер v700, 128 ГБ ОЗУ и работают на физическом Xeon E5-2690 2,90 ГГц. BIOS обновлен, все драйверы обновлены до последних версий и т. Д. Все версии SQL Server 2008R2 Enterprise (SP1) обновлены до последней версии CU и Windows 2012R2 Standard. Оба работают на 200 ГБ SSD x5 RAID10. На каждой из них работает только одна база данных, синхронизированная с помощью задания, вызывающего пакет служб SSIS. Наш системный администратор провел много тестов производительности и стресс-тестов, чтобы убедиться, что у нас нет конфигурации или сбоев в работе оборудования или сети. Как и ожидалось, новейшие показывают лучшие результаты производительности. Все идет нормально.
Проблему, которую мы имеем, можно увидеть на снимке экрана с Kibana. Желтый и оранжевый - это два новых сервера (6,7 на таблицах) и ниже всех других серверов. Совершенно очевидно, что эти 2 новых сервера имеют более медленное время отклика. И не только это, но и эти 2 сервера имеют немного меньшую нагрузку, чем 2 более старых (светлые и синие линии - 4,5 на таблицах).
Есть несколько сценариев мониторинга, собирающих информацию о счетчиках перфорации. Покопавшись как можно дальше с DMV и третьими инструментами мониторинга, у меня под рукой много информации. Но должно быть (оф) что-то, чего мне здесь не хватает, так как я не могу найти ответ на это более медленное время отклика.
Два новейших сервера используют меньше оперативной памяти, но я полагаю, что это ожидается, по сравнению с другими более старыми серверами, поскольку они имеют меньшую нагрузку.
| Server Name| Mem_MB | Mem_GB | Server_RAM_GB | SQL_max_mem_GB| SQL_min_mem_GB |
|------------|--------|--------------|---------------|---------------|----------------|
| 4 | 41108 | 40.145263671 | 128 | 120 | 16 |
| 5 | 61272 | 59.836425781 | 128 | 120 | 16 |
| 6 | 34117 | 33.317626953 | 256 | 250 | 16 |
| 7 | 33764 | 32.972656250 | 256 | 250 | 16 |Конфигурация ОЗУ для всех серверов выглядит следующим образом:
| Server Name | Total_Page_File_In_MB | Available_Page_File_MB | Kernel_Paged_Pool_MB | Kernel_Nonpaged_Pool_MB |
|-------------|-----------------------|------------------------|----------------------|-------------------------|
| 4 | 180160 | 130042 | 249 | 98 |
| 5 | 148416 | 77246 | 249 | 110 |
| 6 | 301010 | 260453 | 132 | 99 |
| 7 | 301010 | 260454 | 143 | 108 |Выполнение следующего запроса на всех серверах показывает одинаковые параметры конфигурации:
SELECT * FROM master.sys.configurationsЯ мог бы показывать намного больше информации, но я не совсем уверен, что может понадобиться. Любая подсказка о том, что я должен проверить?
Я прочитал известный технический документ из MS Устранение проблем с производительностью в SQL Server 2008 и получил оттуда много запросов DMV.
РЕДАКТИРОВАТЬ По запросу:
EXEC sp_configure 'max server memory (MB)'
| Server Name | name | minimum | maximum | config_value | run_value |
|-------------|------------------------|---------|------------|--------------|-----------|
| 4 | max server memory (MB) | 16 | 2147483647 | 120000 | 120000 |
| 5 | max server memory (MB) | 16 | 2147483647 | 120000 | 120000 |
| 6 | max server memory (MB) | 16 | 2147483647 | 250000 | 250000 |
| 7 | max server memory (MB) | 16 | 2147483647 | 250000 | 250000 |Что касается того, что maxdopмы играем с этим, и результаты:
EXEC sp_configure 'max degree of parallelism'
| Server Name | name | minimum | maximum | config_value | run_value |
|:-----------:|:-------------------------:|:-------:|:-------:|:------------:|:---------:|
| 4 | max degree of parallelism | 0 | 1024 | 1 | 1 |
| 5 | max degree of parallelism | 0 | 1024 | 1 | 1 |
| 6 | max degree of parallelism | 0 | 1024 | 1 | 1 |
| 7 | max degree of parallelism | 0 | 1024 | 1 | 1 |
Ответы:
Это изображение говорит само за себя.
Спасибо Кин за указание на ваш вопрос и связанные с ним ответы. Я многому научился в процессе. Рассматривая ваш подробный вопрос, я подумал о том же, сравнивая планы выполнения нашего самого тяжелого запроса ... и вуаля !! Проблемы были работой, которая должна была выполняться уже пару недель с отключенным графиком. Теперь я должен проверить, почему он был отключен и когда именно был отключен. Сейчас все идет гладко. Синяя линия - это один сервер, не получающий запросы из-за технического обслуживания, не мертвый.
источник