Более низкая производительность на новейших серверах


8

На производстве у нас есть несколько серверов, 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     |

Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Пол Уайт 9

Ответы:


1

Это изображение говорит само за себя.

введите описание изображения здесь

Спасибо Кин за указание на ваш вопрос и связанные с ним ответы. Я многому научился в процессе. Рассматривая ваш подробный вопрос, я подумал о том же, сравнивая планы выполнения нашего самого тяжелого запроса ... и вуаля !! Проблемы были работой, которая должна была выполняться уже пару недель с отключенным графиком. Теперь я должен проверить, почему он был отключен и когда именно был отключен. Сейчас все идет гладко. Синяя линия - это один сервер, не получающий запросы из-за технического обслуживания, не мертвый.

введите описание изображения здесь

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.