Проблема, я думаю, чем-то похожа на эту тему.
Неважно, если я включил или отключил обмен, всякий раз, когда объем реально используемой оперативной памяти начинает приближаться к максимальному и почти не остается места для дискового кэша, система перестает отвечать на запросы.
Диск крутится дико, и иногда после долгого ожидания 10-30 минут он разморозится, а иногда нет (или у меня кончится терпение). Иногда, если я действую быстро, мне удается медленно открыть консоль и убить некоторые приложения, которые едят оперативную память, например браузер, и система почти мгновенно размораживается.
Из-за этой проблемы я почти никогда не вижу ничего в свопе, только иногда там есть несколько МБ, а затем вскоре после того, как эта проблема появляется. Мое не очень образованное предположение состояло бы в том, что он каким-то образом связан с слишком жадным дисковым кешем или слишком мягким управлением памятью, поэтому, когда память требуется, она не освобождается достаточно быстро и приводит к голоданию системы.
Проблема может быть решена очень быстро, если работать с файлами lagrge (500 МБ +), которые загружаются в дисковый кеш, и после этого система не может выгрузить их достаточно быстро.
Любая помощь или идеи будут с благодарностью.
Сейчас мне приходится жить в постоянном страхе, когда что-то делает компьютер, который может просто зависнуть, и мне, как правило, приходится перезапускать его, если он действительно исчерпывает себя, мне бы очень хотелось, чтобы он просто убивал некоторые приложения пользовательского пространства, такие как broser ( желательно, если бы я мог как-то отметить, кого убить первым)
Хотя загадка - вот почему своп не спас меня в этой ситуации.
ОБНОВЛЕНИЕ: Это не висело в течение некоторого времени, но теперь я снова получил несколько происшествий. Сейчас я постоянно держу монитор памяти на своем экране, и когда зависание происходило, оно все равно показывало ~ 30% свободного места (вероятно, используется дисковым кешем). Дополнительные симптомы: Если во время просмотра видео (проигрыватель VLC) звук останавливается первым, через несколько секунд изображение останавливается. Хотя звук прекратился, я все еще имею некоторый контроль над ПК, но когда изображение останавливается, я даже больше не могу двигать мышью, поэтому я перезапустил его после некоторого ожидания. Между прочим, этого не произошло, когда я начал смотреть видео, но некоторое время спустя (20 минут) и в то время я больше ничего не делал активно, хотя браузер и oowrite были открыты на втором экране все время. По сути, что-то просто решает произойти в какой-то момент, и система зависает.
По запросу в комментариях я запускал dmesg сразу после зависания. Я не заметил ничего странного, но не знал, что искать, поэтому вот оно: https://docs.google.com/document/d/1iQih0Ee2DwsGd3VuQZu0bPbg0JGjSOCRZhu0B05CMYs/edit?hl=en_US&authbcCz7
Ответы:
Чтобы решить эту проблему, я обнаружил, что вам нужно установить следующий параметр примерно в 5% -6% от общей физической памяти, разделенный на количество ядер в компьютере:
Имейте в виду, что это настройка для каждого ядра, поэтому, если у меня 2 ГБ ОЗУ и два ядра, я рассчитал 6% только из 1 ГБ и добавил немного больше, чтобы быть в безопасности.
Это заставляет компьютер пытаться освободить этот объем ОЗУ, и при этом ограничивает возможность кэширования файлов на диске. Конечно, он все еще пытается их кешировать и немедленно поменять их местами, так что вам, вероятно, следует также ограничить обмен:
(100 = своп как можно чаще, 0 = своп только по полной необходимости)
В результате linux больше не принимает случайного решения загрузить весь файл фильма объемом около 1 ГБ в оперативной памяти во время просмотра, что приводит к гибели компьютера.
Теперь есть достаточно зарезервированного пространства, чтобы избежать истощения памяти, что, по-видимому, было проблемой (поскольку больше нет зависаний, как раньше).
После тестирования в течение дня - блокировки исчезли, иногда бывают небольшие замедления, потому что вещи чаще кэшируются, но я могу с этим смириться, если мне не нужно перезагружать компьютер каждые несколько часов.
Урок здесь заключается в том, что управление памятью по умолчанию является лишь одним из вариантов использования и не всегда является лучшим, хотя некоторые люди пытаются предложить иное - Ubuntu для домашних развлечений следует настраивать не так, как сервер.
Возможно, вы захотите сделать эти настройки постоянными, добавив их в ваш файл
/etc/sysctl.conf
следующим образом:источник
vm.swappiness
ничего не даст в таком случае, я полагаю?vm.min_free_kbytes
вообще делает. Он действует как блок страниц, зарезервированных для облегчения атомарного (т. Е. Заполнения или уничтожения / отсутствия__GFP_WAIT
) распределения в условиях высокой конкуренции системной памяти. Здесь действительно может иметь смысл поднять этот вопрос (поскольку, вероятно, эти киоски связаны с конфликтом системной памяти), но это точно не будет причиной, описанной в этом ответе.Это произошло для меня в новой установке Ubuntu 14.04.
В моем случае это не имело никакого отношения к упомянутым проблемам sysctl.
Вместо этого проблема заключалась в том, что UUID раздела подкачки во время установки отличался от того, который был после установки. Так что мой своп никогда не был включен, и мой компьютер зависал после нескольких часов использования.
Решение было проверить текущий UUID раздела подкачки с
а затем
sudo nano /etc/fstab
заменить неверное значение UUID свопа на значение, указанное в blkid.Простая перезагрузка, чтобы повлиять на изменения, и вуаля.
источник
Я знаю, что этот вопрос старый, но у меня была эта проблема в Ubuntu (Chrubuntu) 14.04 на Chromebook Acer C720. Я попробовал решение Krišjānis Nesenbergs, и оно несколько сработало, но иногда все же падало.
Наконец-то я нашел решение, которое сработало, установив zram вместо физического подкачки на SSD. Чтобы установить его, я просто следовал инструкциям здесь , вот так:
После этого мне удалось настроить размер zram swap, изменив
/etc/init/zram-config.conf
строку 21.Я заменил 2 на 1, чтобы размер zram соответствовал размеру барана. С тех пор у меня больше не было зависаний или системного бездействия.
источник
zram
Это жизнеспособный вариант, только если вы не можете установить больше оперативной памяти. Если система работает слишком медленно при переключении на SSD и выходит из ОЗУ без подкачки, этоzram
может помочь немного, пока вы не попытаетесь сделать немного больше, и результат будет таким же, как и из ОЗУ без подкачки.У меня ничего не получалось !!
Поэтому я написал скрипт для мониторинга использования памяти. Сначала он попытается очистить кэш ОЗУ, если потребление памяти увеличит порог. Вы можете настроить этот порог в сценарии. Если даже тогда потребление памяти не будет ниже порогового значения, оно начнет убивать процессы на один в порядке убывания потребления, пока потребление памяти не станет ниже порогового значения. Я установил его на 96% по умолчанию. Вы можете настроить его, изменив значение переменной RAM_USAGE_THRESHOLD в скрипте.
Я согласен, что процессы уничтожения, которые занимают много памяти, не являются идеальным решением, но лучше убить ОДНО приложение, а не терять ВСЕ работу !! сценарий отправит вам уведомление на рабочем столе, если использование ОЗУ увеличит порог. Он также уведомит вас, если убьет какой-либо процесс.
Сохраните код в файле скажем save_hang.py. Запустите скрипт как:
Обратите внимание, что этот скрипт совместим только с Python 3 и требует установки пакета tkinter. Вы можете установить его как:
Надеюсь это поможет...
источник
Я предполагаю, что вы установили
vm.swappiness
очень низкое значение, из-за чего ядро переставляется слишком поздно, оставляя слишком мало оперативной памяти для работы системы.Вы можете показать текущую настройку подкачки, выполнив:
По умолчанию это значение равно 60. Ubuntu Wiki рекомендует установить значение 10, но вы можете установить более высокое значение. Вы можете изменить это, запустив:
Это изменит его только для текущего сеанса , чтобы сделать его постоянным, необходимо добавить
vm.swappiness = 10
его в/etc/sysctl.conf
файл.Если у вас медленный диск, подумайте о покупке нового.
источник
dmesg
команды вы должны увидеть некоторую информацию (и имя процесса + идентификатор) процесса. Я думаю, вам лучше купить новый, более быстрый диск. Или обновите свою RAM.Я долго боролся с этой проблемой, но теперь, похоже, она решается на моем ноутбуке.
Если ни один из других ответов не работает для вас (я пробовал большинство из них), поиграйтесь с min_free_kbytes , чтобы иметь больше места в оперативной памяти, когда ваш компьютер начинает подкачку (непосредственно перед достижением этого минимального значения в вашей свободной оперативной памяти).
У меня 16 ГБ ОЗУ, но раньше, чем позже, память заполнялась, а затем перестала отвечать на 10-30 минут, пока некоторые вещи не поменялись местами.
По крайней мере, для меня установка значения min_free_kbytes выше рекомендованного значительно ускоряет процесс обмена.
Для 16 ГБ ОЗУ попробуйте это:
Чтобы установить это значение, смотрите другие ответы или просто гуглите его :)
источник
Я постоянно запускаю один из моих ноутбуков с живой SD-карты Ubuntu с небольшим разделом хранения ext4 и файлом подкачки на жестком диске. Когда используется почти вся оперативная память, а значение подкачки слишком низкое (иногда я предпочитаю полностью отключить жесткий диск, если это возможно, потому что он шумный), производительность Linux для меня имеет тенденцию падать с обрыва, так что просто TTY1, чтобы убить Firefox, занимает 15 минут.
Повышение
/proc/sys/vm/vfs_cache_pressure
значения по умолчанию от 100 до 6000, кажется, помогает предотвратить это. Тем не менее, документация ядра предупреждает против этого, говоряЯ не совсем уверен в побочных эффектах этого, поэтому я буду осторожен в этом.
источник
vfs_cache_pressure
приближении к 10 (т. Е. Намного меньше 100) и настройкеmin_free_kbytes
выше. Имейте в виду, что если вы установитеmin_free_kbytes
слишком высокое значение, ядро OOM Killer убьет всех!min_free_kbytes
до 262144, и я заметил, что снижениеvfs_cache_pressure
имеет противоположный эффект - снижение его ниже 100 заставляет систему перестать отвечать на запросы намного быстрее. Я не уверен, почему именно.vfs_cache_pressure
приведет к тому, что директории будут выброшены раньше, чем содержимое кэшированного файла, и, как результат, общая производительность, как правило, пострадает со значениями более 100. Если вы сможете найти шаги для воспроизведения, чтобы вызвать сбой / зависание системы, например, с Ubuntu Live CD тогда разработчики ядра могут выяснить причину. Для меня зависание происходит без предупреждения. Я думаю, что ядро зависает из-за OOM до того, как OOM Killer освободит достаточно оперативной памяти. Сейчас я запускаю min_free_kbytes = 100000, admin_reserve_kbytes = 250000 и user_reserve_kbytes = 500000.