The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Оценка производительности LZO и ZLib сжатия в файловой систе..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от opennews on 18-Мрт-11, 15:59 
Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo...) тестирование производительности реализации файловой системы Btrfs при работе в трех режимах: без сжатия данных, со сжатием при помощи метода ZLib и со сжатием с использованием метода LZO, поддержка которого была добавлена в недавно вышедшем Linux-ядре 2.6.38 (https://www.opennet.ru/opennews/art.shtml?num=29919).

В тесте Compile Bench, оценивающем скорость сборки различных проектов, Btrfs c LZO-сжатием обогнал вариант без сжатия в 2.25 раза и вариант с zlib-сжатием в 1.25 раз. В тесте IOZone  Btrfs c LZO-сжатием  опередил вариант без сжатия в 9 раз, а вариант с  zlib-сжатием в 2.4 раза.


В тесте Dbench результаты были примерно одинаковыми. При увеличении числа клиентов в тесте Dbench, а также при проведении текста FS-Mark, варианты с Zlib/LZO показали идентичный результат, опередив конфигурацию без сжатия на 20-22%. При отключении режима sync/fsync в тесте  FS-Mark вариант LZO в 3 ра...

URL: http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo...
Новость: https://www.opennet.ru/opennews/art.shtml?num=29959

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


5. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +2 +/
Сообщение от gegMOPO4 (ok) on 18-Мрт-11, 16:32 
Первый раз сходил по ссылке на Фороникс. Результат интересный. По крайней мере на некоторых задачах на некоторой аппаратуре есть большой смысл выбирать LZO.

В переводе ошибка. В FS-Mark LZO показал почти такой же результат, как без сжатия, это Zlib опережает их на 33%.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от tulskiy (ok) on 18-Мрт-11, 16:36 
Кто-нибудь пользовался IntelliJ IDEA c btrfs? Стоит ли включать сжатие, и вообще даст ли btrfs преимущество над ext4?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +3 +/
Сообщение от Drist (ok) on 18-Мрт-11, 16:47 
Если твоей целью служит потеря данных, то на данный момент времени бтрфс даст неоспоримое преимущество над ехт4. Потом в рассылке напишешь мольбу о помощи. Там разработчики любят разбирать что и как, чтобы потестить получше. Глядишь, через пару лет формат фс и утвердят, а еще через пару лет выпустят фсчк :) А там и федора 14 выйдет, где бтрфс по умолчанию, чтобы еще лучше потестить. Тогда, конечно, преимуществ над ехт4 будет поменьше, но зато нужных для работы, а не для теста.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от dalco (ok) on 18-Мрт-11, 18:27 
В целом согласен, но Fedora 14 уже вышла :) Так что btrfs по умолчанию - это Fedora 16 или 17 ;)

P.S. Периодически пробовал btrfs начиная с 12ой федоры (или даже раньше?). В общем, оно работает и даже неплохо... но не всегда. У меня в btrfs виртуальная машинка в qemu-kvm грузилась минут 20 против 20 секунд под ext4. :) А вот во всех остальных случаях никаких проблем, одна беда - мне виртуальные машинки важнее.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

14. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +1 +/
Сообщение от Frank email(ok) on 18-Мрт-11, 19:52 
Thu Mar 17 20:28 - crash
Thu Mar 17 08:16 - crash
Mon Mar 14 08:12 - crash
Fri Mar 11 20:26 - crash
Thu Mar 10 08:10 - crash
Wed Mar  9 08:20 - crash
Sun Mar  6 16:36 - crash
Sun Mar  6 14:27 - crash
Sat Mar  5 19:40 - crash
Sat Mar  5 10:59 - crash
Sat Mar  5 10:44 - crash
Fri Mar  4 06:31 - crash
Thu Mar  3 12:07 - crash
Wed Mar  2 13:55 - crash
Wed Mar  2 12:54 - crash
Wed Mar  2 08:10 - crash
Tue Mar  1 10:30 - crash

Как тебе такая картинка, впечатляет? Она уже несколько месяцев у меня, только не спрашивай почему - на то есть объективные причины. И это НЕ btrfs :)
Так вот, несмотря на такие завешивания (чаще всего вис железный и не работают даже magic keys), я не потерял НИЧЕГО за пол года эксплуатации btrfs. Так что насчёт "даст неоспоримое преимущество над ехт4" ты не прав.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от iZEN (ok) on 18-Мрт-11, 19:00 
А зачем сжатие для IntelliJ IDEA?
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

13. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от gegMOPO4 (ok) on 18-Мрт-11, 19:48 
Для скорости. Ну и многогигабайтные кеши с индексами если меньше занимать будут — тоже приятно.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

19. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от tulskiy (ok) on 20-Мрт-11, 08:16 
> А зачем сжатие для IntelliJ IDEA?

Скорость. Размер данных на диске не так важен, но время индексирования и работы с свн хотелось бы уменьшить. Тут важна запись и чтение тысяч мелких файлов. Судя по тестам самих JetBrains на ext4 работает раза в два быстрее чем на ntfs. Если btrfs быстрее ext4 на записи большого количества мелких файлов, то это будет огромный плюс для меня.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +1 +/
Сообщение от Paul Rufous email on 18-Мрт-11, 21:41 
Использую btrfs несколько месяцев, потерь данных не наблюдал, так что хватит писать фигню. Работает шустрее ext4. OS - Debian.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +2 +/
Сообщение от dalco (ok) on 18-Мрт-11, 21:54 
Вот если бы ты написал "использую пару лет на тысяче рабочих станций и сотне серверов и никаких проблем", тогда бы это что-то значило. А так... маловато данных для статистики.

P.S. Это справедливо не только для btrfs, но и для любой другой FS.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от pavlinux (ok) on 19-Мрт-11, 01:39 
>... Работает шустрее ...

если только NFS по модему 14400/MNP5/NONE

Попробуй виртуалки поклонировать.

# qemu-img clone
# VBoxManage clonehd  
# VBoxManage convertfromraw

из QEMU снапшота, применить изменения:  Ctrl+Alt+1, commit all

---
Может уже исправили, а в октябре так и было.
И меня всё это так затрахало, все эти попугай - BTRFS/ZFS/ext4/POHMELFS,
что конвертнул нахрен  всё обратно, в XFS, сплю спокойно. :)

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

18. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от IGX on 19-Мрт-11, 23:58 
На твоём месте я бы как раз побеспокоился, если тебе дороги данные, т.к. XFS очень критична к программным и аппаратным сбоям, включая сбои электросети и источников бесперебойного питания.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от pavlinux (ok) on 20-Мрт-11, 13:00 
> На твоём месте я бы как раз побеспокоился, если тебе дороги данные,
> т.к. XFS очень критична к программным и аппаратным сбоям, включая сбои
> электросети и источников бесперебойного питания.

Угу... пока глюки были везде, кроме XFS.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

21. "Оценка производительности LZO и ZLib сжатия в файловой систе..."  +/
Сообщение от Анон on 21-Мрт-11, 08:10 
А откуда беруться данные для чтения-записи в тестах? Они ведь все-таки синтетические. Если из /dev/urandom - тогда тут у сжатия шансов не должно быть никаких, если из /dev/null - тогда ясно откуда 9х. Или там все-таки приближенные к реальности файлы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру