—————- total       used       free     shared    buffers     cached
Mem:          108G       107G       1.2G        25G        59M        26G
-/+ buffers/cache:        80G        27G
Swap:         3.9G       3.9G       1.2M

Теперь не могу подключиться к базе, в логах сыпятся ошибки
2021-06-19 12:05:11 +06 [29866]: [5052-1] LOG:  could not fork autovacuum worker process: Cannot allocate memory
2021-06-19 12:05:12 +06 [29866]: [5053-1] LOG:  could not fork new process for connection: Cannot allocate memory

+

Привет! Прохожу курс от EPAM по Data Engineering. Не получается развернуть готовую базу из курса в DBeaver + PostgreSQL. Сняла видео, выложила по ссылке, сама база там тоже лежит, а также скриншоты первой ошибки и результаты run (ALT + X). Кто-то может с этим помочь? Вся учёба встала 🙂 https://drive.google.com/drive/folders/1jOcOXqjsNFdWrz40nKe7am7Cz-vLZl3p?usp=sharing

Может спроосиь у ментора ?

Обучение без ментора. Self-paced course

Ааа

Прикольно, а где на такой курс можно записаться?

в указанной последовательности восстанавливаешь данные ?

Всё чётко по инструкции из курса. База начала сообщать об ошибке, начиная с schema, файл 1

а где инструкция ?

Положила в папку

error handle так же настроила ?

Сейчас ещё раз проверю. Шла по инструкции. Сравню с их скриншотом

Да, полностью совпадают настройки в окнах.

Зайдите на сервер под root и гляньте prlimit --pid <pid стартового процесса СУБД> . ulimit -a от postgres может и наврать, если СУБД была запущена очень давно. Хотя есть вариант, что это не СУБД память поглотила. По фрагменту конфига получается 60-70ГБ утилизация, это если у вас нет распараллеливания запросов, тогда work_mem для таких запросов множится на все сортировки таблиц из запроса.

prlimit не установлен,
ulimit -a показывает:
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 443422
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 20480
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 20480
cpu time               (seconds, -t) unlimited
max user processes              (-u) 8192
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

распараллеливания нет

У меня есть мысль, и я её думаю: с huge_pages как дела обстоят? Просто ПГ пытается выделить память одним куском, а таких, каких надо просто нет, вот и падает. И да, обновляться надо, без вариантов.

Ну так обновитесь до 9.3.какой-там-последний-minor, хотя бы.
Иначе Вы просто впустую тратите [не только своё] время.
Но, по-хорошему, стоит обновиться на поддерживаемую версию.

> как обновиться с минимальным временем простоя и без выделения дополнительных ресурсов для обновления.

С помощью pg_upgrade же. Кстати:

> С 9.3 там обновляться в 2 этапа вроде надо, если не ошибаюсь

Нет, в один.

> База весит 4.5ТБ, а для pg_upgrade сверху нужно еще 4.5ТБ

И тоже нет, не нужно. См. https://www.postgresql.org/docs/current/pgupgrade.html , ключ --link.
Но это к слову — не факт, что приложение заработает на новой major версии (они не просто так major).

коллеги,всем привет!
У меня вопрос: кто нибудь здесь базу данных на бесплатном сервисе гугла открывал?