ну и отмечу что в самом слоте не делается каких-либо удалений/вставок и т.п., - все это происходит в базе, а слот просто читает журнал транзакций, извлекает оттуда нужные данные и держит их для валсендера

250 коннектов, из которых в основном активных 10, остальные в idle.
По транзакциям в среднем в сутки 70-80 TPS

Ну да, я имел в виду, что в таблицах, которые привязаны к слотам, идет запись\изменение

еще такой вопрос, вы пробовали сбросить и потом снова включить своп - повторяется ли эта ситуация ?

Это довольно рискованно делать на прод-сервере, простой базы крайне нежелателен)

то ответ - нет, не делали. верно?

Нет, не делал

я вот к чем клоню... но это гипотеза, т.к. нет данных о повторяемости проблемы конкретно со слотами.

вероятно у вас приходит куча клиентов с трафиком и процессы постгреса через work_mem просят памяти, ядро обнаруживает нехватку и начинает свопить страницы (зависит от vm.swappiness) и по каким-то внутренним ядерным критериям в своп улетают страницы принадлежщие процессам репликации. Потом клиенты с трафиком убегают, память возвращается, но страницы процессов репликации продолжают лежать в свопе, потом если вдруг эти страницы иногда требуются, то они поднимаются из свопа в память (вероятно это и есть тот самый мизерный swap out).

как-то так... то есть заполненый своп это еще не показатель проблемы, а вот постоянный свопный трафик это уже свидетельство что памяти недостаточно под ворклоад.

а можете еще просто для справки показать head -n 20 /proc/meminfo

Спасибо, да, это имеет смысл, т.к. иногда бывают всплески по коннектам и трафику, то вероятнее всего такой сценарий и произошел, вытеснило менее активные процессы wal sender'а в своп из-за закончившейся памяти.
Попробую докинуть оперативы и поэксперементировать со слотами

Парни, подскажите как правильно освободить место на диске, я удалил данные из таблиц, но место не освободилось (

Vacuum должен очищать, если avtovacuum настроен хорошо. Если не очищает, то 'VACUUM FULL' на таблицу, но это полностью ее блокирует.
Есть еще pg_repack, он без блокировки умеет делать

truncate table

Как полностью команда выглядит?

я где-то читал что не рекомендую вакуум

Truncate, эт если полностью данные удалял, то да, такой вариант быстрее будет. А если данные не все удалял, то

VACUUM FULL db.table

Трункейт очистит таблицу )

проверь в pg_stat_activity есть ли процессы автовакуума на этих таблицах

судя по цифрам, на данный момент нехватки памяти нет в системе - Available ~12GB что больше 50% от total RAM. Это добавляет уверенности что проблема с уездом в своп была какая-то "разовая"