"съедает" не больше 100GB?
Когда не хватает памяти то приходит OOM Killer (у вас же linux?) и просто убивает самый жадный процесс и память возвращается в систему и (с некоторыми оговорками) все начинает работать нормально.
В вашем же случае когда СУБД виснет, важно определить что происходит в это время в БД, какие запросы выполняются, как много и как долго, для этого есть pg_stat_activity. Например во время очередного зависания выполните вот этот запрос [1] и приходите с результатами сюда в чат. Это будет более предметное обсуждение.
1 - https://github.com/dataegret/pg-utils/blob/master/sql/db_activity.sql
> Когда не хватает памяти то приходит OOM Killer (у вас же linux?) и просто убивает самый жадный процесс и память Если он приходит, то кто-то неправильно настроил OS. Just my 0.02$. ;)
1. у нас есть сервер мониторинга - Prometheus + Grafana. все по графикам видим CPU/Memory/Network/FS 2. "Когда не хватает памяти то приходит OOM Killer (у вас же linux?) " - возможно и приходит, но уже бывает поздно 3. по дискам просадки не замечали, это было мое первое предположение, которое не подтвердилось 4. долгие запросы это есть - но почему запросы СУБД в аут отправляют, вот это вопрос..
ну вот! покажите график cpu/memory usage в момент проблемы (с легендой)
к сожалению, не получиться. у нас время хранения исторических данных неделя - и за прошлую неделю все было хорошо)
Обсуждают сегодня