чесно говоря просто - у нас СУБД в штатном режиме работает и съедает не больше 100GB точно. но бывают моменты когда пользюки чтото начинают делать - и все, СУБД виснет, приклад виснет, и по итогу потом виртуалка с СУБД ложится и помогает только рестарт виртуалки на которой СУБД и ессно всей системы

По каким параметрам (или какими инструментами) вы определяете что СУБД "съедает" не больше 100GB?

Когда не хватает памяти то приходит OOM Killer (у вас же linux?) и просто убивает самый жадный процесс и память возвращается в систему и (с некоторыми оговорками) все начинает работать нормально.
В вашем же случае когда СУБД виснет, важно определить что происходит в это время в БД, какие запросы выполняются, как много и как долго, для этого есть pg_stat_activity. Например во время очередного зависания выполните вот этот запрос [1] и приходите с результатами сюда в чат. Это будет более предметное обсуждение.

1 - https://github.com/dataegret/pg-utils/blob/master/sql/db_activity.sql

Опять же если вы говорите про "зависания", то проблема может заключаться в долгом выполнении запросов из-за медленного дискового IO (что имеет мало отношения к памяти).

вобщем для более лучшей диагностики нужны данные об утилизации сервера (cpu, memory, disk utilization) и представление того что происходит в БД в момент проблемы. Если нет полноценного мониторинга, то можно воспользоваться хотя бы инструментами top/iostat чтобы составить примерную картину происходящего.

> Когда не хватает памяти то приходит OOM Killer (у вас же linux?) и просто убивает самый жадный процесс и память

Если он приходит, то кто-то неправильно настроил OS. Just my 0.02$. ;)

Да он даже на "основные" вопросы ещё не ответил, а Вы уже хотите данные мониторинга. :)

1. у нас есть сервер мониторинга - Prometheus + Grafana. все по графикам видим CPU/Memory/Network/FS
2. "Когда не хватает памяти то приходит OOM Killer (у вас же linux?) " - возможно и приходит, но уже бывает поздно
3. по дискам просадки не замечали, это было мое первое предположение, которое не подтвердилось
4. долгие запросы это есть - но почему запросы СУБД в аут отправляют, вот это вопрос..

ну вот! покажите график cpu/memory usage в момент проблемы (с легендой)

я же на все ответил, ребята. щас еще раз перечитаю переписку

Да, перечитайте и ответьте.
И вообще, лучше уже все данные по обсуждаемому вопросу собрать в одном месте (на paste site, или git, например), как мне кажется (а то как-то всё сильно разбросано по сообщениям).

согласен, все данные лучше в одном месте, pastebin или gist.github

к сожалению, не получиться. у нас время хранения исторических данных неделя - и за прошлую неделю все было хорошо)

Привет, подскажите,
делаю запрос
INSERT INTO data.source(id, created, created_utc) VALUES($1, to_timestamp('$2'), to_timestamp('$3'))

получаю ошибку
error: invalid input syntax for type double precision: "$2"

Что за ошибка? У меня в базе тип этого поля timestamp, а он мне про double втирает.
Вставляемое значение 1581569438

В документации to_timestamp принимает double precision - to_timestamp(double precision),
разве отдаваемое мною число не является double? (делаю на js, принудительно привел это значение к числу)

Кавычки надо убрать у аргументов

Иначе не используется аргумент, а вставляется строка '$2'

Точнее, пытается вставиться :)

Попробовал, без них другая оишбка лезет
error: duplicate key value violates unique constraint "source_pkey"
Буду разбираться, спасибо

Эта ошибка, очевидно, вменяемее. source уникальный, видимо, у таблицы.

Ой, что это я. Id уникальный, вставляется, видимо, один и тот же.

Точно, спасибо!