Если у вас часто обрывается SSH-соединение с сервером, то рекомендую добавить пару параметров для SSH-клиента в файл /etc/ssh/ssh_config: ServerAliveInterval и ServerAliveCountMax
ServerAliveCountMax The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds.
Неплохой инструмент для локального использования в Linux чтобы почистить систему от старых контейнером и volumes. При удалении контейнера предлагает также удалить связанный с ним volume. Можно быстро смотреть логи и даже графики использования памяти и CPU. Стоит ли использовать подобные инструменты?
Стефан Фиданов из Болгарии в своей как мне кажется шуточной статье Pushing SQLite to its limits with Go while having fun поднимает тему сокращения стека и предлагает радикальное решение - использовать SQLite для бэк-энда под приличной нагрузкой около 6000 RPS.
В статье создается "пустой" Hello World web-сервер. Он показывает 100к+ RPS на МакБуке (Core i7 и 8Гб RAM). Если добавить чтение из SQLite (простая выборка без JOIN'ов по PK), то RPS падает 65К+. Добавляем еще к этому запись в ResponseWriter размером 100Кб и RPS падает уже до 11К+. Если же вместо большого шаблона делать UPDATE, то RPS будет держаться на уровне 24K+. Все это работает с включенным WAL-модификатором (_journal_mode=WAL параметр).
Кроме как шутку эту статью не могу воспринимать, т.к. автор рекомендует рассмотреть SQLite в качестве СУБД для следующего проекта. SQLite - отличный продукт с хорошей репутацией, но функционал быстро вычерпывается ложкой и ты уже скребешь дно. Вобщем, и сами авторы предлагают рассматривать SQLite как альтернативу fopen:
Think of SQLite not as a replacement for Oracle but as a replacement for fopen()
У нас случился инциндент: на сервере с базой данных закончилось место. Надо понимать, что на сервере 228Гб, а базы не занимают и 10ой доли этого места. Куда же делось свободное место?
Первое на что нужно обращать внимание в случае проблем с БД - это операции чтения/записи и их интенсивность. Для проверки какой процесс и как интенсивно работает с диском можно использовать утилиту iotop.
Удаление данных провоцирует распухание pg_wal директории. Что такое WAL? Это журнал предзаписи. Он очень важен и позволяет сильно повысить производительность СУБД по следующим причинам:
Как правильно удалять данные? Приводит ли к распуханию журналов удаление колонки?
Лоуренс Альбе (известен своим титаническим вкладом по ответам на вопросы про PostgreSQL на StackOverflow) в своей недавней статье поднял не новый вопрос полиморфизма в SQL: как сослаться с одной таблицы на несколько других одного класса?
Сама проблема часто возникает в объекто-ориентированных языках, где вполне естественно создать несколько наследников и при необходимости работать со ссылкой родительского класса. В СУБД реляционная модель не очень-то хорошо представляет данные, представленные в объектом виде.
Итак, вы используете ORM (и названия таблиц у вас скорее всего в единственном числе :) ). Вы пишете бэкэнд для лизингового сервиса, который сдает в аренду машины, велосипеды, тракторы и т.д. В ООП вы создаете родительских класс "Vehicle" и наследуетесь от него для создания "Car", "Bicycle" и т.д. В контракте (Contract), который заключает клиент агентсва нужно сослаться на один (для простоты) арендуемый объект.
Как представить это в реляционной СУБД?