Size: a a a

pgsql – PostgreSQL

2021 June 11

AL

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

ММ

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

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

AL

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

ММ

Михаил Мехоношин... in pgsql – PostgreSQL
Это довольно рискованно делать на прод-сервере, простой базы крайне нежелателен)
источник

AL

Alexey Lesovsky in pgsql – PostgreSQL
то ответ - нет, не делали. верно?
источник

ММ

Михаил Мехоношин... in pgsql – PostgreSQL
Нет, не делал
источник

AL

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

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

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

AL

Alexey Lesovsky in pgsql – PostgreSQL
а можете еще просто для справки показать head -n 20 /proc/meminfo
источник

ММ

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

ММ

Михаил Мехоношин... in pgsql – PostgreSQL
MemTotal:       20641448 kB
MemFree:          136668 kB
MemAvailable:   12390380 kB
Buffers:           28252 kB
Cached:         16501604 kB
SwapCached:        64428 kB
Active:         10940636 kB
Inactive:        7213812 kB
Active(anon):    4898068 kB
Inactive(anon):  1193396 kB
Active(file):    6042568 kB
Inactive(file):  6020416 kB
Unevictable:        3652 kB
Mlocked:            3652 kB
SwapTotal:       1949692 kB
SwapFree:              0 kB
Dirty:               132 kB
Writeback:             0 kB
AnonPages:       1566040 kB
Mapped:          4374284 kB
источник

G.

GEXmur . in pgsql – PostgreSQL
Парни, подскажите как правильно освободить место на диске, я удалил данные из таблиц, но место не освободилось (
источник

ММ

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

KK

Konstantin Knizhnik in pgsql – PostgreSQL
truncate table
источник

G.

GEXmur . in pgsql – PostgreSQL
Как полностью команда выглядит?
источник

G.

GEXmur . in pgsql – PostgreSQL
я где-то читал что не рекомендую вакуум
источник

ММ

Михаил Мехоношин... in pgsql – PostgreSQL
Truncate, эт если полностью данные удалял, то да, такой вариант быстрее будет. А если данные не все удалял, то
VACUUM FULL db.table
источник

KK

Konstantin Knizhnik in pgsql – PostgreSQL
источник

G.

GEXmur . in pgsql – PostgreSQL
Трункейт очистит таблицу )
источник

ММ

Михаил Мехоношин... in pgsql – PostgreSQL
проверь в pg_stat_activity есть ли процессы автовакуума на этих таблицах
источник

AL

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