172 похожих чатов

Добрый день. Имеются несколько глобальных проблем, которые хотелось бы решить.

Но не знаю даже, с чего необходимо начать анализ.
БД: PostgreSQL 13
Конфигурация машины: 12 vCPUs, RAM 64GB, Storage 2TB (об этом чуть ниже)
Конфигурация базы: стандартные настройки при инициализации базы через Google Cloud SQL (но можно позже отобразить все настройки), за исключением параметра max_connections, который равен 3,000.

Проблема 1.
Непонятно что занимает Storage машины базы. Под непонятно что я на самом деле подразумеваю непонятно что. Ибо на данный момент с помощью команды SELECT pg_size_pretty( pg_database_size('DB NAME') ); выводит размер базы 51 GB, и это на самом деле так и есть (пробежался ещё по размеру каждой из таблиц), но через панель управления базой в Google Cloud отображает занятую память 1.5 TB из 2 TB, и это значение увеличивается на несколько гигов чуть ли не каждую минуту. Как понять, что это вообще такое? Из-за чего это может быть? Кэш, ошибки, логи, без понятия.

Проблема 2.
Работа с PostgreSQL впервые, но таких проблем при работе с другими базами не встречал. Обычная стандартная установка базы и дальше самые обычные запросы для только вставки и проверки данных на существование в таблице (никаких удалений и обновлений на данный момент нет). И тем не менее, только с PostgreSQL наблюдаются проблемы: странное (для меня) использование RAM, что приводит к волнам на графиках (см. скриншот ниже). Когда память находится в пике, работа с базой невозможна. В Datagrip пишет: FATAL: the database system is in recovery mode, воркеры в это время в ожидании возобновления работы базы, поэтому обработка чего-либо становится невозможной.
Почему так происходит?

1 ответов

10 просмотров
Mooner- Автор вопроса

Доброго дня ещё раз. К сожалению, разбор полётов с базой пришлось отложить ввиду новых более приоритетных задач. Поскольку сейчас они в нужной степени решены, разбор полётов возвращается. С моего последнего апдейта изменилось следующее: 1. Проблема с ООМ осталась (ниже более подробно) 2. Проблема с быстрым заполнением Storage пропала. Просто поднял новую базу с той же конфигурацией, теми же воркерами и проблема исчезла. Почему, из-за чего — без понятия. Но раз пока пропала, то меньше головная боль. Проблема с RAM. Как вы можете видеть, в прикреплённом мной предыдущем сообщении имеется график использования RAM за 6 часов. Непонятно из-за чего он поменял вид, но проблема осталась. Прислушавшись к вашим советам по поводу смены облачного решения на собственный сервер с PostgreSQL, было решено поднять его с помощью пакета Bitnami. Основной момент, почему был вообще выбран клауд — это быстрое развертывание, сразу установленные мониторинги, возможность менять какие-то конфигурации прямо на лету.

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта