LINUX.ORG.RU
Форум — Admin  

Я ффш0ке от производительности zfs с сжатием gzip-9 на чтение.


0

2

Коротко: zfs с gzip-9 живущая в файловом контейнере на ext4 в 2 раза опережает сам ext4 на чтение.

Все началось с того что обнаружил в текущем Debian Wheezy поставленном на древнем 10+летнем ноуте с Celeron-1.6 пакет: zfs-fuse и поставил его.
Когда пару лет назад я начал ковырять zfs - она работала исключительно на x64 компьютерах и мне пришлось лишь для неё ставить Debian x64 на компе и нетбуке.
Сейчас она реализована и на x32, но в этой реализации отсутствует Алгоритм сжатия lz4, потому я поставил gzip-9, создал на корне 10Gb Контейнер и забил его корнем+частью из /home.
Устроив чтение дерева в /dev/null подумал
что 25 минут это долго и начал читать с нативного раздела. На момент 25 минут было считано лишь 5Gb. Я разочаровался было в ext4 но обнаружил там xfs, запустил онлайн дефраг но это не исправило ситуацию. Однако разница в два раза меня ошеломила и я пошел на другой комп:

с процессором: Intel(R) Celeron(R) CPU E3400 @ 2.60GHz
К нему по USB3 подключен 3TB Seagate NAS3T, на нем ext4 раздел с корнем
свежепоставленного Debian Wheezy смонтированный в /mnt/root:
Total Used Free
47G 4,2G 40G

читаем этот корень:
#find root -type f -exec cat '{}' \; |pv|dd of=/dev/null
3,44GB 0:07:41 [7,63MB/s] [ <=> ]
7144764+124516 записей считано
7205901+1 записей написано
скопировано 3689421565 байт (3,7 GB), 461,169 c, 8,0 MB/c

Там же делаем 10Gb контейнер:

#dd if=/dev/zero of=zfs-10G.zfs bs=1048576 count=0 seek=10240

Затем делаем в нем zfs
#zpool create zfs-over-ext4 /mnt/root/zfs-10G.zfs
устанавливаем упаковку gzip-9
#zfs set compression=gzip-9 zfs-over-ext4

Копируем /mnt/root на zfs в контейнере на ext4.
#/usr/bin/time rsync -axvPH --exclude=/zfs-10G.zfs /mnt/root/ /zfs-over-ext4
sent 3698550260 bytes received 2594892 bytes 4281255.24 bytes/sec
total size is 3690113480 speedup is 1.00
38.01user 71.12system 14:23.83elapsed 12%CPU (0avgtext+0avgdata 52060maxresident)k
5681360inputs+7203210outputs (0major+41076minor)pagefaults 0swaps

Теперь читаем записанное:
#find /zfs-over-ext4 -type f -exec cat '{}' \; |pv|dd of=/dev/null
3,44GB 0:04:36 [12,7MB/s] [ <=> ]
7144723+124584 записей считано
7205901+1 записей написано
скопировано 3689421565 байт (3,7 GB), 276,59 c, 13,3 MB/c

Упс... тут тоже разница 4:36 минут против 7:41 на чистом ext4
я ффш0ке...

Понимаю что тут compressratio=2.49, но на древнем ноуте с тормозным целероном он 1.71. Тестирование конечно слабое, но радует что zfs есть теперь и для x32.
я ффш0ке...

И на довесок скопируем тот же корень в нативный 2.6T zfs с упаковкой lz4

#/usr/bin/time rsync -axvPH --exclude=/zfs-10G.zfs /mnt/root/ /opt
sent 3698550254 bytes received 2594886 bytes 5898239.27 bytes/sec
total size is 3690113480 speedup is 1.00
39.33user 78.36system 10:27.53elapsed 18%CPU (0avgtext+0avgdata 53960maxresident)k
7882326inputs+7203010outputs (6major+32134minor)pagefaults 0swaps
10 минут против 14 минут.

