cache-bench 0.2.0 — инструмент для исследования эффективности кэширования файлов

Предыдущая новость: Выпуск r-test v0.1.0 -- инструмента для исследования эффективности кэширования файлов при нехватке памяти

cache-bench - это форк r-test. r-test не будет развиваться.

Python

надо было на раст писать сразу?

На JS же :)

Нашёл к чему придраться. А надо было на чём писать? Чем плох питон для написания маленьких тестовых утилит? Какая вообще разница на чём это написано, да хоть на bash, в данном случае язык абсолютно неважен, на чём ему удобно было, на том и написал, питон у всех в дистрибутиве есть.

у Iron_Bug нет питона в ее войде.

Вообще не понятно, что этот скрипт делает. Он тестирует скорость чтения-записи дискового устройства?

Это не придирка, а троллинг.

Благодарю за разъяснение, капитан. У нас с вами разное к этому явлению отношение, я помню.

Скорость чтения. Она зависит от степени кэширования файла. Кэшированный файл читается со скоростью гигабайты в секунду, некэшированный - мегабайты или десятки мегабайт в секунду в зависимости от размера чанка и скорости диска.

На кэширование (особенно при нехватке памяти) влияют различные факторы: vm.swappiness, vm.watermark_scale_factor etc. например, при нехватке памяти при низком swappiness кэш будет легко удаляться из памяти для предотвращения своппинга, вследствие чего производительность чтения резко падает. Например, начало нехватки памяти и начало своппинга при swappiness=100:

$ cache-bench -r 15000 -i 4 -b 1 -p 1
starting cache-bench
  file: testfile.bench
  file size: 300.0 MiB
  log file is not set
  output interval: 4.0s
  mmap: 0, preread: 1, bloat: 1, chunk: 64 KiB
prereading (caching) the file...
  preread 300.0 MiB (100.0%) in 2.6s
reading 15000.0 MiB from the file...
  read 7042.6M in 4.0s (1760.7M/s); total 7042.6M in 4.0s, avg 1760.7M/s
  read 3541.1M in 4.0s (884.7M/s); total 10583.7M in 8.0s, avg 1322.5M/s
  read 68.6M in 4.0s (17.1M/s); total 10652.4M in 12.0s, avg 886.8M/s
  read 46.1M in 4.0s (11.5M/s); total 10698.4M in 16.0s, avg 667.8M/s
  read 51.3M in 4.0s (12.8M/s); total 10749.7M in 20.0s, avg 536.7M/s
  read 55.8M in 4.0s (13.9M/s); total 10805.5M in 24.0s, avg 449.6M/s

– сначала чтение из кэша идет быстро, потом резко замедляется. Такого замедления можно избежать при swappiness=200.

Конечно, можно и скорость чтения с устройства измерять, наблюдая влияние размера чанка на скорость чтения, когда файл еще не попал в кэш.

С другой строны, можно наблюдать влияние продолжительного чтения из большого файла на начало своппинга. При интенсивном чтении своппинг заметен даже при небольших значениях swappiness.

Также --mmap опция особенно полезна при изучении эффектов Multigenerational LRU Framework: с ним кэш mmapped файлов получает усиленную защиту и с трудом вытесняется при нехватке памяти.

Ого! Не ожидал такой развёрнутый ответ! Теперь стало понятно. Спасибо!

Такого замедления можно избежать при swappiness=200.

Этого значения я не совсем понимаю, поскольку информация по этому параметру указывает на значение в процентах. Может быть значение 20, а не 200? У себя на десктопе я вообще 10 выставил, но на сервере 20 наверное лучше.

Этого значения я не совсем понимаю, поскольку информация по этому параметру указывает на значение в процентах.

swappiness

This control is used to define the rough relative IO cost of swapping and filesystem paging, as a value between 0 and 200. At 100, the VM assumes equal IO cost and will thus apply memory pressure to the page cache and swap-backed pages equally; lower values signify more expensive swap IO, higher values indicates cheaper.

Keep in mind that filesystem IO patterns under memory pressure tend to be more efficient than swap's random IO. An optimal value will require experimentation and will also be workload-dependent.

The default value is 60.

