Замораживание компьютера при почти полной ОЗУ, возможно проблема с дисковым кэшем

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

Существует приложение Windows под названием Format Factory, и оно хорошо работает в WINE. После его установки в левой части окна есть все параметры преобразования. Я думаю, что это довольно понятно. Я надеюсь, что это работает!

1
задан 13 April 2017 в 15:14

5 ответов

Это произошло для меня в новой установке Ubuntu 14.04.

В моем случае это не имело ничего общего с упомянутыми проблемами sysctl.

Вместо этого проблема заключалась в том, что UUID раздела подкачки был другим во время установки, чем после установки. Таким образом, моя своп никогда не включалась, и моя машина блокировалась через несколько часов.

Решение состояло в том, чтобы проверить текущий UUID раздела подкачки на

sudo blkid

и затем sudo nano /etc/fstab, чтобы заменить значение UUID некорректного свопа с сообщением blkid.

Простая перезагрузка, чтобы повлиять на изменения, и voila.

8
ответ дан 25 May 2018 в 21:11
  • 1
    Спасибо огромное! Я боролся с этой невероятно бешеной ошибкой для чего-то близкого к году, и попытался все исправить это. Почему Linux имеет такое поведение? Похоже, он должен действовать так, как будто нет свопа, и просто вызывайте ООМ-убийцу. Вместо этого он, похоже, притворяется, что существует своп, но затем не удается фактически заменить все (потому что на самом деле нет, так как он неправильно настроен). – crazy2be 7 September 2015 в 19:40

Я знаю, что этот вопрос старый, но у меня была эта проблема в Ubuntu (Chrubuntu) 14.04 на Chromebook Acer C720. Я попробовал решение Krišjānis Nesenbergs, и он работал несколько, но все же иногда разбивался.

Наконец-то я нашел решение, которое работало при установке zram вместо использования физической замены на SSD. Чтобы установить его, я просто выполнил следующие инструкции:

sudo apt-get install zram-config

. После этого мне удалось настроить размер zram-обмена, изменив /etc/init/zram-config.conf в строке 21.

20: # Calculate the memory to user for zram (1/2 of ram)
21: mem=$(((totalmem / 2 / ${NRDEVICES}) * 1024))

Я заменил 2 на 1, чтобы размер zram был такого же размера, как и количество бара, которое у меня есть. С тех пор у меня не было больше зависаний или системной безответственности.

4
ответ дан 25 May 2018 в 21:11
  • 1
    zram является жизнеспособным вариантом, только если вы не можете установить больше ОЗУ. Если система работает слишком медленно при переключении на SSD и выходит из ОЗУ без свопа, тогда zram может немного помочь, пока вы не попытаетесь сделать немного больше, и результат будет таким же, как из ОЗУ без свопа. – Mikko Rantalainen 17 December 2017 в 20:45

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

Вы можете покажите текущую настройку swappiness, выполнив:

sysctl vm.swappiness

По умолчанию это значение равно 60. Ubuntu Wiki рекомендует установить значение 10, но не стесняйтесь устанавливать его на более высокое значение. Вы можете изменить его, выполнив:

sudo sysctl vm.swappiness=10

Это изменит его только на текущий сеанс, чтобы сделать его постоянным, вам нужно добавить vm.swappiness = 10 в файл /etc/sysctl.conf.

Если ваш диск медленный, подумайте о покупке нового.