Теперь читаем:
find /opt -type f -exec cat '{}' \; |pv|dd of=/dev/null
3,44GB 0:06:21 [9,21MB/s] [ <=> ]
7144846+124348 записей считано
7205901+1 записей написано
скопировано 3689421565 байт (3,7 GB), 381,878 c, 9,7 MB/c
Где то посередине между gzip-9 в контейнере поверх ext4 и ext4

Вообще от zfs пока в основном положительные впечатления.
Если у кого есть отрицательные отзывы - интересно будет послушать.

Я наверное всех уже утомил, пойду спать.

★★★

Последнее исправление: n0mad (всего исправлений: 2)
← Не устанавливается Bitrix на VDS
Не пингуются сервера и компы 192.168.30.0/24 подсети →
 ← 1 2

find /opt -type f -exec cat '{}' \; |pv|dd of=/dev/null

ты же просто читаешь содержимое всех файлов.

при чём тут zfs вообще ? :-)

кому какое дело до ФИЗИЧЕСКОЙ скорости чтения твоего жёсткого диска (куда в данный момент всё и упирается у тебя.. потому такой и результат.. особенно становится понятно, учитывая что жёсткий-диск на USB).

всем важнее насколько файловая система быстро решает — типичные для неё манипуляции с файловым деревом..

user_id_68054 ★★★★★
()

Вообще от zfs пока в основном положительные впечатления.
Если у кого есть отрицательные отзывы - интересно будет послушать.

ну в BTRFS тоже есть два вида сжатия: ZLIB и LZO (и ведётся работа над LZ4) ..

но только в отличии от ZFS — BTRFS не сломается после обновления ядра :-)

ну а почему ты пытался сравнивать ZFS именно с EXT4 , а не с BTRFS — вот это несовсем ясно (потому что бабка на лавке сказала что BTRFS якобы глючит? ну уж наверно не больше там «глюков» чем в неродной ZFS :))..

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

но радует что zfs есть теперь и для x32.

Шо есть x32? 32 бита? А зачем оно?!?! :)

Да, сброса кешей не видно - как кешей ОС, так и самого зфс.

Вообще - сжатие в gzip-9 идёт ОЧЕНЬ медленно, на любом процессоре. Вот у себя погонял - 20 мегабайт в секунду при архивации в devnull: 

# cat test | pv | gzip -9 > /dev/null
 598MB 0:00:25 [23.9MB/s]
Другие уровни GZIP не сильно быстрее на деле.

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

но только в отличии от ZFS — BTRFS не сломается после обновления ядра :-)

У меня reiserfs уже лет пять не ломается и видимо не сломается еще долго, если курды не помогут :)

hbars ★★★★★
()

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

vxzvxz ★★★
()

активно использую zfs под задачи виртуализации на основе KVM уже 1,5 года, она значительно облегчила жизнь, а самое замечательное это бекапы и разворачивание виртуалок посредством снапшотов zfs

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

но только в отличии от ZFS — BTRFS не сломается после обновления ядра :-)

Там где постоянно обновляют ядра zfs не место, это серьёзная ФС для промышленного применения.

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

Там где постоянно обновляют ядра zfs не место, это серьёзная ФС для промышленного применения.

Ага, не обновлять ядра — это серьёзно!

(Сарказм)

:-)

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

Ага, не обновлять ядра — это серьёзно!

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

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

я посмотрю, как часто ты будешь обновлять, если после обновления тебе придётся звонить в ФСТЭК и говорить об этом.

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

Надеюсь ты сбрасывал кеши?

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

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

find /opt -type f -exec cat '{}' \; |pv|dd of=/dev/null
ты же просто читаешь содержимое всех файлов.

Естественно, но банальный обход дерева, открытие и чтение
каждого файла на zfs проходит быстрее.

при чём тут zfs вообще ? :-)

Потому что с этой ФС быстрее всё читается.

кому какое дело до ФИЗИЧЕСКОЙ скорости чтения твоего жёсткого >диска (куда в данный момент всё и упирается у тебя.. потому >такой и результат.. особенно становится понятно, учитывая что >жёсткий-диск на USB).