For in-memory swap, like zram or zswap, as well as hybrid setups that have swap on faster devices than the filesystem, values beyond 100 can be considered. For example, if the random IO against the swap device is on average 2x faster than IO from the filesystem, swappiness should be 133 (x + 2x = 200, 2x = 133.33).

At 0, the kernel will not initiate swap until the amount of free and file-backed pages is less than the high watermark in a zone.

https://github.com/torvalds/linux/blob/v5.15/Documentation/admin-guide/sysctl/vm.rst#swappiness

Где там сказано про проценты?

Может быть значение 20, а не 200?

Нет, именно 200. swappiness - это не проценты. 200 можно ставить начиная с ядра 5.8 (емнип).

на сервере 20 наверное лучше

Смотря какая нагрузка, смотря какое устройство используется в качестве пространства подкачки. С быстрыми устройствами (типа zram) можно swappiness выше ставить.

См также https://habr.com/ru/company/flant/blog/348324/

У себя на десктопе я вообще 10 выставил

С такими настройками при быстрой утечке памяти ваш гуй повиснет как хусейн.

Где там сказано про проценты?

Значения от 0 до 100 можно интерпретировать как проценты. А взял я это из википедии Арча 😀:

Swappiness может иметь значение от 0 до 100

Но в Инглишь версии поправили документацию и там сейчас указано:

Swappiness can have a value between 0 and 200 (max 100 if Linux < 5.8)

А вообще на огромном количестве ресурсов, когда я этим интересовался, была информация о значениях только от 0 до 100. Конечно, можно сказать, что я тупой, хожу по каким-то сомнительным сайтам, но не выходят в топе поиска гугла источники, а новичку вообще сложно понять, что там Линус пишет )) Так что.. учился я как мог )) Извиняйте.

Вот эта цитата, вообще с толку сбивает и мне не понятно как это вообще обмозговать и понять:

lower values signify more expensive swap IO, higher values indicates cheaper.

Тогда как в той же Arch документации указано:

Using a low value on sufficient memory is known to improve responsiveness on many systems.

А вы говорите:

ваш гуй повиснет как хусейн.

Наоборот, он сейчас «летает», 90% ОЗУ используется по назначению и SWAP пустой при таком значении. А вот если ОЗУ (Application Memory) будет выходить за пределы использования выше 90, то начнёт активно свопится, и вот тут Гуй действительно начнёт тормозить.

См также https://habr.com/ru/company/flant/blog/348324/

Спасибо за ссылку! Изучу когда время найду.

если ОЗУ (Application Memory) будет выходить за пределы использования выше 90, то начнёт активно свопится

Cвопиться может и при 10% swappiness, а можно иметь и пустой своп при swappiness=200 - это зависит от рабочей нагрузки.

swappiness - это не процент от памяти, а фактор, влияющий на баланс файловой (кэша диска) и анонимной памяти (памяти приложений) при нехватке памяти. Он регулирут то, какую память удалять или свопить при нехватке.

Можно иметь хорошую отзывчивость под стрессом при swappiness=200, рузультат может быть таким: https://www.youtube.com/watch?v=g9GCmp-7WXw - с низким своппинес в такой ситуации гуй виснет.

Да, Гуй при swappiness=10 всё-таки тормозит, но только тогда, когда начинает активно свопится, а свопится по моим тестам как раз начинается тогда, когда значение Used Memory приближается к 90% всей памяти. Поэтому связав всё что происходит во едино, легко представить, что это грубо говоря остаток процентов от доступной памяти, порог при котором начинает активно работать своппинг. Но видимо это не так, как я так думал, и думали другие на информационных ресурсах откуда я «выдумал» этот процентаж.

К сожалению я не могу понять лучше как этот параметр работает как-то иначе. При высоких значениях у меня начинает свопится ещё до того, как используется большая часть свободного RAM, и это влияет на тормоза Гуя. Мне непонятно, зачем свопить, когда Used Memory примерно на 10-50%. Зачем тогда вообще ОЗУ нужна в таком случае? ))