2
ответ дан 25 May 2018 в 21:11
  • 1
    Фактически сокращение общности сократило проблему (это случалось реже). Я держу его в 5 сейчас. Хотя, возможно, это была еще одна проблема с более высокой swapinness, потому что, когда ей было 60, и я решил посмотреть фильм или отредактировать большой файл, весь файл и почти GB был загружен в память, а затем сразу же началась перестановка программ, которые я активно использовать и даже сам пользовательский интерфейс. Дело в том, что я понимаю, что часть обмена, что я хочу, убивает жадные пользовательские приложения, а не замораживает машину при выходе из бара. (И желательно ограничить размер файла в кеше) – Krišjānis Nesenbergs 10 May 2011 в 19:22
  • 2
    @Krisa: когда в системе заканчивается память (оперативная память и своп), ядро ​​вызывает oom_kill, который убивает процессы для сохранения памяти. К сожалению, вы не можете контролировать целевые процессы. Чтобы запустить его вручную, нажмите Alt + SysRq + F. При запуске команды dmesg вы должны увидеть некоторую информацию (и имя процесса + id) процесса. Думаю, вам лучше купить новый, более быстрый диск. Или обновите свою оперативную память. – Lekensteyn 10 May 2011 в 20:37
  • 3
    Проблема в том, что oom_kill просто не вызывается до того, как компьютер заблокирован на 30 минут. Также - есть ли хотя бы способ узнать, какой процесс будет убит первым? – Krišjānis Nesenbergs 11 May 2011 в 01:18
  • 4
    У меня 2GB Ram, а жесткий диск - 5400 об / мин. Я действительно не думаю, что это такая старая система, которая оправдывает полчаса зависанием, наблюдая за некоторым видео на одном мониторе и просматривая около 20-30 вкладок в другом. На самом деле я был бы очень доволен, если бы я просто мог получить доступ к консоли и убить некоторые процессы - есть ли способ сделать пользовательский ввод и высокий суперпринтер терминала, так что он работает, пока система зависает? – Krišjānis Nesenbergs 11 May 2011 в 01:28
  • 5
    Во всяком случае - замена и объем оперативной памяти немного оффтопик. Проблема заключается в том, что система перестает отвечать на долгое время, даже если swap отключен, и после этого иногда все еще запускается программа (так что ей удается где-то найти память), а в других случаях работает oom_killer. Система должна быть в состоянии сказать, что у нее заканчивается баран, и просто не позволяйте мне запускать больше материала. Итак, есть ли способ остановить эти зависания или установить приоритет ввода пользователя настолько высоким, что я могу переключиться на консоль, когда они произойдут, и сами убить некоторые процессы? – Krišjānis Nesenbergs 11 May 2011 в 02:54

Ничего не работало для меня !!

Итак, я написал сценарий для мониторинга использования памяти. Сначала попробуйте очистить кеш оперативной памяти, если потребление памяти увеличит порог. Вы можете настроить этот порог в скрипте. Если даже тогда потребление памяти не будет ниже порогового значения, оно начнет уничтожать процессы на единицу в порядке убывания объема памяти до тех пор, пока потребление памяти не будет ниже порогового значения. Я установил его по умолчанию 96%. Вы можете настроить его, изменив значение переменной RAM_USAGE_THRESHOLD в скрипте.

Я согласен с тем, что уничтожение процессов, которые потребляют высокую память, не является идеальным решением, но лучше убить ОДНОЕ приложение, а не потерять ВСЕ работу !! сценарий отправит вам уведомление на рабочем столе, если использование ОЗУ увеличит порог. Он также уведомит вас, если он убьет любой процесс.

#!/usr/bin/env python
import psutil, time
import tkinter as tk
from subprocess import Popen, PIPE
import tkinter
from tkinter import messagebox
root = tkinter.Tk()
root.withdraw()

RAM_USAGE_THRESHOLD = 96
MAX_NUM_PROCESS_KILL = 100

def main():
    if psutil.virtual_memory().percent >= RAM_USAGE_THRESHOLD:
        # Clear RAM cache
        mem_warn = "Memory usage critical: {}%\nClearing RAM Cache".\
            format(psutil.virtual_memory().percent)
        print(mem_warn)
        Popen("notify-send \"{}\"".format(mem_warn), shell=True)
        print("Clearing RAM Cache")
        print(Popen('echo 1 > /proc/sys/vm/drop_caches',
                    stdout=PIPE, stderr=PIPE,
                    shell=True).communicate())
        post_cache_mssg = "Memory usage after clearing RAM cache: {}%".format(
                            psutil.virtual_memory().percent)
        Popen("notify-send \"{}\"".format(post_cache_mssg), shell=True)
        print(post_cache_mssg)

        if psutil.virtual_memory().percent < RAM_USAGE_THRESHOLD:
            print("Clearing RAM cache saved the day")
            return
        # Kill top C{MAX_NUM_PROCESS_KILL} highest memory consuming processes.
        ps_killed_notify = ""
        for i, ps in enumerate(sorted(psutil.process_iter(),
                                      key=lambda x: x.memory_percent(),
                                      reverse=True)):
            # Do not kill root
            if ps.pid == 1:
                continue
            elif (i > MAX_NUM_PROCESS_KILL) or \
                    (psutil.virtual_memory().percent < RAM_USAGE_THRESHOLD):
                messagebox.showwarning('Killed proccess - save_hang',
                                       ps_killed_notify)
                Popen("notify-send \"{}\"".format(ps_killed_notify), shell=True)
                return
            else:
                try:
                    ps_killed_mssg = "Killed {} {} ({}) which was consuming {" \
                                     "} % memory (memory usage={})". \
                        format(i, ps.name(), ps.pid, ps.memory_percent(),
                               psutil.virtual_memory().percent)
                    ps.kill()
                    time.sleep(1)
                    ps_killed_mssg += "Current memory usage={}".\
                        format(psutil.virtual_memory().percent)
                    print(ps_killed_mssg)
                    ps_killed_notify += ps_killed_mssg + "\n"
                except Exception as err:
                    print("Error while killing {}: {}".format(ps.pid, err))
    else:
        print("Memory usage = " + str(psutil.virtual_memory().percent))
    root.update()


