Когда я использую слишком много RAM на своей Ubuntu 18.10, замораживаниях GUI. Это прекращает реагировать на клавиатуру и мышь и там не имеет отношения кроме жесткой перезагрузки компьютер.
Я полагал, что это было то, потому что система выгрузила двоичные файлы Gnome к диску и что в конечном счете они были бы подкачаны назад. Но этого никогда не происходило в наблюдаемый период времени (приблизительно 20 минут).
Я пытался решить проблему путем отключения подкачивающий (я предпочитаю терять несохраненную работу потере несохраненной работы и необходимости перезапустить ПК), и давая уничтожителю OOM команду уничтожить, какой бы ни процесс инициировал ситуацию OOM согласно этому ответу. Однако это не помогло. Я пытался использовать большую память путем открытия слишком многих вкладок браузера и единственной вещи, которая произошла, был то, что система стала безразличной снова.
Как это возможно? Что мог быть включен другой механизм, чем перегрузка? (подлинный технический вопрос, не напыщенная речь)
Я контролировал системную статистику во время этого эксперимента, и кажется, что ЦП не выполнял менее чем 100%-ю загрузку, таким образом, это не было вычислительное ограничение. Кроме того, кажется, что GUI заморозился, прежде чем у меня был шанс открыть достаточно вкладок для инициирования уничтожителя OOM.
Лучшая теория, что я могу придумать, состоит в том, что библиотеки GUI используют своего рода средство выделения памяти, которое позволяет им продолжать функционировать даже с очень небольшой памятью, или при помощи некоторого альтернативного механизма свопинга или некоторым ЦП интенсивные перестановки "кучи". Иначе у меня нет подсказки.
Есть ли какое-либо лучшее объяснение этого поведения? Или решение даже?
Править
мой swappiness:
vm.swappiness = 60
моя память:
martin@martin-UX305UA:~$ free -h
total used free shared buff/cache available
Mem: 7.7G 5.5G 145M 993M 2.1G 975M
Swap: 2.0G 57M 1.9G
мой /etc/fstab
UUID=e0edf45b-903c-403f-b2c7-5e69b8b450da / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=0564-1C88 /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
Каждая система нуждается в разделе подкачки или /swapfile.
удалить настройки OOM
изменить текущий неиспользуемый 2G / файл подкачки на как минимум 4G ( см. I необходимо увеличить пространство подкачки для процедуры, при необходимости )
В terminal
, попробовать ...
sudo sysctl vm.swappiness
# для просмотра исходного значения (= 60)
sudo sysctl vm.swappiness=80
# изменение ОЗУ в зависимости от соотношения подкачки
Повторите попытку сервера / IDE / Chrome. Если это работает лучше, попробуйте указанную выше команду с = 90. Протестируйте.
Чтобы сделать постоянным ...
sudo sysctl -w vm.swappiness={final value from above}
# не использовать {}
sudo sysctl -p
# load /etc/sysctl.conf с новыми значениями
Стоит попробовать использовать какую-нибудь улучшенную версию OOM-killer. Например, earlyoom или nohang. На их сайтах описано больше альтернатив.
Эти пользовательские приложения могут реагировать намного быстрее, чем обычные OOM-убийцы ядра.
Сопровождающий nohang на github очень активно отвечает на проблемы, если они у вас возникнут.
Этот подкаст Linux представляет собой вводную аудиоинформацию по теме.