Те же 10G Физически читаются так:
#dd if=/dev/sdb3 of=/dev/null bs=1048576 count=10240
10240+0 записей считано
10240+0 записей написано
скопировано 10737418240 байт (11 GB), 96,5956 c, 111 MB/c

всем важнее насколько файловая система быстро решает — >типичные для неё манипуляции с файловым деревом..

Вот именно. Надо обойти:
# find . -type d|wc -l
12983
Каталога.
Открыть и прочитать:
# find . -type f|wc -l
129682
Файлов.

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

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

erzent ☆☆
()
Ответ на: комментарий от user_id_68054

ну в BTRFS тоже есть два вида сжатия: ZLIB и LZO (и ведётся >работа над LZ4) ..

У меня негативные отзывы. Я ничего не замерял но год жизни (2 года назад взял 2TB USB Винт, поставил btrfs и сжатие. Через пол года использования начало сильно тупить.
Хотя могу и врать - у меня файлы кажется перестали читаться (давно это было). При этом физический диск читался без ошибок.

но только в отличии от ZFS — BTRFS не сломается после >обновления ядра :-)
ну а почему ты пытался сравнивать ZFS именно с EXT4 , а не с >BTRFS — вот это несовсем ясно (потому что бабка на лавке >сказала что BTRFS якобы глючит? ну уж наверно не больше там >«глюков» чем в неродной ZFS :))..

Я сравнил с тем что у меня было на древнем ноуте (xfs) и на настольном компе корень на ext4. Всё остальное в zfs.

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

пакет: zfs-fuse

выкинь эту какашку и поставь нативный модуль ядра для zfs (ZOL) - http://zfsonlinux.org/

Именно он и стоит на x64 машинке с USB3. Я рассказывал что сейчас и x32 появилось в fuse и видимо прямо в дистре.
Сейчас нативный zfsonlinux уже есть в x32? Раньше небыло.

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

но радует что zfs есть теперь и для x32.

Шо есть x32? 32 бита? А зачем оно?!?! :)

Увы есть и x32, у меня вон на расстоянии вытянутой руки 8 Машин из которых лишь 2 x64, одна из которых нетбук на атоме.

Да, сброса кешей не видно - как кешей ОС, так и самого зфс.

Где эти кэши у ext4 и xfs? Почему те так тупят хотя прогонял не раз.

Вообще - сжатие в gzip-9 идёт ОЧЕНЬ медленно, на любом >процессоре. Вот у себя погонял - 20 мегабайт в секунду при >архивации в devnull:

# cat test | pv | gzip -9 > /dev/null
598MB 0:00:25 [23.9MB/s]

Другие уровни GZIP не сильно быстрее на деле.

Не спорю.
У меня дома нет постоянно пишущих на диск задач. Если такие встретятся - никто не мешает отключить сжатие на отдельном подтоме.

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

а терь выдерни из розетки зфс и расскажи как ты готовил ext4?

Никак, так же как и zfs. Я банально поставил фDebian Wheezy на древний ноут и обнаружил что там есть еще и zfs-fuse.

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

ещё года 3 и дома она будет можно считать основной, при 128 гб оперативы проблеем с её использованием не будет.

Глупости. ZFS прекрасно работает в значительно меньших объёмах памяти.

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

посмотри btrfs и тоже удивись.

Пару лет назад смотрел. На тему подтомов и сжатия. Поставил на 2T USB винт, но радовался недолго. К сожалению не помню точно какие там были проблемы. Толи тормозить начала после серии xcopy на разные алгоритмы, чтения и удаления или тупо перестали читаться файлы, хотя физически диск читался. Толи оно перестало читаться после сбоя по питанию или висняка... не помню. В общем отрицательный отзы на 2 года назад. Пока устраивает zfs, поэтому btrfs не хочу и трогать.

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

я посмотрю, как часто ты будешь обновлять, если после обновления тебе придётся звонить в ФСТЭК и говорить об этом.

