LINUX.ORG.RU

Zram vs Zswap. Часть 2: тесты

 , ,


2

2

Чтобы закрыть оставшиеся вопросы, я провёл серию тестов на скорость и отзывчивость по симуляции сёрфинга с фоновой нагрузкой.

Железо:

  • ноутбук HP pavilion dv5
  • Оперативная память 2Гб
  • Цпу: двухядерный pentium duo (core2), ограниченный до 65 градусов через cpufreqd
  • Видеокарта nvidia 9200M 256M видеопамяти, драйвер nouveau
  • Дистрибутив дебиан10, ядро 4.19
  • накопитель ssd

После загрузки запускаю:
Virtualbox (256М оперативки, ХР, пустой рабочий стол), firefox, пара консолек. В стартовой позиции занято 1,1Гб памяти.

Затем запускаю скрипт с тестовым сценарием:

  • На первом этапе открывается 5 вкладок через небольшие промежутки времени (5-7с) чтобы быстро добраться до начала свопинга.
  • Затем запускается Unigine Tropics (на минималках разумеется) в качестве индикатора отзывчивости системы и для фоновой нагрузки. Даётся задержка 40с для подгрузки оставшихся вкладок и собственно Tropics.
  • Начинает открываться второй пакет вкладок, 19 штук с промежутками 16с. Тестовый пакет - различные новостные ленты, не повторяжщиеся.
  • В момент появления первой из них я запускаю 'benchmark' в Tropics. Нагрузка упирается в цпу, браузер начинает захлёбываться и не успевает отрисовывать вкладки. Необходимость одновременно с этим свопиться определённо замедляет его и при этом дополнительно просаживает фпс в Tropics. Так как все прочие условия и настройки одинаковы, разница в тестах зависит от разных настроек свопинга.
  • Tropics заканчивает свой бенчмарк первыми и выдаёт результат, но продолжает рисовать остров, не сбрасывает нагрузки и я его не трогаю.
  • Окончание отрисовки пакета вкладок считаю по появлению ямы в графике нагрузки цпу (это происходит через ~5-10с после того, как firefox объявляет все вкладки загруженными). Время теста замеряется секундомером на смартфоне от запуска скрипта до повяления ямы на графике.

И последний тест, на пролистывание всех отрисованных вкладок.
Окно firefox на весь экран, Tropics остаётся в фоне, для каждой вкладки я жду подгрузки картинки, даю команду «end» (с плавной прокруткой), жду подгрузки, потом «home», подгрузка, ctrl-W для закрытия. Время теста также по секундомеру.

Серия тестов:
1) простой свопинг
2) zswap 25% z3fold/lzo
3) zswap 25% zbud/lzo
4) zram/lzo, backing_dev на ssd, mem_limit=450M

Результаты:

Unigine Tropics
Без дополнительной нагрузки:
результат 205, фпс мин/средн/макс 5,2/8,1/20,5
1) результат 162 фпс 3,1 / 6,4 / 19,4
2) результат 170 фпс 4,0 / 6,7 / 16,0
3) результат 168 фпс 3,4 / 6,7 / 16,5
4) результат 168 фпс 3,8 / 6,7 / 12,7
Здесь лучшую отзывчивость показал zswap/z3fold, а все 3 ускорителя явно лучше чем прямой свопинг.

Открытие вкладок
1) 7:33
2) 7:10
3) 7:26
4) 7:07
Zram победил, zswap/z3fold дышит в спину, zswap/zbud почти ничего не даёт.

Закрытие вкладок
1) 2:43
2) 2:49
3) 2:54
4) 2:42
Этот тест наиболее субъективный и менее точный. Со своей стороны могу заметить, что вариант zram показался мне самым отзывчивым и быстрым при поднятии из свопа.

Дополнение

Суммарный sleep в тестовом скрипте: 6:04 (Что более-менее оправдано в серии тестов 1-4. Держит загрузку цпу (все ядра суммарно) в районе 75...150% большую часть времени, за исключением пика до 200...300% на последних вкладках)