В моём случае, очень редко что либо свопится, так как обычно ОЗУ в ПК достаточно для всех моих приложений, что я использую. Своп я настроил, для исключительных ситуаций. Разработчики Блендера ошибаются время от времени и могут использовать некорректно Image Buffers и использование ими RAM в разные периоды времени разработки могут умножать использование кратно пока не исправят проблему с потреблением. Поэтому, я настроил своп, чтобы дать запас Системе не киллить приложение при длительных рендерах, чтобы не потерять многочасовой результат, когда оно начинает потреблять ОЗУ выше чем обычно. При этом, мне не нужно чтобы своппинг тормозил Гуй ещё до того, как большая часть ОЗУ будет использована. Отсюда и параметр swappiness я выставил равным 10.

Что произойдёт, если я выставлю параметр swappiness=200?

Кстати, почитал я на досуге про SWAP по ссылке которую Вы мне дали. Это мрак конечно, перевод - машинный, если кто и правил после робота, то немного. Читать такое нужно запрещать или блокировать вообще )))

Пример:

высвобождение анонимных страниц «невозможно», поскольку анонимные страницы по своей природе не имеют резервного хранилища, к которому можно обратиться при удалении данных из памяти, — таким образом, их высвобождение приведёт к полной утере данных из соответствующих страниц.

Еще раз:

их высвобождение

Куда высвобождение!!?? В Swap?

Оказывается, нужно заменить этот глагол на УДАЛЕНИЕ, тогда становится всё понятно, потому что высвобождение, это скорее перемещение, а если так, то почему данные будут утеряны? И таких «ляпов» в статье очень много. В оригинале читать наверное лучше.

reclaim - страницы становятся свободными для дальнейшего использования. page frame сможет быть занят новым содержимым. Это высвобождение. Перевод неплохой, по-моему.

нужно заменить этот глагол на УДАЛЕНИЕ

reaclaim - это освобождение page frame для дальнейшего использования. Занятые страницы превращаются в свободные.

глава по теме https://www.kernel.org/doc/gorman/html/understand/understand013.html

Куда высвобождение!!?? В Swap?

Общее число страниц обычно остается неизменным. Восстановление страницы - это превращение анонимной или страницы файл кэша в свободную. Содержимое анонимной страницы улетает в своп, при этм сам page frame освобождается (reclaim):

Chapter 10  Page Frame Reclamation

A running system will eventually use all available page frames for purposes like disk buffers, dentries, inode entries, process pages and so on. Linux needs to select old pages which can be freed and invalidated for new uses before physical memory is exhausted.

https://www.kernel.org/doc/gorman/html/understand/understand013.html

Свободные страницы - это тоже страницы. Страницы при reclaim не удаляются, а освобождаются, то есть из занятых превращаются в свободные. Поэтому «восстановление» - вполне корректный перевод.

В оригинале читать наверное лучше.

Кто ж запрещает? https://chrisdown.name/2018/01/02/in-defence-of-swap.html

Автор там ссылается на гораздо более худший перевод: https://chrisdown.name/2018/01/02/in-defence-of-swap.html

Вы можете добиться лучшего поведения подкачки под давлением памяти и предотвратить "молочницу" с помощью memory.low и друзей в cgroup v2.
...
В этих дискуссиях неоднократно повторялась тема обмена мнениями. Обмен - это горячо оспариваемая и плохо понимаемая тема, даже теми, кто работает с Linux много лет.

thrashing - это «молочница», swap - обмен мнениями. Как вам такое?

их высвобождение

Скажите еще спасибо, что не «мелиорация» или «рекультивация».

Page Frame Reclamation - варианты перевода от deepl.com:

• Страничная рамка Мелиорация

• Страничная рамка Рекультивация

• Мелиорация рамы страницы

Автор там ссылается на гораздо более худший перевод:

это https://web.archive.org/web/20200924111107/https://softdroid.net/v-zashchitu-svopa-rasprostranennye-zabluzhdeniya

Что произойдёт, если я выставлю параметр swappiness=200?

Сначала ничего. При чтении (кэшировании) больших объемов с диска, когда свободная память опустится до минимума, вместо удаления кэша получите своппинг (при восстановлении страниц будет отдаваться предпочтение анонимным страницам, а не файловым).