Ты мне сейчас хочешь рассаказать про стандартизацию? Я разворачивал в банках инфраструктуры на SCO OpenServer и поддерживал это хозяйство, когда доброй половины подписчиков LOR-а ещё в проекте не было.
Сейчас я использую ZFSonLinux на некоторых своих серверах, я продаю свои сервисы и услуги, мне плевать на ФСТЭК, более того, мои требования к доступности сервисов перекрывают их.

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

Где эти кэши у ext4 и xfs? Почему те так тупят хотя прогонял не раз.

У любой нативной ФС в линухе все просто - echo 3 > /proc/sys/vm/drop_caches

В случае с ZFS - хрен его знает. Для начала слезь с FUSE и перейди на ядерный ZFS - там всё бегает еще веселее. А там можно поиграться с параметрами модуля zfs - zfs_arc_min/zfs_arc_max и для чистоты эксперимента уменьшить этот кеш до минимума. Как его динамически сбросить - хз.

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

Для чистоты эксперимента. Иначе у тебя могут быть частично или полностью кешированные данные - наверняка не узнаешь.

blind_oracle ★★★★★
()

Из всего треда прочитал только заголовок. Ну а что ты хотел? CPU намного быстрее диска, поэтому гораздо быстрее прочитать вдвое меньше + распаковать, чем просто прочитать. И да, это относится к любым ФС, поддерживающим сжатие на лету.

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

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

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

Из всего треда прочитал только заголовок. Ну а что ты хотел? >CPU намного быстрее диска, поэтому гораздо быстрее прочитать >вдвое меньше + распаковать, чем просто прочитать. И да, это >относится к любым ФС, поддерживающим сжатие на лету.

Если скорость чтения винта 100Mb/s а фс чтает 5898239.27 bytes/sec т.е. около 6Mb/s для корневого раздела с 129682 файлам. То это наводит на размышления.

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

2 года назад взял 2TB USB Винт, поставил btrfs и...

То есть ты сравниваешь ощущения от СОВРЕМЕННОЙ версии zfs с ощущениями от УСТАРЕВШЕЙ версии btrfs? Да? :-)

«Отличная» задумка :) .. Напоминает рекламу Интернет Эксплорера :-)

Глупая твоя голова, год~два года назад над btrfs стоял гриф «пожалуйста не используйте». Сейчас там всё сильно улучшилось..

user_id_68054 ★★★★★
()

где тег «я познаю мир»?

Знаешь, что занимает 95% времени при чтении с диска? ВНЕЗАПНО: чтение с диска. А при сжатии вдвое читать нужно вдвое меньше. И что тут удивительного?

emulek ★
()

Если у кого есть отрицательные отзывы - интересно будет послушать.

мои файлы уже сжаты и/или несжимаемы. Зачем мне zfs?

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

И да, это относится к любым ФС, поддерживающим сжатие на лету.

…например ext4, только для включения этой бесполезной фичи тоже надо ядро пересобрать.

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

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

«сколько» это man free

«каких» это devision by zero.

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

Если скорость чтения винта 100Mb/s а фс чтает 5898239.27 bytes/sec т.е. около 6Mb/s для корневого раздела с 129682 файлам. То это наводит на размышления.

угу. Учить матчасть вам надо, юноша. 100мбпс это _линейная_ скорость, а есть ещё скорость позиционирования. Т.е. вы не учли время, за которое головка прыгает от дорожки к дорожке.

Попробуйте читать диск командой dd, но не подряд, а по 4К рандомными блоками. У вас и получится 6мбпс.

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

Сейчас там всё сильно улучшилось..

подтверждаю. Работает даже в слаке искароппки. Хотя я не пробовал.

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

2 года назад взял 2TB USB Винт, поставил btrfs и...

То есть ты сравниваешь ощущения от СОВРЕМЕННОЙ версии zfs с >ощущениями от УСТАРЕВШЕЙ версии btrfs? Да? :-)

Да, и я это оговорил. Я понимаю что всё движется вперед и когда куплю очередной xTB винт - я попробую btrfs.

«Отличная» задумка :) .. Напоминает рекламу Интернет >Эксплорера :-)

