Не работает vm.swappiness

[Tonal]

Значит по мнению системы, ей больше не нужно памяти.

Вот можно ли повлиять на это "мнение системы" как-то кроме изменения swappiness?

Может в systemd есть какой-то дополнительный параметр, по аналогии с отключением свопа?

[ecc83]

Вот можно ли повлиять на это "мнение системы" как-то кроме изменения swappiness?

Разумеется можно. Нужно уменьшить кол-во оперативной памяти.
Чем меньше оперативной памяти, тем больше используется подкачка.

[EvangelionDeath]

Tonal, эх... вы...
Почему все считают, что swappiness это количество свободной ОЗУ, при которой начинае система сбрасывать данные в SWAP.
Начнем с того, что система никогда не сбросит в SWAP то, что активно использует (в wiki довольно упрощенная схема и так же написано, что при vm.swappiness может быть заметно сразу замедление работы системы). И именно может
В более полном варианте: каждый раз система делает оценку хранимым данным в ОЗУ - как давно они туда попали, как часто используются и куча других параметров. После чего применяются vm.swapiness, а если точнее высчитывется distress. И после уже вынесения всех оценок система будет сбрасывать SWAP.
Кроме vm.swapiness есть еще параметр vm.min_free_kbytes , который равен по умолчанию 64МиБ. Это как раз нижняя черта свободного количества ОЗУ при котором система таки будет свопить

[ecc83]

Впервые встречаю человека, который желает изменить приоритет использования оперативной памяти в пользу подкачки 

[Morisson]

Просто нужно знать, о чем говоришь, прежде чем советовать что-то изменить. И поменьше читать говноблогов.
Почему все стараются его уменьшить?
Вот как думаете, разработчики- глупые люди? И почему по-умолчанию он равен 60-ти?
И как правильно замеитили, этот самый параметр не определяет объем памяти.
Вот статья с переводом разработчика. Иногда лучше читать, чем говорить

[EvangelionDeath]

Tonal, а можете поподробней о файловаом кеше... и какое ПО вы все же запускаете.
А я вижу из той инфы, что вы предоставили, почти 5 ГБ - кешированые данные. И соответсвенно число free показывает сколько вообще памяти нераспределено, но при этом реально доступно 4,5ГиБ.
Попробую прояснить немножко, на пальцах, есть
 - active memory - память занятая активными процессами,
 - free - полностью свободная,
 - shared - память, что используется для нескольких процессов,
 - buffered - ну это ваши буферы обмена, кеш диска...,
 - cached - кеш
 - available - именно доступная.
Так вот
- cache используется для быстрого старта ПО которым вы пользуетесь часто (да, ядро умное и следит за вами), но в то же время сброс этой памяти в SWAP - сизифов труд (что читать с диска со SWAP, что читать файлы в память...) и если такая память надо - она просто освобождается (вытесняется) другим ПО.
- active/shared - занята активными процессами и не может быть вытеснена в SWAP из тех причин, что доступ к ней надо "здесь и сейчас"
- buffered - кеш диска сбрасывается по таймеру или при достижении определенного числа "грязных" страниц или % свободной ОЗУ

А потому, надо все же смотреть, что за ПО приводит к таким последствиям, что система не знает, какаю память переместить в своп. Ну и соответственно не передает данные ООМ киллеру за такой беспредел
Так же хочу уточнить, вы часом не "крутили" настройки самого дискового кеша?

И я тут копался в кое чем

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

> sysctl vm.swappiness
vm.swappiness = 10
> free -mh
              total        used        free      shared  buff/cache   available
Mem:           125G        3.0G         17G        8.7G        105G        112G
Swap:          8.0G         47M        8.0G


Так что 99% проблема в ПО (не в ОС) или битой ячейке памяти

[Tonal]

а можете поподробней о файловаом кеше... и какое ПО вы все же запускаете.

Настройки кеша не трогал.
Система - Neon с последними обновлениями на базе Kubuntu 16.04
Замерзания проявляются в следующих случаях:

• Отработка тестов тяжелого проекта на Python. py.test из под PyCharm. В штатном режиме проект жрёть от 800мб до 3-4гб похоже при тестах течёт память, поэтому к в районе 5-7го теста машина замерзает, если не успеть стопнуть.
• Запуск винды под Virtual Box для сборки и тестирования проекта C++ Qt5. Раньше виртуалке выделял 4гб и работал. Сейчас комп замерзает при старте такой машинки до ресета. Пришлось урезать до 2-3гб
• Пробовал гонять Vowpal Wabbit на больших данных. При размере данных 4гб и больше машина замерзает - правда иногда удаётся дождаться отмерзания
• Гонял некоторые модели на ScyPy на Jupiter notebook - тоже при некотором объеме исходных данных замерзает. И тоже иногда удаётся дождаться

