LINUX.ORG.RU

Ubuntu: Buff / cache съедает всю память. каковы возможные значения vm.vfs_cache_pressure

 


0

1

На моем сервере установлено проприетарное программное обеспечение, которое включает в себя множество баз данных - postgress, tarantool, Memcached и несколько проприетарных приложений с высокой нагрузкой. Система ubuntu 16.04 4.15.0.76-generic

Также на той же машине у меня установлена ​​виртуальная машина (quemu / kvm), на которой установлено все то же программное обеспечение, но другая версия (это причина, по которой она установлена ​​на виртуальной машине). гостевая система ubuntu 18.04 5.4.0-84-generic

Главное в этом программном обеспечении то, что у меня очень ограниченное количество доступных опций, и, самое главное, у него довольно строгие значения тайм-аута , которые я не могу увеличить. (менее полсекунды).

Итак, проблема в том, что через какое-то время вся свободная память уходит в буфер / кеш, и после этого система начинает использовать swap.

Я пытался установить vm.swappiness = 3 по умолчанию было 60 , это как-то помогло, но система работает не очень стабильно, так что это больше похоже на то, что я продлил ее агонию ) Использование свопа приводит к увеличению таймаутов, что, в свою очередь, приводит к неработающему приложению. По какой-то причине система предпочитает начинать использовать своп, чем очищать cache/buff.

Прочитав еще немного, я обнаружил, что могу вручную очистить cache/buff. Поэтому я попытался использовать / bin / sync && / bin / echo 3> proc / sys / vm / drop_caches Я сделал это в задании crontab, которое выполняется каждые два часа для хост-системы и каждые шесть часов для гостевой системы. Я пробовал это в течение недели, система работает стабильно, я еще не нашел никаких поврежденных файлов. Я пробовал использовать его на хосте и гостевых машинах.

Безопасно ли использовать / bin / sync && / bin / echo 3> proc / sys / vm / drop_caches ? Таким образом, источники говорят, что это может привести к потере данных (в основном из-за некоторого времени между sync && echo 3> proc / sys / vm / drop_caches ).

Как связаны vm.swappiness и vm.vfs_cache_pressure ? Как vm.swappiness работает одинаково для этих версий: Ubuntu 16.04 4.15.0.76-общий Ubuntu 18.04 5.4.0-84-общий

Если установлено vm.swappiness = 0 , означает ли это, что система вообще никогда не будет использовать своп и завершит все процессы, если памяти недостаточно? Я где-то читал, что разработчики ядра Linux изменили поведение vm.swappiness = 0 , начиная с некоторой версии ядра, поэтому, если установлено значение 0, это просто убивает процесс.

Каковы возможные значения для vm.vfs_cache_pressure В некоторых источниках говорится, что это от 0 до 200. В разных источниках говорится, что он определяет количество страниц памяти, которые могут быть выделены для баффа / кеша. Что на самом деле означает vm.vfs_cache_pressure? Какие возможные значения я могу установить для vm.vfs_cache_pressure? Поможет ли установка vm.vfs_cache_pressure = 200 решить мою проблему? есть ли способ полностью запретить использование cache/buff, если это приводит к использованию подкачки?

Какие еще варианты я могу попробовать? Как я могу увидеть, какие файлы и какие объекты кешируются?

Существуют ли какие-либо другие опции, кроме vm.vfs_cache_pressureи vm.swappiness, которые могут изменить использование, приоритет баффа / кеша?

Идея состоит в том, чтобы не использовать swap, если есть некоторая доступная память (aviable), и отдать приоритет очистке Buff/cache, и только если это невозможно, и только тогда использовать подкачку (чтобы предотвратить завершение процесса) и конечно, не завершайте процессы, если есть доступный своп.

Если своп дуплит из-за медленного стоража, можно сделать формальный своп в пожатой оперативе (типа zram/zswap), и отключить дисковый. Ну, это если оперативы в целом хватает, и своп дисковый нужен лишь формально. В убунте есть некоторое количество сервисов, которые включены по дефолту, и хавают оперативу. Лучше удалить с purge всё ненужное. Ну и посмотреть какие процессы жрут своп

vasily_pupkin ★★★★★
()

Ubuntu: Buff / cache съедает всю память

во-первых не всю во-вторых что в этом плохого

hakavlad ★★★
()

Если установлено vm.swappiness = 0 , означает ли это, что система вообще никогда не будет использовать своп

Нет, не означает. На способность свопить влияет также vm.watermark_scale_factor

hakavlad ★★★
()

Каковы возможные значения для vm.vfs_cache_pressure В некоторых источниках говорится, что это от 0 до 200

допустимы от 0 до 10000. Читайте оф док

hakavlad ★★★
()

есть ли способ полностью запретить использование cache/buff

во-первых нет во-вторых это б убило производительность

hakavlad ★★★
()

Существуют ли какие-либо другие опции, кроме vm.vfs_cache_pressureи vm.swappiness, которые могут изменить использование, приоритет баффа / кеша?

vm.watermark_scale_factor - увеличение его может усиливать своппинг

hakavlad ★★★
()

вместо выполнения sync можно просто уменьшить лимит для грязного кэша через ручку vm.dirty_bytes

hakavlad ★★★
()

Какие еще варианты я могу попробовать?

сделать своппинг быстрым путем использования swap on zram

hakavlad ★★★
()

Идея состоит в том, чтобы не использовать swap, если есть некоторая доступная память (aviable)

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

кэш увеличивает производительность, не надо весь удалять.

hakavlad ★★★
()
Ответ на: комментарий от glorsh66

сначала поставь zram-tools.
отредактируй /etc/default/zramswap
посмотри как будет работать.

Minona ★★☆
()

Причины могут быть не только в неких кешах и проблема может возникать 1) Если ядро говно 2) Если графический видео драйвер поставляемый провайдером твоих пакетов тоже может быть говном. Итог можешь переехать в деревню «Грязь» и основать там свое казино с названием «и говно» и того получаем грязь и говно что звучит как «большой куш» или ?кровь и бетон" , а это заявка на номинацию золотого подорожника или веточки ели.

anonymous
()
Ответ на: комментарий от hakavlad

vm.dirty_bytes, vm.dirty_bytes_ratio, vm.dirty_backgound_bytes, vm.dirty_backgound_ratio он я правильно понимаю регулирует только dirty_pages т.е. кэш для записи?

А как регулировать кэш для чтения? По тому что

cat /proc/vmstat | egrep «dirty|writeback» в среднем говорит что nr_dirty 5709 Но не понятно значение nr_dirty_threshold nr_dirty_background_threshlod

glorsh66
() автор топика
Ответ на: комментарий от hakavlad

А в одном сообщении нельзя было все это расписать? Или ты гуглил и сбрасывал сюда результаты по ходу гуглежа? Палишься. Сам весь такой «читай оф доки» типа. Лол.

Gonzo ★★★★★
()
Последнее исправление: Gonzo (всего исправлений: 1)
Ответ на: комментарий от Gonzo
  • можно было в одном, но написал как удобнее. Прочитал кусок оп-поста, прокомментировал. И так далее по всему посту.

Или ты гуглил

не в этот раз

Сам весь такой «читай оф доки» типа

И в чем проблема?

hakavlad ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.