Станислав Бодро́в,
Вот с апликухами было сложно в плане того что я не мог (видимо не докурил) как можно отфильтровать (обычно лезу в htop,free,vmstat ) конкретно анонимные страницы.
я видел в htop что они (процессы) делят с postgres кучу шаренной памяти и вроде как что-то используют, но убедится в том что это реально используется анонимная память я не мог (не знал как)
---
Вот про это тоже читал, но на диск ничего не было вытеснено.
Заклинание из мониторинга (я где-то нашёл расчёт метрики для честного мониторинга памяти) вовремя сработало - на диск ничего не успело упасть (своп пустой).
Хороший кстати вопрос разобраться, будет ли запрос в /proc возвращать страницы что в свопе, а если и будет, то как понять сколько он вытеснил а сколько нет (если конечно я правильно представляю себе механизм)
Рональд Макдональд, Алексей Черемисин,
Я мониторю память с помощью прометея и нод экспортера, полезная штука, там есть специальная метрика что показывает количество выделенных анонимных страниц и они росли, медленно но очень уверено.
Вроде нашёл способ найти проблему с помощью сайта markelov.blogspot.com/2009/01/linux-procmeminfo.html
пробежался по самым большим процессам, ( в статье описано как anonpage из /proc на процесс посчитать ) и нашёл несколько долгих подключений к postgresql которые выжирали по 1.5Гб в состоянии idle.
Просто ничего не знаю о нём.
xcp-ng выглядит как тот же xenserver но при этом со свободным распространением.
какой вообще опыт использования Proxmox? и были ли кейсы переноса на него тачек с другой платформы виртуализации?
спасибо.
почему-то раз за разом ходил через этот кусок и не мог понять что если они советуют следить, то сами не собираются поддерживать эту фишку. что явно минус для repmgr.
имел ввиду что не могу дать права на systemctl restart postgresql. ваш подход показался мне правильным, почему-то даже не подумал что так можно)
правда теперь не могу упасть в этот инстанс
psql: FATAL: role "postgres" does not exist и не могу понять почему)
наверно это связанно с checkpoint_completion_target = 0.9 ?
Другие чекпоинты в начале нагрузки выглядят так же. а потом просто пропадают.
При этом загруженность растёт.
В виде графиков чекпоинты у меня видны вот так
я вообще имел ввиду что что файлы wal пропадают только после checkpoint, а он однозначно не может идти резать дальше последнего "проигранного" wal.
следовательно он не вычищает wal потому что startup процесс не успевает проиграть wal. но правда не понятно почему он прекращает выполняться каждые 5 минут.
+ ещё в отношении pg_stat_bgwriter
я вижу что
checkpoints_timed не инкрементируется
когда
checkpoints_req щёлкает вперёд, но записей в логе не появляется и wal меньше не становится.
ky0 Запрос реально долгий.
правда, мастер его прожёвывает без проблем, а при раскатке этих wal на slave видимо затыкается в скорости (при этом система не сходит с ума и не говорит что она загружена).
мониторю расхождение wal на slave и master, и там видно, что файлы доезжают до копии, но они оч медленно проигрываются и начинают копится.
тут понял что сам процесс восстановления
postgres: startup process recovering. работает относительно медленно. я так понимаю checkpoint должен вырезать все wal до pg_last_wal_replay_lsn
но что делать если сам процесс восстановления не справляется?
Melkij, проблема в том что чекпоинтер настроен как на мастере. я как раз исходил из идеи что он будет отрабатывать самостоятельно по получению объёма данных или по истечению времени.
но (у меня нет лога вызова чекпоинта, но есть лог времени его отработки) так вот он вдруг перестаёт отрабатывать. и WAL бегут вверх.
wal там 200GB свободных, их точно не впритык.
не совсем понял что значит controlfile...
Упирался в сжатие при передаче. отключил сжатие и чудо! данные полились со скоростью света) теперь скорее всего будем заставлять тачку уже после перекладывания не спеша жать и не тревожить основной сервак. благодарю
и фишка в odyssey с возвращением честных ошибок балансером от базы.