я пытался её пофиксить в общем виде, но нашел пору кейсов, которые непонятно как решать, и пока отложил до следующего патч релиза

условный "Mr. Mac'Nuggets" как имя пользователя взрывает парсинг нафиг

Столкнулся с такой проблемой.
"Тащу" wal-ы c мастера двумя процессами:
1) Реплика (без нагрузки, на случай поломки мастера)
2) pg_receivewal
Оба процесса через stream + replication slot, оба с бэкапного хоста, только каждый в свои каталоги пишет
И вот на мастере кто-то что-то в 1С поставил то ли перепроводить, то ли базу закачивали (не посмотрел), короче дали хорошую нагрузку по записи.
И появилось отставание реплики.
Но, при этом реплика отставала не так уж и сильно (на 200-300 Мб)
А вот pg_receivewal умудрялся дико тупить и набрал отставание в пике до 2,5Гб
Когда нагрузка ушла, то pg_receivewal довольно быстро "нагнал" отставание.
При этом я не заметил, чтобы i/o особо сильно напрягался, ну и сеть в том числе.

Вопрос - что могло ему мешать?
Может мастер тупить на отдачу?

Нюанс - подключение к мастеру через SSH port forwarding

1. Pg_receivewal с сжатием?
2. Что за подключение через ssh? Кто им пользуется?

1) да -Z 6, но нагрузки на процессор я не наблюдал
2) ssh - специально port forwarding для подключения к мастеру:   ssh -T -N -L 5431:localhost:5432 srv

Через ssh и реплика подключается, и pg_receivewal

А зачем через ssh?

хосты через интернет общаются, настраивать ssl было лень )

но они в одном ДЦ, между ними до 1Гб скорость

еще вспомнил, когда pg_receivewal отставал, то при выводе pg_stat_replication у него статус был "catchup"

И еще выдавал ошибки terminating walsender process due to replication timeout
Увеличил wal_sender_timeout до 2 минут

Значит ресивер 60 секунд не отвечал

Или не было связи, или он чем-то занимался

Для дальнейшего анализа уже нужен какой-нибудь условный atopd

А вообще в целом для мастера большая разница в один слот отдавать, или в два?

Т.е. вроде и выглядит все так, что это ресивер тупил

Но тупить он начал ровно тогда, когда на мастере начали много писать

разница есть, ведь разные реплики по разному могут отставать и соотвественно для каждой будут отдаваться разные wal-ы

ну это понятно
если уточнить мой вопрос - то насколько это ему тяжело? )
просто выглядит это не так уж и обременительно - "не  удаляй сегменты, пока их не заберут во всех слотах" и "тупо шли через протокол сегменты", ведь особо что-то там вычислять не требуется

Похоже я упустил в наблюдениях нагрузку на диски на приемнике, надо попробовать повторить это все с более подробными логами
но iotop, iostat не показывали особо ничего, по крайней мере запуск бэкапа намного больше нагрузку на диски дает