Sometimes I work on legacy notebook (Samsung R522) with only 2G RAM onboard. I used to work with frugal software (vim, tmux, mpd, mutt, mbsync etc with minimalistic hand-tuned openbox as WM), but quantum firefox eats them all. And this hangs system, because I completely switch off swap (attempt to increase service life of harddisk). So I rtfm, then discovered kernel politics wich overcommit memory and changed default:
vm.overcommit_ratio = 50
vm.overcommit_memory = 0
to
vm.overcommit_ratio = 98
vm.overcommit_memory = 2
----
Укрощение лисы
или как снизить потребление памяти прожорливого firefox и заставить linux жить по средствам.
2018-04-12 09:40
(there is english tldr in the end of text)
Сейчас иногда использую в качестве мобильного рабочего места ноут Samsung R522 - впечатляющая даже по сегодняшним меркам машинка, но всего с 2G RAM на борту. В основном я работаю либо с совсем низкоуровневыми программами (vim, tmux, mutt, mbsync, mercurial, pandoc, ... что еще нужно человеку для полного счастья?) и прельстиво и любовно допиленным openbox. Однако, quantum firefox способен сожрать всю память и завесить систему. Ко всему прочему, чтобы пощадить винт, я принципиально отключил своп. Посему начали случаться моменты когда система зависала. Это не совсем зависание - как написали на одно
м из форумов "just highly unresponsible" - но обычно у меня не хватало терпения ждать и я перезагружал машину.
Некоторое время я пытался настроить firefox на меньшую прожорливость, проверял плагинки, обновлял базы - в общем все необходимые ритуальные танцы. В конце-концов стало понятно, что проблема не в браузере.
Я забрался в докуметацию и выяснил интересную штуку. Оказывается, в ядре есть такая настройка, как memory overcommit - выделение приложению памяти больше, чем есть в наличии. Я не копал глубоко вопрос почему и зачем это сделано - по моим предположениям такой режим выгоден (а) когда запущено много разных приложений и есть шанс, что недостающая память случайным образом высвободится за счет закрытия другой программы, к моменту когда она понадобится программе текущей (привет теории массового обслуживания), (б) расчет идет на то, что если лимит памяти будет превышен - п�
�йдет сброс лишнего в своп (которого у меня нет) и (в) если будет совсем плохо запустится task killer и прибьет какое-нибудь ненужное приложение (на практике killer обычно тупит).
За режим выделения памяти отвечают переменные vm.overcommit_memory - которая задает режим выделения памяти и vm.overcommit_ratio, которая определяет насколько можно превысить пределы.
По дефолту у меня были режим 0 и 50% соответственно:
Я их поменял на "режим 2" (не выдавать память авансом - давать только то, что есть в наличии) и 98% (расходовать всю память минус 2% для баша на всякий пожарный) соответственно. Все равно памяти больше не станет - поэтому лучше, чтобы система "жила по средствам" и не тщилась съесть больше, чем есть в наличии.
Это можно сделать из-под рута на один сеанс (до перезагрузки - посмотреть, как поведет себя система):
Либо открыть из-под рута в текстовом редакторе /etc/sysctl.conf
и добавить туда пару строчек:
# профилактируем оверкоммиты памяти
vm.overcommit_ratio = 98
vm.overcommit_memory = 2
Тогда настройки подхватятся после перезагрузки и можно будет на них посмотреть через cat (см команды выше).
В теории это может вызвать подтормаживание лисы, но я побочных эффектов пока не заметил, зато система стала работать стабильно, что не может не радовать.