Если проходить тест открытия вкладок не допуская свопинга, т.е. пролистывая и закрывая вкладки, тогда:
Без всех утяжелителей: 6:21
С фоновым Unigine Tropics: 6:37 (tropics 181 фпс 4,3/7,2/19,1)

Вывод: Если вычесть это время (что 6:04, что 6:37), получается довольно заметая разница в 19 секунд из 56...89 (как считать).

И... Вернёмся к истокам, своп на HDD (80Гб, 720rpm, 8М), подключенном через usb 2.0!

5) Методика тестирования прежняя, zswap/z3fold 25%, lzo.
tropics 181 фпс 4,3/7,2/19,1
открытие: 7:21
закрытие: 2:53
При этом диск практически простаивает пока в свопе не окажется ~1,3-1,4Гб. Потом начинает активно использоваться.

6) Отключаю zswap, методика прежняя. Приблизительно те же самые показатели до 6-й минуты, когда Tropics заканчивает бенчмарк. И тут я трогаю мышку и навожу её на окно Tropics... Мышка просыпается, Kwin просыпается, konsole просыпается, firefox продолжает пережёвывать вкладки, система уходит в своп-трашинг. Я смотрю на это мунуту и решаю прервать тест. 15 МИНУТ НА ПРЕРЫВАНИЕ ТЕСТА И РЕБУТ!

Меняю методику тестирования. При прохождении тестов на ssd я мог без ограничений переключать окна и разворачивать список вкладок, без тормозов и задержек. Теперь я делают то же самое в поцессе теста на HDD. Без особо активных попыток вызвать своп-трэшинг.
tropics 175 фпс 3,3/6,9/20,6
открытие: 13:32
закрытие: 8:08

7) Повторяю тест HDD+zswap/z3fold, но специально провоцирую своп-трэшинг, тыкаю в окна, переключаю вкладки в пределах последних 4.
tropics 170 фпс 3,2/6.7/14,6
открытие: 8:40
закрытие: 2:45

Вывод: Ускорители свопа однозначно совершили революцию. Только мы её не видим, потому что на ssd разницы не заметно.

★★★★★

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

Ответ на: комментарий от LINUX-ORG-RU

Ну, вот визуально облегчил результаты, но не представляю что сделать с портянкой описания тестирования. От переразбивки абзацев принципиально ничего не изменится, а тег cut не работает.

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

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

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

Аааа, LORCODE. Ну ладн. Но вот сейчас хорошо всё. Я это и имел в виду не текст, а просто красивость. А текст, как это не важно, всё что написано всё важно это и станет предметом обсуждения. Ну да ладно.

LINUX-ORG-RU ★★★★★ ()
Ответ на: комментарий от kirill_rrr

Я не могу поменять разметку на маркдаун.

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

а загнать под какой нибудь спойлер

Сейчас витрина статей верстается так, что под спойлер загонять приходится весь текст статьи, кроме краткой аннотации.

hobbit ★★★★★ ()

ядро 4.19

А вот если бы стояло ядро 6.1.2+, то цифры отзывчивости выросли. ) Но я это уже комментил в первой статье.

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

У меня есть ощущение, что с бесконечным объёмом памяти там было бы 6:30. К сожалению память не бесконечна и проверить предположение не могу.

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

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Увеличь DISKSIZE до 3:1 к RAM вот тебе и «бесконечным объёмом памяти». )

И zstd желательно вместо lzo. Но здесь смотреть, конечно, как pentium отреагирует.
Или lzo-rle.

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

Судя по цифрам результата кажется что оно того не стОит ради 7% производительности. Но тут видимо очень важно наличие SSD.

Когда я года 2 назад пробовал обуздать систему с 2мя ГБ и HDD - основной практический сценарий был вида «открыть N вкладок в браузере и потом переключиться на открытую первой, поскроллить туда-сюда». Время замерял от «нажал мышку чтоб переключиться» до «скроллинг стал нормально работать»

Тестов с секундомером не проводил, но насколкьо я понмю разница была типа 30 секунд (swap, приложения, домащняя папка - всё HDD) VS 10 секунд (zswap.enabled=1 zswap.zpool=zsmalloc zswap.compressor=zstd zswap.max_pool_percent=42).

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

