LINUX.ORG.RU

Автосброс свапа

 


0

1

8 гб памяти катастрофически не хватает, поэтому ноут постоянно выходит в свап, из-за этого наблюдаются микро лаги, которые раздражают и отвлекают. Проблема заключается в том, что когда память освобождается, система не торопится перемещать ресурсы из файла подкачки. Решается проблема самописным скриптом, который делает swapoff -a && swapon -a и отображает прогресс бар по ходу процесса.

Можно ли что-то сделать, чтобы свап чистился автоматически при освобождении памяти и есть ли вообще в этом смысл?


Так выставь параметр swapiness http://fx-files.ru/archives/704

В убунте он вроде 30 по дефолту (то бишь когда памяти остается 30%, он начинается свопиться). Выставь где-то 5 и будет то, что тебе хочется.

nikolnik ★★★
()
Последнее исправление: nikolnik (всего исправлений: 1)

zswap.enabled=1 к параметрам ядра добавь, чтобы данные вытеснялись в сжимаемый кэш, а на диск в крайнем случае только.

Radjah ★★★★★
()
Ответ на: комментарий от Radjah

zswap is a compressed RAM cache for swap devices. Pages which would otherwise be swapped out to disk will instead be compressed and maintained in RAM until RAM is exhausted, after which the least recently used (LRU) pages will be sent to disk.

Так если страницы свапаются, когда RAM на исходе, куда zswap будет их писать? Получается же сразу на диск.

Anvill
() автор топика
Ответ на: комментарий от Anvill

$ cat /proc/sys/vm/swappiness

10

Из-за этого и лаги. Верни дефолтное значение - 60. А потом и zswap можно будет побаловаться.

anonymous
()

Лучше пнуть важные приложения чтобы они вернулись в озу, а мусор пусть остаётся в свапе.

anonymous
()
Ответ на: комментарий от Anvill

Хуже. Гугл хром

Для гуглохрома не хватает 8гб ОЗУ? Дай угадаю, у тебя там 100500 вкладок открыто, и все они тебе нужны?

djoe ★★★
()
Ответ на: комментарий от Anvill

Так если страницы свапаются, когда RAM на исходе, куда zswap будет их писать? Получается же сразу на диск.

Wrong. Страницы жмутся, и таким образом часть страниц становится свободной. Если и это не помогает, только тогда страницы уходят на устройство подкачки.

Сразу два плюса:

  • Там, где без zswap ты «немного засвопишься», с ним система обойдётся без дискового ввода-вывода вовсе.
  • Там, где без zswap ты «сильно засвопишься», с ним система будет гонять на ввода-вывода сжатые данные, и задержки будут меньше.

Это в теории. Сам на практике не юзал.

Deleted
()
Ответ на: комментарий от djoe
  • После ребута: ~1.5-2G занято
  • Хром ~15 вкладок: ~2G
  • Idea: 1G + съедает ещё в периоды активности
  • VSCode (бывает запускаю до 3-ех инстансов): 1-1.5G

Докер контейнеры, компиляторы могут много сжирать периодически, ну и по мелочи ещё набегает.

Anvill
() автор топика

Доставать из свопа неиспользуемые данные смысла нет. А хром все равно тормозить будет, т.к. у него кэш на диске, что примерно так же бьет по производительности как своп.

anonymous
()
Ответ на: комментарий от Deleted

Это откладывает проблему, но не решает её. Сжатие, по-сути, просто увеличивает объем доступной памяти. Ну допустим за счет сжатия получим выигрыш в ~10%, но в итоге всё всё равно улетает на диск. И здесь сразу же минус такого подхода выявляется: если без zswap при обращении к странице производилась io операция, то с ним будет io + декомпрессия.

Попробую конечно, но я всё ещё в поиске механизма для автоматического освобождения свопа. Ещё попробую сделать два свап файла: первый на ssd, второй на hdd — если памяти не хватает чуть-чуть, то задействуется «бстрый» файл на ssd, а когда всё плохо, то пишем на хард; сейчас один файл на hdd.

Кстати, получается для zswap нужно vm.swappiness побольше поставить, чтобы он мог больше страниц в итоге насжимать без ухода в io?

Anvill
() автор топика
Ответ на: комментарий от Anvill

Ну допустим за счет сжатия получим выигрыш в ~10%

Обещают до 50%.

Я, правда, использую не zswap, а zram + swapon на виртуальное блочное устройство. Это действительно помогает уменьшить лаги при нехватки памяти.

Это откладывает проблему, но не решает её.

Это да. Но средства упреждающего засасывание свопа обратно в память мне тоже не известны.

Deleted
()
Ответ на: комментарий от anonymous

В свопе оказываются как раз актуальные данные. Смотри: допустим в момент времени занято 80% RAM, тут идея решает посчитать какой-нибудь важный индекс, и, естественно, он не влезает и уходит на диск, в ближайшем времени идея будет часто обращаться к этому индексу, чем вызывать микро лаги. (Не уверен, реализован ли в ядре механизм LRU, чтобы на диск уходили страницы, к которым происходит редкое обращения, но по моим эмпирическим наблюдениям нет)

Хром как раз не тормозит (по крайней мере, когда памяти хватает). $HOME со всеми конфигами и кэшами лежит на ssd, поэтому обращение к нему не так критично — пускай себе хранит кэш на диске. Тормозит idea, и система в общем в моменты переключения окон и активностей (вкладок, открытый файл, навигация по файлу)

Anvill
() автор топика
Ответ на: комментарий от Deleted

Обещают до 50%.

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

$ stat 19386-7fcd85c3a000-7fcd8643a000.dump | rg -i size
2:  Size: 8388608       Blocks: 16384      IO Block: 4096   regular file
$ lzop 19386-7fcd85c3a000-7fcd8643a000.dump
$ stat 19386-7fcd85c3a000-7fcd8643a000.dump.lzo | rg -i size
2:  Size: 40623         Blocks: 80         IO Block: 4096   regular file
$ lzop -d 19386-7fcd85c3a000-7fcd8643a000.dump.lzo -o 19386-7fcd85c3a000-7fcd8643a000.dump.2
$ md5 19386-7fcd85c3a000-7fcd8643a000.dump*
7de7371984380785883c9fc738ee2177  19386-7fcd85c3a000-7fcd8643a000.dump
7de7371984380785883c9fc738ee2177  19386-7fcd85c3a000-7fcd8643a000.dump.2
9bef30ca0b8e03152d3d990c745253fa  19386-7fcd85c3a000-7fcd8643a000.dump.lzo
vadim@vadim-K56CB /t/workdir-0207-0940-memdump> 

Хотя скорее всего просто удачно попал в какой-нибудь однородный массив, но возможно обещания не голословны — надо будет потестить

Anvill
() автор топика
Ответ на: комментарий от Anvill

А вот так, если сжимать все страницы процесса целиком:

$ tar cf dump.tar 193*
$ ll dump.tar | awk '{print $5}'
212M
$ lzop dump.tar
$ ll dump.tar.lzo | awk '{print $5}'
28M

Anvill
() автор топика
Ответ на: комментарий от Anvill

и виноватым во всей этой котовасии, естественно, оказался хром :)

djoe ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.