Несмотря на ` vm.swappiness=100`, система Mint зависает, но подкачка используется недостаточно
Время хранится как время эпохи Unix (, см. s_mkfs_timeв суперблоке ), а не как календарная дата, поэтому оно не зависит от часового пояса.
При отображении tune2fsпреобразует ее в календарную/человеческую дату, чтобы дать вам представление, значимое для вас, в вашем часовом поясе.
Чтобы получить время в формате UTC, запустите его с:
TZ=UTC0 LC_ALL=C tune2fs -l /dev/sda3 |
sed -n 's/^Filesystem created: *//p'
Это говорит tune2fs, что ваш часовой пояс — UTC (с нулевым смещением от UTC ).
Я добавил LC _ALL=C, чтобы убедиться, что Filesystem createdвозвращается на английском языке, а дата по-прежнему отображается в американском -английском стиле независимо от языкового стандарта пользователя (в case e2fsprogsинтернационализируются в будущем ).
Поскольку S_mkfs_timeнаходится по смещению 0x108 в суперблоке, а суперблок начинается со смещения 0x400 внутри блочного устройства, вы также можете получить время этой эпохи вручную:
od -vAn -j 0x508 -N4 < /dev/sda3
И конвертировать в нужный формат:
$ date --iso-8601=s -d "@$(od -An -j0x508 -N4 -tu4 < /some/device)"
2017-07-23T12:20:22+01:00
$ date -u --iso-8601=s -d "@$(od -An -j0x508 -N4 -tu4 < /some/device)"
2017-07-23T11:20:22+00:00
Короче говоря, подкачка вам не поможет , наиболее эффективным решением этой проблемы является расширение памяти , если вы не изменяете системную среду.
Теперь ответьте на вопросы, которые вы только что упомянули.
1. Почему не происходит подкачка памяти несмотря на 'vm.swappiness=100'?
Во-первых, вы должны знать, как работает своп в Linux. Когда ядро считает, что памяти недостаточно, есть два способа освободить память, чтобы облегчить ситуацию.
- замена анонимных страниц
- восстановить кэшированные страницы
и 'vm.swappiness' просто контролируют, насколько агрессивно ядро будет подкачивать страницы памяти (выгружать больше анонимных страниц или восстанавливать больше кэшированных страниц)
Итак, возникает еще один вопрос: как ядро определяет, какая анонимная страница должна быть заменена? Стратегия сложная, вы можете сослаться на коды здесь в соответствии с вашей версией ядра. Кратко опишите стратегию в одном предложении, замените самые неактивные страницы. Что делать, если нет неактивной страницы, которую, по мнению ядра, можно было бы подкачать?
Вот почему ваша система не выгружает столько памяти, сколько вы думали.
2. Помогает ли принудительная подкачка памяти?
Нет. И нет общепринятого способа принудительной подкачки памяти, ее берет на себя ядро.
Очевидно, у вас тут две проблемы.
Неработающая последовательность REISUB может быть вызвана тем, что магический SysRq не активирован -проверить
cat /proc/sys/kernel/sysrq
# List of possible values in /proc/sys/kernel/sysrq:
# 0 - disable sysrq completely
# 1 - enable all functions of sysrq
# >1 - bitmask of allowed sysrq functions (see below for detailed function description):
# 2 - enable control of console logging level
# 4 - enable control of keyboard (SAK, unraw)
# 8 - enable debugging dumps of processes etc.
# 16 - enable sync command
# 32 - enable remount read-only
# 64 - enable signalling of processes (term, kill, oom-kill)
# 128 - allow reboot/poweroff
# 256 - allow nicing of all RT tasks
Вам нужно 4 (R )+ 64 (E,I )+ 16 (S )+ 32 (U )+ 128 (B )= 244 для классического REISUB (эффект такой же, как у версии тощего слона; как мнемоника, это BUSIER, написанное задом наперёд ).
Что касается подкачки системы :, она работает как положено . Причина такого поведения в том, что у вас много используемой памяти -, что может быть 95%, которые вы получаете -и , затем что-то еще запрашивает много новой оперативной памяти, заставляя большую часть этих 95% помещаться в своп и бороться до конца.
Лучшее, что вы можете сделать, это установить больше оперативной памяти. В противном случае, посмотрите, сможете ли вы укротить либо маленькие процессы, накапливающиеся до этих 95%, либо большие, пожирающие еще 40 -50%. В этом вам может помочь утилита top.
В качестве причудливого решения вы могли бы увеличить кажущуюся подкачку и держать мелкую сошку «урезанной» с помощью некоторого процесса, который контролировал бы систему и, если большая свинья не работала и объем памяти был слишком велик, начинал выделять и освобождать большие полосы памяти -, скажем, вся оставшаяся память плюс 64 МБ, чтобы заставить 64 МБ мелкой сошки попасть в кеш, затем +128 МБ и так далее, пока задержка выделения не превысит заданный временной порог или не начнется большая свинина.
Этот ответ может дать вам хорошее начало, если вы действительно хотите это сделать.
Если система представляет собой ноутбук, его клавиатура клавиша sysreq может не работать, если не установлена дополнительная функциональная клавиша , (которая действует как клавиша shift . ).
Всякий раз, когда приложение (или набор приложений )занимают более 16 ГБ ОЗУ, обычно лучше найти менее раздутое приложение.