Потом кстати использовал эти же параметры zswap, когда временно схохла основная машина для работы и пришлось какое-то время запускать кучу тяжёлых приложений на 8GB памяти (и опять же HDD на тот момент…). Тут уже не было колоссального эффекта, на глаз максимум 20-30%.

В общем - имхо интересней было бы не за 7% гоняться, а для HDD оценить эффект для разных вариантов (при этом можно не с 2ГБ памяти, а с большим количеством и болшой нагрузкой). Там это может быть киллер-фичей производительности.

GPFault ★★ ()
Последнее исправление: GPFault (всего исправлений: 1)
Ответ на: комментарий от devl547

и krasnh, сами любитесь с новыми ядрами на старой Невидии.

И можете прогнать аналогичную серию у себя.

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

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

Когда-то, когда hakavlad бился на ЛОРе в одиночку, доказывая необходимость грамотной настройки работы памяти и продвигая свой le9, я, видя инертность юзерской массы и нежелание патчить, считал, что «вот когда выйдет ядро 6.1, все воленс-неволенс пересядут на него и обретут дзен».
Реальность хуже. 😀

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

Увеличь DISKSIZE до 3:1 к RAM

В смысле пытаться хранить в оперативке 6 гигов сжатых данных? Я так уже делал на RPi3 c 1 гигом, всё упиралось в то, что при слишком большой zram оно оставляет слишком мало доступной приложениям памяти и вся система со всем софтом упорно, но безуспено пытались работать ы ~200М памяти. В данном случае я выделил приложениям порядка 1,3-1,5 гига, что вполне вольготно для браузера с 5 вкладками и ещё какой нибудь мелочи.

Если речь о том, чтобы изменить сжатый кеш с 25% до 33% то это скорее всего не принципиально.

И zstd желательно вместо lzo. Но здесь смотреть, конечно, как pentium отреагирует.

Он на это отреагирует очень плохо. У меня всего 2 ядра, 1,5 из которых используется файерфоксом для отрисовки одной вкладки, а скорость сжатия zstd ниже, чем сброс данных на ssd блоками по 4К. Вот будь у меня какой нибудь zen3+ хотя бы на 8 потоков...

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от GPFault

В общем - имхо интересней было бы не за 7% гоняться

Это же не 7% эффективности свопинга, это 7% замедления процесса, в котором свопинг является далеко не главным компонентом. Щас попробую прогнать тест без тормозного парашюта.

а для HDD оценить эффект для разных вариантов

А вот это в принципе возможно. В извращенском правда варианте, хард будет висеть на юсб2.0. Так что не 4 а только 2 теста.

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

В контексте теста HDD - там баланс скорости и степени сжатия уже совсем другой, и lzo уже может не быть лидером общей эффктивности.

по USB2.0 в принципе хороший пример ещё более медленного устройства. В таком сценарии zram/zswap наверняка себя раскроют.

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

GPFault ★★ ()

Ускорители свопа однозначно совершили революцию. Только мы её не видим, потому что на ssd разницы не заметно.

А возросший i/o и следственно чуть больший износ SSD? В старых ядрах, дефолтный LRU плохо понимает, что можно/нельзя сбрасывать на своп и данные будут бесполезно гоняться туда-сюда. В отличие от MGLRU/le9. )

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

Ну раньше свопа на ССД все боялись как огня, но потом оказалось что они даже дешевле хардов, а ресурса там на десятилетия если без особого фанатизма и избегать косяков.

А ещё сжатые свопы однозначно сокращают i/o. Конкретно вы моём тесте zswap+hdd оказалось, что на диск почти ничего не пишется пока не забьётся кеш 450М*(2,7...3 сжатие). А на 24 вкладках это примерно первые 18-20.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от ya-betmen

Если вычесть это время (что 6:04, что 6:37), получается довольно заметая разница в 19 секунд из 56...89 (как считать).

Или в случае hdd

открытие: 8:40
закрытие: 2:45

против

открытие: 13:32
закрытие: 8:08

kirill_rrr ★★★★★ ()
Ответ на: комментарий от ya-betmen

