gigaRAM: память без переплат

После расширения сервера администратор PostgreSQL увеличивает shared_buffers: чем больше данных база держит рядом, тем реже обращается к накопителю. Но Linux тоже использует RAM для недавно прочитанных файлов. Один блок может оказаться сразу в двух кешах. На первый взгляд это двойная трата. Однако слои выполняют разные обязанности. PostgreSQL управляет блоками таблиц и индексов как база данных, а Linux ускоряет путь к файлам для всей системы. Дублирование бывает, но оно не означает, что вся база постоянно хранится в двух полных копиях...

На одном сервере работают виртуальные машины с базами и приложениями. Каждая получила достаточно RAM. Днём отчёты, резервное копирование и обработка заказов одновременно требуют больше памяти. Все ВМ видят обещанный объём, но ответы сервисов замедляются. Так проявляется memory overcommit — виртуальным машинам суммарно назначено больше памяти, чем физически установлено на хосте. Пока пики распределены по времени, свободный ресурс не простаивает и сервер используется плотнее. Когда потребности совпадают, несколько гостей претендуют на одну и ту же DRAM...

Команда уменьшила RAM на брокерах Kafka и получила хороший финансовый отчёт. JVM heap заполнен не полностью, сборщик мусора работает спокойно. Но стоило отставшему потребителю запросить старые события во время восстановления реплики, как ответы брокера стали приходить позже. Это кажется странным, только если считать heap всей памятью Kafka. На самом деле журнал хранится в файлах, а Linux использует свободную RAM как быстрый слой перед накопителем. После сокращения памяти Java может чувствовать себя прекрасно, пока чтение незаметно переезжает из RAM на диск...

Противоречия нет. У контейнера и сервера разные границы. СУБД могла израсходовать весь разрешённый ей объём, хотя за этой границей оставался ресурс для соседних приложений и самой операционной системы. Это похоже на дополнительную банковскую карту с лимитом: деньги на общем счёте есть, но конкретной картой потратить больше нельзя. Такой инцидент начинают с вопроса «чья граница была достигнута». От ответа зависит решение: пересчитать лимит базы, разгрузить сервер или изменить размещение контейнеров...

На одном сервере ClickHouse идёт большой пакетный отчёт и работают короткие запросы панелей. Памяти хватает, пока не появляется ещё одна интерактивная выборка. Именно она просит дополнительный ресурс — но система завершает отчёт, начавшийся раньше. Со стороны это выглядит случайностью. На деле ClickHouse применяет memory overcommit: сравнивает запросы и выбирает работу, которая сильнее других вышла за назначенную ей основу. Технический механизм отвечает на вполне деловой вопрос: какая задача должна уступить, когда все полезные работы одновременно не помещаются...