LINUX.ORG.RU

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

 , ,


0

1

r-test - это Python скрипт, позволяющий оценить влияние настроек виртуальной памяти (vm.swappiness, vm.watermark_scale_factor, Multigenerational LRU Framework и прочих) на производительность выполнения задач, выполнение которых зависит от кэширования файловых операций в условиях нехватки памяти. Код открыт под лицензией CC0.

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

Имеет два режима работы. Первый - вспомогательный - служит для создания директории заданного объема. При этом в директории создается заданное число мебибайтных файлов со случайными именами.

Второй режим - основной - режим чтения файлов из указанной директории в случайном порядке. Во время чтения растет объем потребляемой скриптом памяти, а скорость считывания заданного объема файлов зависит от объема кэшированных файловых страниц.

Частью проекта также является вспомогательных скрипт drop-cache, который рекомендуется выполнять перед началом теста.

В процессе работы скрипта в режиме чтения выводится общее время работы, средняя скорость чтения, имя последнего считанного файла.

Скрипт также позволяет логировать результаты в файл. Пример лога:

2021-05-30 21:47:56,084: mkdir testdir1
2021-05-30 21:47:56,211: written testdir1/0.9860985015646311; total size: 1M
2021-05-30 21:47:56,289: written testdir1/0.0691916965192153; total size: 2M
2021-05-30 21:47:56,377: written testdir1/0.27868153831296383; total size: 3M
2021-05-30 21:47:56,455: written testdir1/0.7341114648416274; total size: 4M
2021-05-30 21:47:56,533: written testdir1/0.5363495159203434; total size: 5M
2021-05-30 21:47:56,533: OK
2021-05-30 21:48:23,193: found 5 regular files in testdir1, total size: 5.0M
2021-05-30 21:48:23,199: setting self oom_score_adj=1000
2021-05-30 21:48:23,199: reading files from the directory testdir1
2021-05-30 21:48:23,229: read 1.0M (20.0%) in 0.0s (avg 32.9M/s); file 0.7341114648416274
2021-05-30 21:48:23,296: read 2.0M (40.0%) in 0.1s (avg 20.8M/s); file 0.0691916965192153
2021-05-30 21:48:23,298: read 3.0M (60.0%) in 0.1s (avg 30.3M/s); file 0.0691916965192153
2021-05-30 21:48:23,299: read 4.0M (80.0%) in 0.1s (avg 40.1M/s); file 0.7341114648416274
2021-05-30 21:48:23,352: read 5.0M (100.0%) in 0.2s (avg 32.6M/s); file 0.27868153831296383
2021-05-30 21:48:23,353: --
2021-05-30 21:48:23,353: read 5.0M in 0.2s (avg 32.6M/s); src: 5 files, 5.0M
2021-05-30 21:48:23,354: OK

>>> Подробности

★★

Проверено: Shaman007 ()

С помощью этого инструмента установлено, например, что Multigenerational LRU Framework, недавно опубликованный гуглом, не вполне корректно работает со swappiness, точнее то, что swappiness (от 1 до 200) очень слабо влияет на результат, в отличие от тестов с применением классического LRU.

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

По теме свопа традиционно рекомендуется классика https://chrisdown.name/2018/01/02/in-defence-of-swap.html

достоверность инфы должна подтверждаться избыточностью

Избыточность ни о чем не говорит. Если один дурак ляпнет ерунду, и ее повторят еще 10 - ерунда не станет истиной.

Спрашивай тут конкретные вопросы, если есть.

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

спасибо за новость

Не за что.

посещать лор (в качестве дежурного комьюнити ИТ специалистов) больше нет смысла

Что-то не так с новостью? Или эта новость настолько преисполнила вас мудростью, что больше нет нужды в новостях и комьюнити?

anonymous ()

read копирует данные из кеша в процесс. В процессе для этого должен быть обычно приватный анонимный мапинг. Может добавить режим работы без копирования и приватных мапингов? Просто mmap-ить файлы в процесс с MAP_SHARED|MAP_POPULATE вместо их чтения?

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

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

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

Угадал автора по заголовку :)

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

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

что за грязного кэша? Вообще я не совсем понимаю в чем проблема с oom в федоре. Я 3 раза прогонял этот тест с различными параметрами каждый раз oom убивал мне иксы полностью, но система оставалась рабочей. У кого по другому? Хотелось бы услышать о чем шла в прошлом речь

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

не совсем понимаю в чем проблема с oom в федоре

см systemd-oomd убьет вашу сессию (внимание пользователям спинов Fedora 34)

Я 3 раза прогонял этот тест с различными параметрами

Требуется конкретика: c какими именно параметрами -r и -w, сколько у тебя памяти и свопа, своп на zram? система на BTRFS со сжатием?

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

Какое DE используешь? Вероятно systemd-oomd работает так, вместо убийства одного процесса-виновника (r-test запускается с oom_score_adj=1000) убивает сессию. Но разрабам федоры пофиг.

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

У кого по другому?

Делаешь большой своп на zram, выставляешь высокий swappiness (до 200), выключаешь systemd-oomd (или заменяешь его на earlyoom или nohang-desktop), подбираешь размер -r, который приведет к заполнению значительной части свопа, но не всего свопа, ибо ООМ нам не нужен. Получаешь нормальный результат. Можешь повторять тест, играя, например, со swappiness. C понижением swappiness обычно время выполнения увеличивается.

С BTRFS со сжатием результат может значительно отличаться, ибо r-test генерирует пустые файлы.

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

Было бы здорово то же самое, только не для " в условиях нехватки памяти. ", а для стандартной ситуации.

Запускаешь такой, он рилтайм бенчит и туда сюда гоняет, одновременно меняет разные параметры vm. Потом тебе такой - «Вот лучший результат».

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

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

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

Потом тебе такой - «Вот лучший результат»

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

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

так что единый для всех рабочих нагрузок результат вряд ли возможен.

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

Смысл в том, что бы их измерять, изменяя при этом параметры vm. ядра, и найти лучшие показатели. Это как раз будет инструмент для определения индивидуального «лучшего» результата.

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

Это лишь предположение. В одном из тредов, у тебя были «демки» на ютубе, ты там перетаскивал окна при 80% загруженной памяти+своп.

Возникает такой эффект «медленных» анимаций, когда изображение не «дёргается», но и уже не такое плавное как раньше. Так вот, такой эффект возникает и при том, что память свободная ещё осталась.

При этом этот эффект возникает именно при активной загрузки памяти, чем больше (~50-60%+), тем сильнее он выражается. Наблюдается на разных писюнах, с разным железом. В ЦП не упирается, в i\o тоже (sdd, nvme).

Косвенно всё это ощущается, как именно хреновая работа с памятью. Возможно конечно, что кривой gl-беккенд, вся эта херня типа gallium. Опять же, пока память не загружена это не проявляется, и я не знаю насколько интенсивно gl-драйвера взаимодействуют с ram.

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