Назад | Перейти на главную страницу

Плохая производительность на лучшем оборудовании

У меня есть потоковая репликация postgresql на 2 хостах, и я столкнулся с проблемой разной производительности по сравнению с двумя серверами. Похоже, что все sql-запросы на одном хосте медленнее на 70-90%, чем на другом.

Сначала я проверил отчеты о запросах от обоих серверов и обнаружил, что почти все запросы в главном отчете медленнее, чем соответствующие запросы из резервного отчета. Я протестировал несколько примеров запросов на обоих хостах и ​​получил тот же результат - запросы на главном хосте выполняются медленнее, чем на резервном.

Я предположил, проблема в другом управлении питанием. Но управление питанием отключено на обоих хостах, не включены регуляторы масштабирования и нет каталогов "cpufreq" в "/ sys / devices / system / cpu / cpuX /"

Затем я сравнил оборудование и обнаружил только одно отличие: более медленный хост имеет новые процессоры, чем более быстрый режим ожидания.

Мастер (который медленнее)

CPU1 Version: Intel(R) Xeon(R) CPU           E5630  @ 2.53GHz --- Signature: Type 0, Family 6, Model 44, Stepping 2
CPU2 Version: Intel(R) Xeon(R) CPU           E5630  @ 2.53GHz --- Signature: Type 0, Family 6, Model 44, Stepping 2
16x DDR3 DIMM 4096MB 1333MHz

В режиме ожидания (что быстрее)

CPU1 Version: Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz --- Signature: Type 0, Family 6, Model 26, Stepping 5
CPU2 Version: Intel(R) Xeon(R) CPU           E5530  @ 2.40GHz --- Signature: Type 0, Family 6, Model 26, Stepping 5
16x DDR3 DIMM 4096MB 1333MHz

Как видите, на главном хосте установлены более новые процессоры E5630, но они работают медленнее, чем более старые E5530. Конфигурация памяти такая же (по сравнению с использованием lshw -C memory), есть только производитель и серийные номера разные.

Затем я взял Intel Memory Latency Checker, проверил память (оба хоста поддерживают NUMA) и получил следующие результаты: master

$ sudo ./mlc-linux/mlc_avx512 --latency_matrix
Intel(R) Memory Latency Checker - v3.5                                                                                                                                                                                          
Command line parameters: --latency_matrix                                                                                                                                                                                       
Using buffer size of 200.000MB                                                                                                                                                                                                  
Measuring idle latencies (in ns)...                                                                                                                                                                                             
                Numa node
Numa node            0       1
       0         366.1   228.9
       1         386.9   218.0
$ sudo ./mlc-linux/mlc_avx512 --bandwidth_matrix
Intel(R) Memory Latency Checker - v3.5
Command line parameters: --bandwidth_matrix 
Using buffer size of 100.000MB/thread for reads and an additional 100.000MB/thread for writes
Measuring Memory Bandwidths between nodes within system 
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
                Numa node
Numa node            0       1
       0         6021.5  5102.2
       1         4799.6  6473.1

ожидание

$ sudo ./mlc-linux/mlc_avx512 --latency_matrix
Intel(R) Memory Latency Checker - v3.5
Command line parameters: --latency_matrix 
Using buffer size of 200.000MB
Measuring idle latencies (in ns)...
                Numa node
Numa node            0       1
       0          82.3   130.1
       1         129.4    80.1

$ sudo ./mlc-linux/mlc_avx512 --bandwidth_matrix
Intel(R) Memory Latency Checker - v3.5
Command line parameters: --bandwidth_matrix 
Using buffer size of 100.000MB/thread for reads and an additional 100.000MB/thread for writes
Measuring Memory Bandwidths between nodes within system 
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
                Numa node
Numa node            0       1
       0        13439.5  7736.3
       1         7749.9 13846.2

В идеале картина на обоих хостах должна выглядеть одинаково - доступ к удаленной зоне должен быть медленнее, чем к локальной. Но это не так, если на резервном хосте все в порядке, то на главных хостах все не так. 1) локальный доступ на 0-> 0 медленнее, чем на удаленном 0-> 1. Зачем? 2) время доступа на мастере значительно больше, чем в режиме ожидания, 218 нс против 80 нс (в лучшем случае), даже если у мастера более новые процессоры. Я пробовал тесты несколько раз и получил похожие результаты.

Также я подумал, что, возможно, результаты зависят от того, что главный сервер находится под производственной нагрузкой, а его резервный режим простаивает. Но эта нагрузка не такая уж и высокая, средняя загрузка порядка 3,87, 3,85, 3,70.

Sysctl на обоих серверах одинаковы, есть только одно семейство ключей sysctl, которое значительно отличается - kernel.sched_domain.cpu * .domain * .max_newidle_lb_cost. Я не нашел никакой информации об этом параметре, но я попытался его изменить, и через некоторое время он динамически меняется.

Конфигурация PostgreSQL (postgresql.conf) одинакова на обоих хостах.

Протестированные запросы не потребляют и дисковый ввод-вывод (проверяется с помощью модуля pg_stat_statements contrib, который предоставляет детали запроса), весь набор данных полностью находится в памяти (общие буферы). У протестированных запросов одинаковый план выполнения на обоих серверах, но время их выполнения разное.

Я также подумал о недавних уязвимостях, связанных с обвалом / призраками, проверил системы и обнаружил следующее отличие. Главный хост с более новыми процессорами имеет полную защиту от spectre_v2.

$ for i in $(sudo ls -1 /sys/devices/system/cpu/vulnerabilities/); do echo $i $(sudo cat /sys/devices/system/cpu/vulnerabilities/$i); done
meltdown Mitigation: PTI
spec_store_bypass Vulnerable
spectre_v1 Mitigation: Load fences
spectre_v2 Mitigation: Full retpoline

по сравнению с резервным хостом

$ for i in $(sudo ls -1 /sys/devices/system/cpu/vulnerabilities/); do echo $i $(sudo cat /sys/devices/system/cpu/vulnerabilities/$i); done
meltdown Mitigation: PTI
spec_store_bypass Vulnerable
spectre_v1 Mitigation: Load fences
spectre_v2 Vulnerable: Retpoline without IBPB

Хорошо. хорошо, я отключил все защиты через "/ sys / kernel / debug / x86 / * _ enabled", но это совсем не помогло (включил их обратно)

Итак, может ли кто-нибудь объяснить, что не так с главным сервером и почему его доступ к памяти и современные процессоры работают намного медленнее? И как исправить эту проблему?