Неприемлимо что, получить трёхкратное ускорение на харде и 21+% на ссд? Или неприемлимо на порядок-другой снизить своп-трэшинг или вообще избавиться от него?

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 2)
Ответ на: комментарий от ya-betmen

Всё равно неприемлимо.

Это стресс-тест на слабом ноуте с 2G ram, с процессором pentium duo «ограниченный до 65 градусов через cpufreqd».
Какие-то другие ожидания от подобного железа? :)

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

Вы забыли гирю в виртуалбоксе и тормозной парашют на одном ядре. И да pentium T3400, оно 2008 года на 65нм.

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Во, круто - это уже больше похоже на то что я наблюдал.

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

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

Так я собственно и пытался оценить. Итого zswap/zbud сливается, zswap/z3fold даёт большую отзывчивость при сбросе в своп, но zswap+backing_dev - большую производительность и скорость поднятия. Осталось подобрать алгоритм, подходящий к процессору и подходящий размер кеша. Ну и прочие твики, общие для всей подсистемы.

нет SSD и памяти меньше 32Гигов - однозначно надо включать одну из технологий.

А если есть ssd - надо включать чтобы снизить i/o и экономить ресурс.

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

насколько я понял вы только в свзяке с SSD тестировали варианты.

А с HDD соотношение производительности между вариантами может значительно отличаться.

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

Проценты и секунды будут меняться, но думаю общее распределение мест сохранится.

Нет, хватит с меня тестов, особенно на hdd. Проверять и подтверждать не буду. Тем более что системы на hdd становятся экзотикой, большого практического смысла нет.

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

Да, я про то и говорю. Инет и браузеры разжирели настолько, что всякие извращения со свопом погоды не делают. Я помню когда на селероне с 385 метрами опреативы хром запустил, лет 7 назад, так оно еле ворочалось.

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

Мне тоже ситуация не нравится, но нет, вот эти вот извращения со свопом позволяют мне за ~1500-2000р самого дешёвого ssd продолжать пользоваться старым ноутом и не тратиться на новый.

Это всё таки стресс-тест, стандартный для него сценарий это открыть пакет 2-5 вкладок со страницы поисковика, подготовить к чтению первую из них в течении 15-20 секунд и завершить работу в фоне, пока я читаю. Теоретически тут даже не нужен своп, но по факту система всегда находится на границе свопинга. И продолжает работать как будто памяти дочерта, просто проц слабый.

kirill_rrr ★★★★★ ()

Zram’чик упирается в RAM, а zswap нет. Ещё есть алгоритм сжатия хороший zstd.

der5ys7em ()
Ответ на: комментарий от ya-betmen

А без стресса я могу открыть 3 окна по 10 вкладок так, как будто у меня не 2 а 4 гига рамы. Собственно я в теории могу открывать их до тех пор, пока фокс не рухнет - свопа хватит. Скорости не прибавляется, только снижает i/o на ssd.

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

Оперативная память 2Гб
Цпу: двухядерный pentium duo (core2), ограниченный до 65 градусов через cpufreqd
Видеокарта nvidia 9200M 256M видеопамяти, драйвер nouveau
Дистрибутив дебиан10, ядро 4.19

Не релевантный тест. Этого старья уже ни у кого нет. Какая разница как работает своп на хламе.

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

Релевантный. Именно на железе с ограничениями RAM, как раз наглядно видна эффективность различных механизмов работы с памятью.

Можно еще линукс запускать в виртуалке с -m 1G/1.5G. Какие дистры (x86-64) сразу ‘отморозятся’, а какие будут работать несмотря ни на что (как пример, Garuda Linux).

p.s. Проц конечно портит картину, плюс еще и ‘придушенный’.

krasnh ()
Последнее исправление: krasnh (всего исправлений: 2)
Ответ на: комментарий от hakavlad

Отбиваются юзеры, руками и ногами. )
Патчить не хотят, кастомные не нравятся (xanmod, zen), обновиться на стоковое 6.1 не заставишь… :)

krasnh ()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от GREAT-DNG

На генту может быть. Скорее всего придётся собирать старую месу.

kirill_rrr ★★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.