У меня есть потоковая репликация 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", но это совсем не помогло (включил их обратно)
Итак, может ли кто-нибудь объяснить, что не так с главным сервером и почему его доступ к памяти и современные процессоры работают намного медленнее? И как исправить эту проблему?