https://www.litres.ru/book/andrey-chesnov/ekspluataciya-cod-prakticheskoe-rukovodstvo-71370031/

https://stroki.mts.ru/book/ekspluatatsiya-tsod-prakticheskoye-rukovodstvo-284463

https://www.amazon.com/dp/B0DM6JP18K/

https://books.apple.com/book/id6738705417

https://play.google.com/store/books/details?id=roAvEQAAQBAJ

https://www.kobo.com/ww/en/ebook/c24i3_5w4T-TZez95wJh4A

1. Признаки проблемы

Свопинг (swap): Если система активно использует swap, это указывает на нехватку оперативной памяти, что может резко снизить производительность.

Замедление запросов: Запросы выполняются медленно, даже если CPU не загружен. Это может быть связано с чрезмерным выделением памяти под work_mem или большим количеством соединений.

Чрезмерное количество соединений:Если количество соединений близко к значению max_connections, сервер начинает расходовать больше ресурсов на их обслуживание.

2. Как диагностировать

На уровне ОС:

free -m: проверьте, сколько памяти доступно (available) и не растёт ли использование swap.

top/htop: найдите процессы PostgreSQL с высоким потреблением памяти.

Использование памяти:

Оцените настройки work_mem и нагрузку от соединений, особенно при большом числе активных запросов.

3. Что делать

   Оптимизируйте запросы:

• Добавьте индексы для ускорения фильтров.

• Избегайте SELECT *, выбирайте только нужные колонки.

• Разбейте сложные запросы на более простые.

Ограничьте соединения:

• Проверьте необходимость всех активных соединений.

• Используйте пул соединений (PgBouncer, Pgpool-II) для управления нагрузкой.

• Установите разумное значение для max_connections (например, 100-200 вместо нескольких сотен).

Настройте параметры памяти:

• Уменьшите work_mem для интенсивных запросов: SET work_mem = '16MB';

• Убедитесь, что shared_buffers не превышает 25-40% доступной памяти.

Мониторинг:

• Настройте системы мониторинга для отслеживания активности соединений и использования памяти (pg_stat_activity, node_memory_MemAvailable).

• Настройте автоматические уведомления при достижении определённых порогов использования памяти или swap.

Да, при настройке параметров необходимо учитывать:

1. ОС: она использует часть оперативной памяти для своих нужд, включая файловый кэш.

2. Другие приложения: если сервер используется не только для PostgreSQL, но и для других сервисов.

3. Резерв: всегда стоит оставлять запас оперативной памяти для непредвиденных нагрузок или системных процессов.

Таким образом, расчёт значений shared_buffers и effective_cache_size лучше производить от доступной памяти, остающейся после учёта всех прочих сервисов и ОС.

https://ozon.ru/t/baajQbW

Книга пока выпущена только в бумажном формате. Вопрос с электронной версией рассмотрим.

Мы предлагаем несколько опций: частное облако как сервис в уже аттестованном контуре, частное облако с нужными заказчику характеристиками, развернутое "с нуля", или частное облако на базе инфраструктуры заказчика, с услугой аттестации для ГИС, если в этом есть необходимость.

Как дела с бекапами ВМ?

У SharxBase нет интеграции с каким-либо продуктом резервного копирования. Решение для резервного копирования можно подружить с SharxBase VM только через агента.

Другие варианты рассматриваются, но требуют времени и ресурсов для развертывания. Всё-таки одно дело - виртуализация инфраструктуры предприятия, и совсем другое - построение публичного облака.

В статье сказано, что на данный момент фактический учет ведется в 1С.