Каков наилучший способ предотвращения зависания памяти (OOM) в Linux?

Question

Есть ли способ заставить OOM Killer работать и предотвратить зависание Linux? Я запускаю приложения на Java и C #, где обычно используется любая выделенная память, и (если я правильно понимаю) чрезмерные коммиты приводят к зависанию машины. Прямо сейчас, как временное решение, я добавил,

vm.overcommit_memory = 2
vm.overcommit_ratio = 10

в /etc/sysctl.conf.

Спасибо всем, кто может объяснить, почему существующий OOM killer не может работать правильно гарантированным образом, убивая процессы всякий раз, когда ядру не хватает «реальной» памяти.

РЕДАКТИРОВАТЬ - многие ответы совпадают с ответами Майкла «если вы испытываете проблемы, связанные с убийцей ООМ, вам, вероятно, нужно исправить то, что заставляет вас исчерпать память». Я не думаю, что это правильное решение. Всегда будут приложения с ошибками, и я бы хотел настроить ядро ​​так, чтобы вся моя система не зависала. Учитывая мое текущее техническое понимание, это не кажется невозможным.

Answer 1

Ниже приведен действительно базовый скрипт на Perl, который я написал. С небольшой настройкой это может быть полезно. Вам просто нужно изменить пути, которые у меня есть, на пути любых процессов, использующих Java или C #. Вы можете изменить команды уничтожения, которые я использовал для перезапуска команд. Конечно, чтобы не вводить perl memusage.pl вручную, вы можете поместить его в файл crontab для автоматического запуска. Вы также можете использовать perl memusage.pl> log.txt, чтобы сохранить вывод в файл журнала. Извините, если это не очень помогает, но мне было скучно, когда я пила чашку кофе. :-D Ура

#!/usr/bin/perl -w
# Checks available memory usage and calculates size in MB
# If free memory is below your minimum level specified, then
# the script will attempt to close the troublesome processes down
# that you specify. If it can't, it will issue a -9 KILL signal.
#
# Uses external commands (cat and pidof)
#
# Cheers, insertable

our $memmin = 50;
our @procs = qw(/usr/bin/firefox /usr/local/sbin/apache2);

sub killProcs
{
    use vars qw(@procs);
    my @pids = ();
    foreach $proc (@procs)
    {
        my $filename=substr($proc, rindex($proc,"/")+1,length($proc)-rindex($proc,"/")-1);
        my $pid = `pidof $filename`;
        chop($pid);
        my @pid = split(/ /,$pid);
        push @pids, $pid[0];
    }
    foreach $pid (@pids)
    {
        #try to kill process normall first
        system("kill -15 " . $pid); 
        print "Killing " . $pid . "\n";
        sleep 1;
        if (-e "/proc/$pid")
        {
            print $pid . " is still alive! Issuing a -9 KILL...\n";
            system("kill -9 " + $pid);
            print "Done.\n";
        } else {
            print "Looks like " . $pid . " is dead\n";
        }
    }
    print "Successfully finished destroying memory-hogging processes!\n";
    exit(0);
}

sub checkMem
{
    use vars qw($memmin);
    my ($free) = $_[0];
    if ($free > $memmin)
    {
        print "Memory usage is OK\n";
        exit(0);
    } else {
        killProcs();
    }
}

sub main
{
    my $meminfo = `cat /proc/meminfo`;
    chop($meminfo);
    my @meminfo = split(/\n/,$meminfo);
    foreach my $line (@meminfo)
    {
        if ($line =~ /^MemFree:\s+(.+)\skB$/)
        {
            my $free = ($1 / 1024);
            &checkMem($free);
        }
    }
}

main();

Answer 2

Если oom_adj вашего процесса установлен в -17, он не будет рассматриваться как убийство, хотя я сомневаюсь, что это проблема здесь.

cat /proc/<pid>/oom_adj

сообщит вам значение oom_adj вашего процесса (ов).

Answer 3

Я обнаружил, что решение проблем со стабильностью в основном основано на точном определении основной причины. К сожалению, для этого требуется способность видеть, что происходит, когда возникает проблема, а это действительно плохое время для попытки запуска различных программ мониторинга.

Одна вещь, которую я иногда находил полезным, состояла в том, чтобы запустить небольшой скрипт мониторинга во время загрузки, который бы регистрировал различные интересные цифры и снимал запущенные процессы. Затем, в случае аварии, я мог посмотреть на ситуацию непосредственно перед аварией. Иногда я обнаруживал, что интуиция была совершенно неверной в отношении первопричины. К сожалению, этот скрипт давно устарел, или я бы дал ссылку.

Answer 4

Прежде всего, как вы можете быть уверены, что замораживания связаны с OOM killer? У меня есть сеть систем на местах, и я получаю нередкие зависания, которые, по-видимому, не связаны с OOM (наше приложение довольно стабильно использует память). Может ли это быть что-то еще? Есть ли интересное оборудование? Есть нестабильные драйверы? Высокопроизводительное видео?

Даже если бы убийца OOM был вовлечен и работал, у вас все равно были бы проблемы, потому что то, что, как вы думали, работало, теперь мертво, и кто знает, что за оставленный беспорядок.

Действительно, если вы испытываете проблемы, связанные с OOM killer, то вам, вероятно, нужно исправить то, что приводит к нехватке памяти.

Answer 5

Я бы сказал, что лучший способ предотвратить зависание OOM - не исчерпать виртуальную память. Если вы регулярно исчерпываете виртуальную память или приближаетесь, то у вас есть большие проблемы.

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

Более того, до того, как в вашей ОС закончится виртуальная память, она начнет делать плохие вещи, такие как удаление страниц из часто используемых общих библиотек, что может привести к снижению производительности, так как их приходится часто возвращать назад, что очень плохо для пропускной способности.

Мои предложения:

• Получи больше оперативной памяти
• Запускать меньше процессов
• Заставьте процессы, которые вы выполняете, использовать меньше памяти (это может включать устранение утечек памяти в них)

И, возможно, также

• Установить больше пространства подкачки

Если это полезно в вашем случае использования.

Большинство многопроцессорных серверов работают с настраиваемым (максимальным) числом процессов, так что вы обычно можете настроить его вниз. Многопоточные серверы обычно позволяют вам сконфигурировать, сколько памяти использовать для своих буферов и т. Д. Для внутреннего использования.