Вот, провёл небольшой тестик:
Сейчас открыто несколько экземпляров Chrome + QtCreator

$ sysctl vm.swappiness
vm.swappiness = 100
$ free -hwm
              total        used        free      shared     buffers       cache   available
Память:         11G        6,4G        1,2G        203M        1,7M        4,0G        4,6G
Подкачка:        7,8G        288M        7,5G

Сейчас запустил VB с 3гб под виндой 7:

Код: [Выделить]

$ free -hwm
              total        used        free      shared     buffers       cache   available
Память:         11G        8,7G        1,2G        207M        960K        1,7G        2,2G
Подкачка:        7,8G        950M        6,9G
Сейчас подниму память виртуалки до 4гб, отчёт след. постом.
Пользователь добавил сообщение 04 Мая 2018, 08:58:19:

Код: [Выделить]

$ free -hwm
              total        used        free      shared     buffers       cache   available
Память:         11G        9,2G        132M        208M        1,1M        2,3G        1,7G
Подкачка:        7,8G        1,1G        6,7G
Похоже vm.swappiness = 100 таки сработал, машина не замёрзла.
Неделю назад, когда я запускал виртуалку с 4гб и vm.swappiness = 90 машина замёрзла на глухо...

[EvangelionDeath]

PyCharm

Эм, проэкт на Java. А среди девелоперов шутки ходят по поводу Java. Если для кого-то стандарты продакшн - это ох и ах, то для разработчиков Java и тех, кто использует продукты на Java - острая необходимость.

Суть такова, что и виртуалка и "тесты" относятся к активной памяти и их выгрузить проблематично.

Вам ОЗУ добавлять надо)

[ecc83]

Вам ОЗУ добавлять надо)

У автора ноутбук и есть предел памяти, которого он по видимому достиг.

[EvangelionDeath]

ecc83, да я знаю, что предел достигнут. соответсвенно надо вообще менять ноутбук, не зря был намек на продакшн. так как все контроллеры памяти ноутбучных камешков поддерживают меньшее количество ОЗУ чем их десктопные собратья. Так же это зависит и от поколения камешка. В мой ноутбук теоретически можно воткнуть 32ГиБ (2 слота по 16) DDR3 (такие есть, но и стоимость каждого выше чем 2х по . Но не суть, процессор поддерживает только 16 ГиБ...
А потому, смотреть процессор, что там за контроллер, искать память или смотреть на замену вообще ноутбука

[Tonal]

Эм, проэкт на Java

PyCharm сейчас самая лучшая среда для разработки на Python.
Альтернативы - Eclipse, Eric4, KDevelop, ActiveState Komodo - все сильно не дотягивают по возможностям и более прожорливые по памяти.

Суть такова, что и виртуалка и "тесты" относятся к активной памяти и их выгрузить проблематично.

Ну так и хочется чтобы при их запуске остальное, сейчас не используемое, было вытеснено.

Вам ОЗУ добавлять надо)

Надо. Есть в планах купить новую машинку - в этой максимум 16гб, но 4 на маме распаяно. Так что стоит максимум - 12гб

Код: [Выделить]

$ lshw
hius2                     
    описание: Ноутбук
    продукт: X751LJ (ASUS-NotebookSKU)
    производитель: ASUSTeK COMPUTER INC.
    версия: 1.0
...
$ sudo dmidecode --type memory
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x0013, DMI type 16, 23 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: None
        Maximum Capacity: 16 GB
        Error Information Handle: Not Provided
        Number Of Devices: 2


[AnrDaemon]

сейчас не используемое

"Остальное" тоже "сейчас используется". И его тоже выгрузить проблематично.

[Tonal]

У меня пока для этих ситуаций сложилось следующая экибана:
vm.swappiness = 100 + Alt+SysRq+F (ручной oom-killer)

Так что жить, до смены железа можно.
Пользователь добавил сообщение 05 Мая 2018, 10:44:27:Что смущает, так это то, что до нового года таких проблем точно не было - гонял я виртуалки с 4гб, тяжелые тесты и расчёты, не особо задумываясь о памяти и параметрах ядра.
На больших объёмах начинало подтормаживать, но всё в пределах ожидаемого.
Замерзаний на минуты точно не было.

А вот где-то после нового года начались подвисания.
Меня терзают смутные сомнения, что это связано с борьбой с дырами в процах, которая как раз в январе развернулась...