Почему RHEL использует подкачку, даже если vm.swappiness = 1?
Программа toe перечисляет записи в базе данных терминалов ncurses, но она может оказаться бесполезной в простом меню.
Например, пакет Debian ncurses-base содержит чьё-то представление о наиболее распространённых описаниях терминалов:
Этот пакет содержит файлы данных terminfo для поддержки наиболее распространённых типов терминалов, включая ansi, dumb, linux, rxvt, screen, sun, vt100, vt102, vt220, vt52 и xterm.
Выбор является специальным и отражает сообщения об ошибках. Проверка фактического пакета;
ansi cons25 cons25-debian cygwin dumb Eterm Eterm-цвет hurd linux mach mach mach-bold mach-color mach-gnu mach-gnu-color pcansi rxvt rxvt-basic rxvt-m rxvt-unicode screen screen-256color screen-256color-bce screen-bce screen-s screen-w sun vt100 vt102 vt220 vt52 wsvt25 wsvt25m xterm xterm-256color xterm-color xterm-debian xterm-mono xterm-r5 xterm-r6 xterm-vt220 xterm-xfree86
или 41 запись. Если посмотреть на список, то можно не согласиться:
xterm-xfree86был устаревшим в пользуxterm-new12 лет назад.- пользователей для
hurd(и связанных с нимmachзаписей) немного, и - он не включает ни одной из исправленных записей для konsole или vte. Чтобы получить эти (а также исправленные варианты 256 цветов), вам понадобится
ncurses-term(который содержит 2675 записей).
Программа infocmp не является специфичной для ncurses, поэтому вы сможете использовать ее на большем количестве платформ - для проверки существования. Но если вы хотите проверить существование (и посмотреть на конкретные возможности), tput - это то, с чего следует начать.
На большинстве систем, которые вы, скорее всего, будете использовать, вы будете использовать терминальную базу данных ncurses - или некоторое подмножество, определенное упаковщиком. Поскольку база данных терминалов ncurses определяет 256-цветные варианты путем добавления "-256color" к рекомендуемому имени терминала, то найти подходящий вариант можно, просто проверив наличие предпочтительного имени с суффиксом.
Дальнейшее чтение:
Как вам уже говорили (см. Почему не работает swappiness? ), изменение swappinessвлияет только на будущие решения, принимаемые ядром, когда ему нужно освободить память. Его уменьшение не приведет к тому, что ядро перезагрузит все, что было выгружено.
Ваш вывод vmstatпоказывает, что подкачка активно не используется, т. е. ваши текущие рабочие нагрузки действительно не нуждаются в выгруженных страницах.
Нет смысла пытаться микро-управлять использованием подкачки ядром так, как это делаете вы. В зависимости от вашей рабочей нагрузки решите, нужно ли вам отдавать предпочтение кэшу страниц или нет, соответствующим образом настройте swappiness, а затем оставьте систему работать.
Если вы действительно хотите очистить подкачку, отключите ее и -снова включите:
swapoff -a && swapon -a
free -mне является надежным источником информации об использовании свопов. Вместо этого используйте vmstatдо и после эхо-команд, которые временно изменяют подкачку.
1)swapoff -a && swapon -a && vmstat
2)выполняют работу, требующую подкачки
3)vmstat
Теперь вы знаете, сколько свопинга происходит до изменения swappiness. Если обмен не происходит, найдите другие рабочие места, которые делают обмен.
4 )используйте и эхо-команду для временного изменения подкачки
5)swapoff -a && swapon -a && vmstat
6)выполнять работу, требующую подкачки
7)vmstat
8 )сравните значения si и so .
Значения для просмотра::
si: Amount of memory swapped in from disk (/s).
so: Amount of memory swapped to disk (/s).
Вы также можете найти полезную информацию в Руководстве по настройке производительности RHEL 7 .
Большое спасибо Стивену Китту за напоминание о swapon и swapoff.