LINUX.ORG.RU

Экономия оперативки и ограничения страничного кэша для отдельных приложений

 ,


0

1

Здравствуйте,

Я хочу поговорить о страничном кэше с занудной бухгалтерией байтиков и электричества.

У меня есть десктоп, который запускает обычные десктопьи приложения и ещё раздаёт торренты. Постоянное чтение файлов, раздаваемых через торрент, тянет их в страничный кэш /page cache/, но hit rate у этого кэша заведомо стремится к 0, а ресурсы заняты зазря.

В системе 16 ГБ оперативки, приложениями обычно занято не более 4-6 ГБ. Но с забитым под завязку кэшем система аж swap выдавливает, вот картинка за неделю.

С 12 января я попробовал запускать торрент-клиент через nocache и терапевтический эффект минимальный: на пару гигабайт свободнее. Тем не менее, раздаваемых через файлов в кэше полно:

 → find ./torrent/ -type f -exec cachestats {} \; | awk -F'[ /]' '{s+=$4} END {printf("%d pages in cache * 4K\n",s)}'

2235489 pages in cache * 4K

2235489 * 4 / 1024^2 = 8.53 ГБ оперативки под мусор.

Есть ли способ органичить страничный кэш для отдельного тома или приложения? Я только за, чтобы в кэше были нужные файлы, и не хочу крутить глобальный vfs_cache_pressure, но вот лишнее держать — сомневаюсь.

А стоит ли вообще внимания эта возня? Или всё это экономия на спичках и ядру самому виднее, что куда класть?



Последнее исправление: emmawatsondtypants (всего исправлений: 2)

Там в комплекте с nocache идёт утилита cachedel, может лучше её вызывать для всех файлов из каталога torrent/, nocache какой-то навороченный, он пытается не кешировать только новые страницы файла. Может у вас файлы попадают в кеш из-за их чтения другим процессом (не торрентом).

При чём здесь электричество я не понял, на десктопах же «пустая» память потреблят столько же.

mky ★★★★★
()

https://www.libtorrent.org/reference-Settings.html#disk_io_write_mode

disable_os_cache

This opens all files in no-cache mode. This corresponds to the OS not letting blocks for the files linger in the cache. This makes sense in order to avoid the bittorrent client to potentially evict all other processes’ cache by simply handling high throughput and large files. If libtorrent’s read cache is disabled, enabling this may reduce performance.

One reason to disable caching is that it may help the operating system from growing its file cache indefinitely.

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

Спасибо! Казалось бы, то что нужно.

Установил для libtorrent
disk_io_write_mode = 2
disk_io_cache_mode = 2
(оказалось, что для моего Deluge есть https://github.com/ratanakvlun/deluge-ltconfig/releases и даже городить костыли не пришлось).

Применяется корректно, но всё равно мразь в кэш тащит! Никакой разницы.

Пока засунул клиента в оградку cgroups c memory.limit_in_bytes. То ли баг, то ли фича, но кэш так же считается за память и за пределы не вылазит. Через systemd просто параметром MemoryMax.

Терапевтический эффект есть.

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

Просто к слову: для меня как-то было откровением, что значительная часть тепла в компьютере не от сопротивления рассыпухи, а как есть — рассеянная в тепло информация, стёртая из емкостной памяти :-)

А cachedel смысла не имеет, по-моему: с условным терабайтом данных кэш до 16 ГБ выбирается мгновенно, теребить дороже.

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

А стоит ли вообще внимания эта возня? Или всё это экономия на спичках и ядру самому виднее, что куда класть?

Да. Во-первых, в свопе совсем немного. Во-вторых, если своп на zram, то тем более вряд ли будет ощутимо. Все равно в своп падает Inactive Anon.

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