English TLDR: 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% соответственно: vik@fantom:~/blog$ cat /proc/sys/vm/overcommit_memory 0 vik@fantom:~/blog$ cat /proc/sys/vm/overcommit_ratio 50 Я их поменял на "режим 2" (не выдавать память авансом - давать только то, что есть в наличии) и 98% (расходовать всю память минус 2% для баша на всякий пожарный) соответственно. Все равно памяти больше не станет - поэтому лучше, чтобы система "жила по средствам" и не тщилась съесть больше, чем есть в наличии. Это можно сделать из-под рута на один сеанс (до перезагрузки - посмотреть, как поведет себя система): # echo 2 > /proc/sys/vm/overcommit_memory # echo 98 > /proc/sys/vm/overcommit_ratio Либо открыть из-под рута в текстовом редакторе /etc/sysctl.conf и добавить туда пару строчек: # профилактируем оверкоммиты памяти vm.overcommit_ratio = 98 vm.overcommit_memory = 2 Тогда настройки подхватятся после перезагрузки и можно будет на них посмотреть через cat (см команды выше). В теории это может вызвать подтормаживание лисы, но я побочных эффектов пока не заметил, зато система стала работать стабильно, что не может не радовать.