if __name__ == "__main__":
    while True:
        try:
            main()
        except Exception as err:
            print(err)
        time.sleep(1)

Сохраните код в файле say save_hang.py. Запустите скрипт как:

sudo python save_hang.py

Обратите внимание, что этот скрипт совместим только для Python 3 и требует установки пакета tkinter. вы можете установить его как:

sudo apt-get install python3-tk

Надеюсь, это поможет ...

1
ответ дан 25 May 2018 в 21:11

Я запускаю один из своих ноутбуков с живого Ubuntu SD-карты постоянно, с небольшим разделом хранения ext4 и файлом подкачки на жестком диске. Когда используется почти вся оперативная память, и значение swappiness слишком низкое (иногда я предпочитаю полностью отключить жесткий диск, потому что это шумно), производительность Linux имеет тенденцию падать на скалу для меня, так что просто добраться до TTY1 для убийства Firefox занимает 15 минут.

Повышение /proc/sys/vm/vfs_cache_pressure от значения по умолчанию 100 до значения 6000, похоже, помогает предотвратить это. Однако документация ядра предостерегает от этого, говоря

Increasing vfs_cache_pressure significantly beyond 100 may have negative
performance impact. Reclaim code needs to take various locks to find freeable
directory and inode objects. With vfs_cache_pressure=1000, it will look for
ten times more freeable objects than there are.

Я не совсем уверен в побочных эффектах этого, поэтому я был бы осторожен в этом.

0
ответ дан 25 May 2018 в 21:11
  • 1
    Вероятно, вы получите лучшие результаты с vfs_cache_pressure ближе к 10 (то есть намного меньше 100) и установите min_free_kbytes выше. Будьте предупреждены, что если вы установите min_free_kbytes слишком высоко, ядро ​​OOM killer убьет всех! – Mikko Rantalainen 17 December 2017 в 20:50
  • 2
    @MikkoRantalainen Я уже поднял min_free_kbytes до 262144, и я заметил, что понижение vfs_cache_pressure имеет противоположный эффект - снижение его ниже 100 заставляет систему становиться невосприимчивой намного быстрее. Я не совсем понимаю, почему именно. – Hitechcomputergeek 19 December 2017 в 03:41
  • 3
    В общем случае увеличение vfs_cache_pressure приведет к выбросу дирижалок перед содержимым кэшированного файла, и в результате общая производительность, как правило, будет страдать со значениями более 100. Если вы можете определить шаги для воспроизведения, чтобы сбой / зависание системы, начиная с, например, Ubuntu Live CD, тогда разработчики ядра могут выяснить основную причину. Для меня зависание происходит без предупреждения. Мое лучшее предположение заключается в том, что ядро ​​зависает из-за OOM, прежде чем OOM Killer освободит достаточное количество ОЗУ. Теперь я запускаю min_free_kbytes = 100000, admin_reserve_kbytes = 250000 и user_reserve_kbytes = 500000. – Mikko Rantalainen 19 December 2017 в 21:11
  • 4
    (cont) Я еще не разбился с конфигурацией выше, хотя у меня есть swappiness = 5 и vfs_cache_pressure = 20. Система имеет 16 ГБ оперативной памяти и 8 ГБ свопа на SSD. Другая система имеет 32 ГБ оперативной памяти и нулевую свопинг, и она случайно кажется, что она страдает от одной и той же проблемы - при нажатии Alt + SysRq + f после того, как система чувствует себя медленно, похоже, помогает, поэтому я думаю, что если OOM Killer будет действовать достаточно быстро, система не будет висеть. – Mikko Rantalainen 19 December 2017 в 21:12

Другие вопросы по тегам:

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