Как Ubuntu может стать безразличной когда OOM без перегрузки?

Когда я использую слишком много RAM на своей Ubuntu 18.10, замораживаниях GUI. Это прекращает реагировать на клавиатуру и мышь и там не имеет отношения кроме жесткой перезагрузки компьютер.

Я полагал, что это было то, потому что система выгрузила двоичные файлы Gnome к диску и что в конечном счете они были бы подкачаны назад. Но этого никогда не происходило в наблюдаемый период времени (приблизительно 20 минут).

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

Как это возможно? Что мог быть включен другой механизм, чем перегрузка? (подлинный технический вопрос, не напыщенная речь)

Я контролировал системную статистику во время этого эксперимента, и кажется, что ЦП не выполнял менее чем 100%-ю загрузку, таким образом, это не было вычислительное ограничение. Кроме того, кажется, что GUI заморозился, прежде чем у меня был шанс открыть достаточно вкладок для инициирования уничтожителя OOM.

enter image description here

Лучшая теория, что я могу придумать, состоит в том, что библиотеки 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
0
задан 13 May 2019 в 17:45

2 ответа

Каждая система нуждается в разделе подкачки или /swapfile.

В 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 с новыми значениями

0
ответ дан 13 May 2019 в 17:45

Стоит попробовать использовать какую-нибудь улучшенную версию OOM-killer. Например, earlyoom или nohang. На их сайтах описано больше альтернатив.

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

Сопровождающий nohang на github очень активно отвечает на проблемы, если они у вас возникнут.

Этот подкаст Linux представляет собой вводную аудиоинформацию по теме.

2
ответ дан 4 June 2020 в 17:47

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

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