Почему большой iowait в cloud vm c postgres?

Question

[igortru]

Привет.

Linux, Centos 7 в облаке Yandex. Параметры vm следующие :

Платформа Intel Cascade Lake
Гарантированная доля vCPU 100%
​vCPU 2
RAM 8 ГБ
Объём дискового пространства 515 ГБ

Бд размещена на отдельном диске с параметрами:

Размер 465 ГБ
Размер блока  4 КБ
Тип Нереплицируемый SSD
Макс. IOPS (чтение / запись) 75000 / 28000
Макс. bandwidth (чтение / запись) 550 МБ/с / 410 МБ/с

БД - Postgres 11
Функционал - реплика БД, на которую даже не приходят с запросами. Больше vm ничем не занимается.
Конфиг postgres

max_connections = 300
shared_buffers = 4GB
effective_cache_size = 6GB
maintenance_work_mem = 1536MB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 2621kB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4
checkpoint_timeout = 30min
checkpoint_completion_target = 0.9
autovacuum_vacuum_scale_factor = 0.4
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 10.0
bgwriter_flush_after = 0
seq_page_cost = 1.0
shared_preload_libraries = 'pg_stat_statements'
ssl = 'on'
ssl_cert_file = '/mnt/keys/server.crt'
ssl_key_file = '/mnt/keys/server.key'
ssl_ciphers = 'HIGH:+3DES:!aNULL'
ssl_prefer_server_ciphers = 'on'
wal_level = 'logical'
wal_keep_segments = 128
log_connections=on

max_standby_streaming_delay = 1800s
max_standby_archive_delay = 1800s
archive_mode = always
archive_command = 'wal-g --config=/mnt/pg-data/.walg.json wal-push \"%p\" >> /var/log/wal-g/wal_g_archive_command.log 2>&1'

Проблема - высокий iowait time на vm. Наш zabbix

Меня смутило что Latenсy до диска достаточно большой, ответ провайдера

Задержки связаны с работой гостевой ОС и ПО внутри неё, так как графики троттлинга в нуле. По ним можно определить, влияет ли Yandex Cloud на задержки работы дисковой подсистемы. У нас нет возможности еще точнее сказать, в чем может быть причина, так как администрирование ОС и ПО находится в зоне ответственности пользователя и выполняется им самостоятельно.

По iops такой картины не наблюдается, использование диска минимально. Мониторинг диска в облаке -



iotop показывает 2-10Мб/c, чтение iostat не помогло, цифры для меня абстрактные и не указывают явно на проблему.

iostat -x 5 5

Linux 5.4.88-200.el7.x86_64 (db-postgres)     04/11/2024      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.27    0.00    3.74    6.76    1.17   84.07

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.06    0.29    1.46    10.59     7.79    21.02     0.02   10.38   32.67    5.90   1.80   0.31
vdb               0.18     0.79   11.19  264.35  4401.19  1221.74    40.81     0.09    0.71    4.34    0.56   1.15  31.80

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.66    0.00    5.26   14.58    1.59   73.91

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.60    0.00    2.20     0.00    18.60    16.91     0.01    5.09    0.00    5.09   0.55   0.12
vdb               0.00     0.00    1.00  379.60    30.40  1652.00     8.84     0.14    0.81    0.40    0.81   1.53  58.08

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.99    0.00    4.27    7.75    1.49   84.49

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     5.40    0.60  407.60   190.40  1827.20     9.89     0.04    0.48    1.67    0.48   1.14  46.38

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.99    0.00    4.79   12.46    1.30   79.46

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.20    0.60     0.80     5.30    15.25     0.01    9.25    1.00   12.00   9.75   0.78
vdb               0.20     0.00    1.40  340.00   444.80  1493.60    11.36     0.14    0.81    2.43    0.81   1.54  52.58

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.69    0.00    4.47   11.03    1.29   81.51

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     0.00    0.00  297.20     0.00  1331.20     8.96     0.10    0.78    0.00    0.78   1.59  47.26

Как бы понять природу большого iowait?

Comments

[SunTechnik]

И все же, покажите вывод днем команды:
iostat - x 5 5

[igortru]

SunTechnik, прикрепил, в новой версии вопроса

[SunTechnik]

igortru,
Получается, что у Вас система только и занимается тем, что пишет мелкими блоками (по 4k).
В текущей ситуации, особого криминала не вижу, но есть сомнения, что данные диски смогут отдать заявленные 28k iops по записи.

Добавление ядер CPU снизит iowait, но это не повлияет на производительность системы, просто больше времени они будут простаивать, а в процентном соотношении iowait снизится..

[igortru]

SunTechnik, получается система простаивает из-за большого latency ? и внутри vm я на это никак повлиять не могу?
Вопрос к тому что у нас есть другие БД, кластера, vm где этого не наблюдается.

[SunTechnik]

igortru,
Да не сказал бы что на системе большая задержка.

Покажите iostat с другой системы, что бы можно было сравнить.

У Вас эта система в любом случае будет простаивать, так как на неё вся нагрузка: применять журналы...

Answer 1

[Melkij]

У яндекса весьма медлительные сетевые диски, совершенно верно. Именно по latency, что куда более критично для СУБД чем обещанная полоса пропускания или IOPS (которые у большинства хранилок предполагают совершенно абсурдную для СУБД глубину очереди команд).

Comments

[igortru]

так что делать?)) вопрос больше риторический.
у нас есть СУБД в YC которые в разы больше по объёму и нагрузке, но такой latency и iowait я не наблюдаю.
мб есть какой-то тюнинг - "писать большими блоками", "количество потоков записи" и пр...

[Melkij]

это нормальное состояние на высоколатентных дисках. Смириться или переезжать на нормальные диски.

"писать большими блоками"

у вас обновилась одна строка таблицы и соответственно к определению этой таблицы допустим пять индексов. Разумеется, это 6 разных блоков в разных местах. Ну и как вы их запишете одним большим блоком, ммм?

Answer 2

[Wexter]

Так на графиках чётко виден рост iowait вместе с задержкой чтения с диска, да и сама задержка ощутимо большая. В идеале задержка чтения/записи не должна превышать 2-3мс

Comments

[igortru]

ну т.е. это облачный провайдер? Они свой комментарий как-бы дали

Answer 3

[Vitaly Karasik]

Я бы начал с вопроса - насколько хорошо система выполняет свою функцию?
Если ее назначение это немного запросов на чтение, то
1) есть ли проблематичная задержка репликации?
2) нормально ли выполняются запросы на чтение?

Если ответы нет\да, и вы не ожидаете увеличение нагрузки на основную базу вдвое (условно), то я бы спал спокойно.

Answer 4

[Дмитрий]

а у меня риторический вопрос - а может яндекс так "намекает", что стоит мигрировать на их Managed Postgress ?