Я не видел этой рекламы и давно не трогал IE, однако по потреблению памяти сейчас все браузеры в отстое. На машинке с 512Mb рамы в интернете сидеть невозможно. Дичайшие тормоза.

Глупая твоя голова, год~два года назад над btrfs стоял гриф >«пожалуйста не используйте». Сейчас там всё сильно улучшилось..

Я мог и наврать и это было не 2 года назад а год назад - когда я купил 3TB винт и синкал туда основной zfs, при очередном синке появились и тормоза и невозможность прочитать файлы. Сейчас появилась мысль еще раз попробовать и рискнуть данными отформатировав копию в btrfs и синкнуть снова. Но зачем оно? Пока zfs устраивает и все эти ресинки занимают прорву времени. Да и вдруг при синке как раз умрет основной винт...

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

где тег «я познаю мир»?

Ага, и делюсь полученными знаниями здесь.

Знаешь, что занимает 95% времени при чтении с диска? ВНЕЗАПНО: >чтение с диска. А при сжатии вдвое читать нужно вдвое меньше. >И что тут удивительного?

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

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

мои файлы уже сжаты и/или несжимаемы. Зачем мне zfs?

У zfs есть возможность и не сижимать файлы.
При этом её создатели утверждают что она консистентна ВСЕГДА.

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

угу. Учить матчасть вам надо, юноша. 100мбпс это _линейная_ >скорость, а есть ещё скорость позиционирования. Т.е. вы не >учли время, за которое головка прыгает от дорожки к дорожке.

Вот я и сравниваю 2 разных ФС, в каждой из которых используются эти операции.

Попробуйте читать диск командой dd, но не подряд, а по 4К >рандомными блоками. У вас и получится 6мбпс.

Какой командой?

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

подтверждаю. Работает даже в слаке искароппки. Хотя я не пробовал.

Это btrfs, а топик про то что в Debian Wheezy есть zfs-fuse искаропки работающий даже на x32.
И при этом он увеличивает скорость даже находясь в файловом контейнере поверх других ФС.

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

Глупая твоя голова, год~два года назад над btrfs стоял гриф
«пожалуйста не используйте». Сейчас там всё сильно улучшилось..

Кстати про эксперименты: Сейчас в поисках правды нашел свой же 2 летней давности топик: Linux и файловые системы xfs,jfs,ext4,btrfs,squashfs. и вычитал там то из за чего «выкинул» btrfs:

n0mad

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


В том сравнении отсутствовала zfs

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

«каких» это devision by zero.

Почему это?

А под сколько я имел ввиду не объем... А скажем так - количество файлов.

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

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

да. Причём сначала надо найти номер нужного блока, а потом подвести головку к этому блоку. Второе действие занимает примерно в 1000 раз больше времени, чем первое, и от ФС совершенно не зависит. Зато сильно зависит от случайных причин, и от компактности данных.

И да, если сжать данные вдвое, то вероятность их нахождения на одной дорожке тоже увеличивается вдвое. А это ускорение чтение в 1000 раз.

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

У zfs есть возможность и не сижимать файлы.

вот и сравнивай ext4 без сжатия с zfs без сжатия

или ext4 со сжатием и zfs со сжатием.

И никак иначе. Просто в твоём сравнении нет смысла.

При этом её создатели утверждают что она консистентна ВСЕГДА.

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

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

Вот я и сравниваю 2 разных ФС, в каждой из которых используются эти операции.

дык а что вы удивляетесь, что прочитать 2Гб вдвое дольше, чем 1Гб? Я вам больше скажу: сжатие не занимает времени вообще. Процессор сжимает/разжимает быстрее HDD и параллельно с ним. Т.е. сжатие абсолютно _не тормозит_ чтение.

Какой командой?

лень думать. Напишите скриптик. Hint, случайные числа лежат в $RANDOM.

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

emulek ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2
← Не устанавливается Bitrix на VDS
Admin
Не пингуются сервера и компы 192.168.30.0/24 подсети →