По следам OOM Killer'a.
Последнее время читатели и друзья задают один и тот же вопрос про OOM Killer механизм ядра Linux и как сделать систему отзывчивой при превышении лимита памяти так, чтобы не использовать страничную подкачку очень часто.
Поэтому я решил написать заметку с обзором проблемы и её решения.
Преамбула: Памяти никогда не бывает много!
В недавней альфа версии десктоп клиента Telegram для Linux была проблема при совершении звонков.
Во время звонка одно ядро процессора было загружено до 100%, после пары минут работы начиналась неконтролируемая утечка памяти в процессе плиента и если страничная подкачка в ядре отключена (тестировалось на Linux ядре с отключенной подкачкой - переносимая система Debian запускалась с флэш диска с параметром ядра vm.spappiness=0, но ведь многие до сих пор так делают и полностью отключают подкачку на своих рабочих машинах чтобы не вредить SSD дискам), ещё через пару минут, когда свободная память заканчивалась, система зависала намертво с шикарными эффектами заиканий в выводе Pulse Audio.
В ядрах старше версии 3.5 vm.swappiness=0 отключает дамп в swap полностью и в итоге система зависает при исчерпании памяти или испытывает очень сильное замедление (freeze) - лучше никогда не делать так на серверах с SSD, крайнее значение vm.swappiness=1, ранее это означало, что ядро будет сбрасывать страницы в область страничной подкачки (swap раздел) при остатке в 1% свободной памяти в системе.
Но сейчас (в ядрах старше версии 3.5) если vm.swappiness=1 ядро будет "свопить" в страничную подкачку только когда памяти остаётся меньше, чем установлено параметром vm.min_free_kbytes - точно так же, как и было на более ранних ядрах при отключении подкачки установкой параметра vm.swappiness=0.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/vm.txt
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
https://www.kernel.org/doc/Documentation/sysctl/kernel.txt
Сделав дамп памяти программы клиента через gdb, отправил отчёт об ошибке - следующая альфа версия клиента Telegram Desktop уже не имела проблем со звонками, баг пофиксили.
Но ведь утечки памяти из-за программных ошибок и слишком большой расход памяти возникают очень часто! Как с этим бороться? Читайте далее...
Последнее время читатели и друзья задают один и тот же вопрос про OOM Killer механизм ядра Linux и как сделать систему отзывчивой при превышении лимита памяти так, чтобы не использовать страничную подкачку очень часто.
Поэтому я решил написать заметку с обзором проблемы и её решения.
Преамбула: Памяти никогда не бывает много!
В недавней альфа версии десктоп клиента Telegram для Linux была проблема при совершении звонков.
Во время звонка одно ядро процессора было загружено до 100%, после пары минут работы начиналась неконтролируемая утечка памяти в процессе плиента и если страничная подкачка в ядре отключена (тестировалось на Linux ядре с отключенной подкачкой - переносимая система Debian запускалась с флэш диска с параметром ядра vm.spappiness=0, но ведь многие до сих пор так делают и полностью отключают подкачку на своих рабочих машинах чтобы не вредить SSD дискам), ещё через пару минут, когда свободная память заканчивалась, система зависала намертво с шикарными эффектами заиканий в выводе Pulse Audio.
В ядрах старше версии 3.5 vm.swappiness=0 отключает дамп в swap полностью и в итоге система зависает при исчерпании памяти или испытывает очень сильное замедление (freeze) - лучше никогда не делать так на серверах с SSD, крайнее значение vm.swappiness=1, ранее это означало, что ядро будет сбрасывать страницы в область страничной подкачки (swap раздел) при остатке в 1% свободной памяти в системе.
Но сейчас (в ядрах старше версии 3.5) если vm.swappiness=1 ядро будет "свопить" в страничную подкачку только когда памяти остаётся меньше, чем установлено параметром vm.min_free_kbytes - точно так же, как и было на более ранних ядрах при отключении подкачки установкой параметра vm.swappiness=0.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/vm.txt
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sysctl/kernel.txt
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
https://www.kernel.org/doc/Documentation/sysctl/kernel.txt
Сделав дамп памяти программы клиента через gdb, отправил отчёт об ошибке - следующая альфа версия клиента Telegram Desktop уже не имела проблем со звонками, баг пофиксили.
Но ведь утечки памяти из-за программных ошибок и слишком большой расход памяти возникают очень часто! Как с этим бороться? Читайте далее...