Как решить эту проблему памяти корректно?

Question

Как решить эту проблему памяти корректно?

Обычно система помещает все в кэш как долго существует доступная свободная память, поэтому обычно этот шаг, кажется, не необходим.

Проверьте, существует ли/dev/shm точка монтирования. На большинстве дистрибутивов сокращаются наполовину Вашей RAM, смонтирован там как электронный диск.

10

ulimit cgroups limit memory

Community 13.04.2017, 15:36

Ссылка

2 ответа

Я часто сталкиваюсь с одной и той же проблемой. Мой общий рабочий процесс включает тяжелые вычисления в MATLAB. Иногда я непреднамеренно пытаюсь выделить новую переменную, размер которой превышает объем доступной памяти. Система зависает, и мне обычно приходится жестко перезагружать машину, чтобы вернуться к работе. : P

В моем случае, и это звучит так же, как и в вашем, я не был так сильно озабочен ограничением объема памяти, используемой MATLAB до статического количества - меня интересовало отсутствие замороженной машины, и я был готов пожертвовать моим процессом MATLAB, чтобы сохранить отзывчивость системы.

Вдохновленный ответом на этот пост , я написал следующий сценарий (я назвал его watch_memory.sh):

#!/bin/bash

MONITOR=$(free | grep 'buffers/cache:')
MEM_USED=$(echo $MONITOR | awk '{ print $3 }')
MEM_FREE=$(echo $MONITOR | awk '{ print $4 }')

MEM_PERC=$(( 100*MEM_USED / (MEM_FREE+MEM_USED) ))

while :; do
    if [ "$MEM_PERC" -gt "95" ]
    then
        kill $1
        echo "$1 killed for using too much memory."
        exit
    fi
    sleep 1

    MONITOR=$(free | grep 'buffers/cache:')
    MEM_USED=$(echo $MONITOR | awk '{ print $3 }')
    MEM_FREE=$(echo $MONITOR | awk '{ print $4 }')
    MEM_PERC=$(( 100*MEM_USED / (MEM_FREE+MEM_USED) ))
done

Этот сценарий каждую секунду проверяет процентное количество свободной памяти. Когда система заканчивается, ваш pid "козла отпущения" (переданный в качестве аргумента скрипту) будет убит.

Без изменения приоритета (аккуратности) скрипта на то, чтобы убить козла отпущения, потребовалось около 10-20 секунд, но он все равно работал. Запуск сценария с отрицательным приоритетом привел к мгновенному уничтожению после нарушения (11916 в этом примере - это идентификатор pid, который я хочу убить, если у меня закончится память):

sudo nice -n -5 bash watch_memory.sh 11916

0

27.01.2020, 20:03

Ссылка

Похожие вопросы

Huygens · Accepted Answer · 27.01.2020, 20:03

Кто-то предложил в Вашем слышать cgroups. Ну, попытайтесь искать то направление, поскольку оно может предоставить Вам:

относившийся группа задачи Вы выбираете (таким образом не в масштабе всей системы, но ни один для каждого процесса)
пределы устанавливаются для группы
пределы статичны
они могут осуществить жесткий предел памяти и/или memory+swap

Что-то как этот могло приблизить Вас к Вашим целям:

group limited {
  memory {
    memory.limit_in_bytes = 50M;
    memory.memsw.limit_in_bytes = 50M;
  }
}

Это говорит, что задачи под этим cgroup могут использовать в максимуме 50M памяти только и 50M memory+swap, поэтому когда память будет полна, это не подкачает, но если память не полна, и некоторые данные могли бы быть отображены в подкачке, это могло быть позволено.

Вот выборка из документации памяти cgroup:

При помощи предела memsw можно избежать системы OOM, который может быть вызван нехваткой подкачки.

Все еще точно, что я ожидал. Но различия между тем, что я ожидаю и действительность, являются часто довольно значительными :) В этом случае я хотел быть уверенным, что я не пропустил ничего как overcommit_memory переменная ядра. Спасибо всем. цикл-AES.README — ,

Как решить эту проблему памяти корректно?

Теги

Похожие вопросы