-
![[image]](https://www.balancer.ru/cache/uploads/images/1248/128x128-crop/1248751-tatice-linux-tux-104092.png)
Производительность файловых систем. ext2 vs ext3 vs ext4dev vs jfs vs reiserfs vs xfs.
Теги:
Balancer
ext4dev ext3 тесты ntfs jfs компьютеры ntfs-3g reiser4 vfat reiserfs fat32 xfs Linux файловые системы ext2 производительность ext4
Затесался у меня тут раздел пустой на 2Гб и решил я немного побенчить нынешние штатные FS под Linux. Написал скриптик, который пишет в tmpfs ядро Linux, а потом делает проход по циклу по сабжевым FS и:
Вот что вышло:
Цифры:
Примечения:
Думаю повторить попозже тест на Core2Duo и, если получится, на 2.6.24 с reiser4.
Точные цифры в архиве лога: http://balancer.ru/files/0806/test.log.bz2
- Форматирует раздел под указанную ФС.
- Распаковывает сорцы ядра из tmpfs на получившийся раздел. Это около 300Мб.
- Далее заполяет раздел, несколько раз копируя и удаляя каталоги, имитируя работу с диском.
- Компилирует ядро, предпоследнюю копию при копировании.
- Делает grep по всем файлам сорцов ядра, ища там определённую последовательность.
- Далее копирует на раздел 470Мб музыки с домашнего NFS и потом, собственно, что измеряется, делает копию этого каталога на разделе.
- Смотрит, сколько в конце осталось свободного места.
- Измеряет уровень фрагментации раздела в конце.
- Считает время, ушедшее на измерение фрагментации.
- Удаляет всё, что вышло по rm -rf.
Вот что вышло:
Цифры:
| ext2 | ext3 | ext4dev | jfs | reiserfs | xfs | |
| Распаковка, сек. | 30,5 | 33 | 31,6 | 34,1 | 29,5 | 65,2 |
| Заполнение, сек./10 | 5,1 | 8,7 | 7,02 | 21,1 | 12,84 | 60,23 |
| Компиляция ядра, сек./10 | 66,7 | 67,2 | 67,8 | 67,1 | 67,2 | 67,7 |
| grep, сек. | 41,8 | 47,2 | 45,4 | 44,2 | 54,7 | 42,3 |
| Копирование музыки, сек*10 | 92 | 104 | 88 | 108 | 100 | 115 |
| Свободно в конце, Мб. | 0,0 | error | 0,0 | 12 | 128 | 37 |
| Фрагментация, %*10 | 13,9 | 15 | n/a | 25 | 76 | 0 |
| Время измерения фрагментации | 71 | 75,5 | n/a | 62,6 | 61,8 | 61,9 |
| Удаление всего, сек | 1,5 | 3,4 | 1,9 | 38,1 | 5,2 | 197 |
| Общее время, сек./10 | 128,6 | 134,4 | 126,7 | 150,2 | 137,3 | 213,1 |
Примечения:
- Железо: P4-3100 no HT, 2Гб RAM, HDD Samsung SP2504C.
- Система: Gentoo / 2.6.24-r8.
- Время компиляции было почти во всех случаях идентичным. Эталонная компиляция в tmpfs заняла 668 секунд. Судя по всему, тест упирается в производительность процессора. Позже нужно будет повторить на Core2Duo.
- Свободное место в тестах ext2 и ext4 в конце, на «музыкальном» тесте было реально равно нулю, а в случае ext3 не влезло несколько файлов. Но переделывать тесты не стал, думаю, это не так принципиально.
- Фрагментация для ext4 не измерялась, так как скрипт измерения на этой ФС обламывается.
Думаю повторить попозже тест на Core2Duo и, если получится, на 2.6.24 с reiser4.
Точные цифры в архиве лога: http://balancer.ru/files/0806/test.log.bz2
инфо
инструменты
хорошие результаты. я года три назад подобный проводил, так что по результатам с тех пор использую ext3 и не мучаюсь проблемой выбора
Shinkei aka HeoB
новичок
Всё конечно хорошо, НО! размонтировался ли после каждой операции раздел дабы сбросить файловый кеш?
Какой планировщик?
Какой планировщик?
S.a.H.> Всё конечно хорошо, НО! размонтировался ли после каждой операции раздел дабы сбросить файловый кеш?
Раздел не размониторвался, кеш сбрасывался копированием 2Гб мелкого мусора в других разделах.
S.a.H.> Какой планировщик?
CFQ.
Раздел не размониторвался, кеш сбрасывался копированием 2Гб мелкого мусора в других разделах.
S.a.H.> Какой планировщик?
CFQ.
ntfs-3g vfat fat32 файловые системы производительность компьютеры ext3 Linux jfs reiser4 reiserfs xfs тесты ext2 ext4 ext4dev ntfs
Итак, вторая серия.
Графиков пока нет, так как надо рисовать с диапазонами (я не поленился провести три серии опытов), а я пока это ни в чём не умею, ни в Excel, ни в GNUPlot
Тест сугубо практический. Заполняем тестовый раздел в несколько потоков всеми *.so из /usr/lib с сохранением структуры (1.3Гб) и потом читаем их оттуда, опять же, в несколько потоков случайным образом.
Начну с конца. Чтение, сек.
Фрагментация, %
Остаток свободного места на разделе, Мб
И, наконец, первая часть теста - сколько времени отнимала запись раздела, сек.
Параметры выполнения, как и в первом тесте. Добавлю неотмеченное ранее. Тест проводился в голой консоли, без GUI, после перезагрузки машины, с nice -5. Второй тест, в отличии от первого, проходил при включённом гипертрейдинге процессора. Перед каждым тестом осуществлялся сброс кеша. Число параллельных потоков при чтении/записи - 5. Фрагментирование осуществлялось путём двукратной записи одного и того же файла. Сперва из /dev/zero с половинной длиной, потом - правильным файлом.
Скрипты теста и логи: http://balancer.ru/files/0806/fs-test2.tar.bz2
Графиков пока нет, так как надо рисовать с диапазонами (я не поленился провести три серии опытов), а я пока это ни в чём не умею, ни в Excel, ни в GNUPlot
Тест сугубо практический. Заполняем тестовый раздел в несколько потоков всеми *.so из /usr/lib с сохранением структуры (1.3Гб) и потом читаем их оттуда, опять же, в несколько потоков случайным образом.
Начну с конца. Чтение, сек.
| ext2 | ext3 | ext4dev | jfs | ntfs-3g | reiser4 | reiserfs | vfat | xfs |
|---|---|---|---|---|---|---|---|---|
| 74,7 | 95,9 | 95,7 | 76,2 | 125,6 | 55,0 | 71,3 | 106,0 | 71,6 |
| 74,5 | 85,9 | 85,8 | 76,7 | 125,4 | 54,9 | 71,2 | 96,3 | 62,6 |
| 75,6 | 95,8 | 85,8 | 76,8 | 125,5 | 54,9 | 71,3 | 96,3 | 71,6 |
Фрагментация, %
| ext2 | ext3 | ext4dev | jfs | ntfs-3g | reiser4 | reiserfs | vfat | xfs |
|---|---|---|---|---|---|---|---|---|
| 5,9 | 21,1 | - | 35,5 | 0,85 | 2,36 | 8,2 | 40,0 | 0,02 |
| 5,5 | 14,1 | - | 37,2 | 1,05 | 2,18 | 6,9 | 39,2 | 0,03 |
| 4,3 | 14,6 | - | 34,0 | 0,85 | 2,51 | 8,9 | 41,0 | 0,02 |
Остаток свободного места на разделе, Мб
| ext2 | ext3 | ext4dev | jfs | ntfs-3g | reiser4 | reiserfs | vfat | xfs |
|---|---|---|---|---|---|---|---|---|
| 580,3 | 547,5 | 557,3 | 720,0 | 715,2 | 629,6 | 700,4 | 731,8 | 718,8 |
И, наконец, первая часть теста - сколько времени отнимала запись раздела, сек.
| ext2 | ext3 | ext4dev | jfs | ntfs-3g | reiser4 | reiserfs | vfat | xfs |
|---|---|---|---|---|---|---|---|---|
| 232,1 | 249,5 | 238,9 | 250,9 | 261,8 | 208,7 | 207,8 | 261,3 | 318,7 |
| 209,0 | 208,9 | 218,7 | 249,7 | 258,7 | 207,9 | 209,0 | 261,3 | 318,8 |
| 208,6 | 210,0 | 211,7 | 248,6 | 257,6 | 208,8 | 208,6 | 264,0 | 318,5 |
Параметры выполнения, как и в первом тесте. Добавлю неотмеченное ранее. Тест проводился в голой консоли, без GUI, после перезагрузки машины, с nice -5. Второй тест, в отличии от первого, проходил при включённом гипертрейдинге процессора. Перед каждым тестом осуществлялся сброс кеша. Число параллельных потоков при чтении/записи - 5. Фрагментирование осуществлялось путём двукратной записи одного и того же файла. Сперва из /dev/zero с половинной длиной, потом - правильным файлом.
Скрипты теста и логи: http://balancer.ru/files/0806/fs-test2.tar.bz2
В общем, по результатам этого теста, я теперь в раздумьях по поводу переползания на reiser4 Для /usr - просто рулит...
Одна засада - если припрёт поработать с LiveCD, боюсь, что в той же Бубунте поддержки reiser4 не будет :-/
resierfs (т.е. 3-й) и xfs показали на чтении /usr паритет, но xfs меньше фрагментируется.
ext3, ext4dev и jfs идут на третьем месте. При этом jfs показывает чудовищную фрагментируемость...
Для /usr - просто рулит...Одна засада - если припрёт поработать с LiveCD, боюсь, что в той же Бубунте поддержки reiser4 не будет :-/
resierfs (т.е. 3-й) и xfs показали на чтении /usr паритет, но xfs меньше фрагментируется.
ext3, ext4dev и jfs идут на третьем месте. При этом jfs показывает чудовищную фрагментируемость...
Balancer> В общем, по результатам этого теста, я теперь в раздумьях по поводу переползания на reiser4 Для /usr - просто рулит...
у тебя так активно меняется /usr?
Для /usr - просто рулит...у тебя так активно меняется /usr?
Harsky> у тебя так активно меняется /usr?
Неужели я НАСТОЛЬКО невнятно пишу ЦИФРЫ? Речь идёт о случаном многопоточном чтении. Если в таблицу не посмотрел - у reiser4 этот тест выполняется стабильно за 55 секунд. В то время, как следующее за этим лучшее время - 62,6сек. у xfs при типичном - 71,6сек.
Это очень приличный выигрышь. И только на одном чтении (на записи xfs оказывается в полной попе).
Неужели я НАСТОЛЬКО невнятно пишу ЦИФРЫ?
Речь идёт о случаном многопоточном чтении. Если в таблицу не посмотрел - у reiser4 этот тест выполняется стабильно за 55 секунд. В то время, как следующее за этим лучшее время - 62,6сек. у xfs при типичном - 71,6сек.Это очень приличный выигрышь. И только на одном чтении (на записи xfs оказывается в полной попе).
нет, это я неверно посмотрел. результаты чтения тупо перенес на запись
25% выигрыша по скорости - цифра приличная, но так как ни о какой разнице на порядок речи не идет, то останусь при своем мнении. от добра добра не ищут, ext3 - наше все
тем более что характер нагрузки на тот же /usr таков, что на интегральную производительность компа (да и сервера) это мало скажется.
25% выигрыша по скорости - цифра приличная, но так как ни о какой разнице на порядок речи не идет, то останусь при своем мнении. от добра добра не ищут, ext3 - наше все
тем более что характер нагрузки на тот же /usr таков, что на интегральную производительность компа (да и сервера) это мало скажется.
Harsky> 25% выигрыша по скорости - цифра приличная, но так как ни о какой разнице на порядок речи не идет, то останусь при своем мнении. от добра добра не ищут, ext3 - наше все
Только с ext3 разница выходит не в 25%, а в 70+% Т.е. уже почти вдвое. Мой опыт говрит, что начинаешь ощущать заметное ускорение, когда разница составляет около 20%.
Harsky> тем более что характер нагрузки на тот же /usr таков, что на интегральную производительность компа (да и сервера) это мало скажется.
Ну, для меня наиболее актуален вопрос быстрого холодного запуска приложений А тест, как раз, это примерно и отражает.
На днях попробую поменять /usr на reiser4 и посмотрю, как изменится время загрузки системы
Только с ext3 разница выходит не в 25%, а в 70+%
Т.е. уже почти вдвое. Мой опыт говрит, что начинаешь ощущать заметное ускорение, когда разница составляет около 20%. Harsky> тем более что характер нагрузки на тот же /usr таков, что на интегральную производительность компа (да и сервера) это мало скажется.
Ну, для меня наиболее актуален вопрос быстрого холодного запуска приложений
А тест, как раз, это примерно и отражает.На днях попробую поменять /usr на reiser4 и посмотрю, как изменится время загрузки системы
примерно на +70% -(время восстановления из бэкапа)
странно, почему на чтение между ext3 и ext2 такая разница?
с какими опциями монтировал ext2, ext3 и reiser4?
странно, почему на чтение между ext3 и ext2 такая разница?
с какими опциями монтировал ext2, ext3 и reiser4?
Harsky> с какими опциями монтировал ext2, ext3 и reiser4?
Исключительно дефолтовые.
Исключительно дефолтовые.
noatime было или нет?
linux под рукой нет, вот и спрашиваю
linux под рукой нет, вот и спрашиваю
Harsky> noatime было или нет?
Не было. noatime - недефолтовая настройка.
Вообще, в логах опции монтирования отмечены:
Не было. noatime - недефолтовая настройка.
Вообще, в логах опции монтирования отмечены:
/dev/sda6 on /mnt/fs-test type ext2 (rw)
/dev/sda6 on /mnt/fs-test type ext3 (rw)
/dev/sda6 on /mnt/fs-test type ext4dev (rw)
/dev/sda6 on /mnt/fs-test type jfs (rw)
/dev/sda6 on /mnt/fs-test type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
/dev/sda6 on /mnt/fs-test type reiser4 (rw)
/dev/sda6 on /mnt/fs-test type reiserfs (rw)
/dev/sda6 on /mnt/fs-test type vfat (rw)
/dev/sda6 on /mnt/fs-test type xfs (rw)
попробуй
может быть и менять ничего не потребуется, легкий тюнинг поправит ситуацию. ну и опции журналирования имеет смысл покрутить.
есть еще одна мысль, которая только теперь в голову пришла. если фс можно эксплуатировать в ro, то стоит потестить ее на чтение смонтировав с этой опцией. вдруг там под кеш память по другому распределяется?
может быть и менять ничего не потребуется, легкий тюнинг поправит ситуацию. ну и опции журналирования имеет смысл покрутить.
есть еще одна мысль, которая только теперь в голову пришла. если фс можно эксплуатировать в ro, то стоит потестить ее на чтение смонтировав с этой опцией. вдруг там под кеш память по другому распределяется?
usr в r/o - это не лучшее решение А noatime несколько ускорит, полагаю, но всех и совсем немного. У меня /usr именно с noatime и смонтирован, но это скорее просто бесплатная припарка. Прибавки в скорости не заметно.
А noatime несколько ускорит, полагаю, но всех и совсем немного. У меня /usr именно с noatime и смонтирован, но это скорее просто бесплатная припарка. Прибавки в скорости не заметно.
Balancer> usr в r/o - это не лучшее решение
это почему? на сервере эта фс прямо скажем, не часто меняется. и всегда с подачи оператора
ну что ж, reiser, так reiser... глядишь ганс за казенный счет его начнет улучшать бешеными темпами
это почему? на сервере эта фс прямо скажем, не часто меняется. и всегда с подачи оператора
ну что ж, reiser, так reiser... глядишь ганс за казенный счет его начнет улучшать бешеными темпами
poige
новичок
[…]
Balancer> Раздел не размониторвался, кеш сбрасывался копированием 2Гб мелкого мусора в других разделах.
Есть такой sysctl — vm.drop_caches (см. Documentation/filesystems/proc.txt)
Balancer> Раздел не размониторвался, кеш сбрасывался копированием 2Гб мелкого мусора в других разделах.
Есть такой sysctl — vm.drop_caches (см. Documentation/filesystems/proc.txt)
Balancer-as-user
Balancer-пользователь
старожил
poige> Есть такой sysctl — vm.drop_caches (см. Documentation/filesystems/proc.txt)
Меня уже на ЛОРе научили Второй тест пользуется системными средствами сброса кеша.
Меня уже на ЛОРе научили
Второй тест пользуется системными средствами сброса кеша.
Harsky> это почему? на сервере эта фс прямо скажем, не часто меняется.
Не знаю, как в других системах, а в Gentoo /usr обновляется каждый день Впрочем, в той же Убунту, в общем, тоже.
Не знаю, как в других системах, а в Gentoo /usr обновляется каждый день
Впрочем, в той же Убунту, в общем, тоже.
aldebober
новичок
Вы можете повторить тесты с определенными размерами файлов? Интересует конкретно скорость в МБ/с различными размерами отдельно по 10, 100 и 1000 МБ при линейной записи/чтении, в потоках и смешанные потоки чтения и записи. Думаю xfs оправдается на файлах от 1GB )))
Могу помочь с графиками в gnuplot.
Могу помочь с графиками в gnuplot.
Harsky>> это почему? на сервере эта фс прямо скажем, не часто меняется.
Balancer> Не знаю, как в других системах, а в Gentoo /usr обновляется каждый день Впрочем, в той же Убунту, в общем, тоже.
дело привычки. по мне - сервер должен работать, а не emerge в кроне пускать каждые 15 минут
Balancer> Не знаю, как в других системах, а в Gentoo /usr обновляется каждый день
Впрочем, в той же Убунту, в общем, тоже.дело привычки. по мне - сервер должен работать, а не emerge в кроне пускать каждые 15 минут
aldebober> Вы можете повторить тесты с определенными размерами файлов?
Пока только с мелочью. «Бесхозный» раздел только на 2Гб. Ту же торрент-раздачу на таком не сымитируешь. На ЛОРе сейчас отвечал, сюда кросс-пост:
По поводу XFS - думаю тут, не воткнуть ли второй винт, отрезав раздел гигов на 30 и пощупать имитацию торрент-раздачи. Только как - не придумал ещё. В голову приходит заполнить 1.4Гб РИПами, взять потоков 10 и дёргать случайные куски из случайных мест файлов. Насколько такой тест будет адекватным? Вопрос только - как средствами shell правильно обращаться в середину файла? tail/head, полагаю, это не то получится.
Пока только с мелочью. «Бесхозный» раздел только на 2Гб. Ту же торрент-раздачу на таком не сымитируешь. На ЛОРе сейчас отвечал, сюда кросс-пост:
По поводу XFS - думаю тут, не воткнуть ли второй винт, отрезав раздел гигов на 30 и пощупать имитацию торрент-раздачи. Только как - не придумал ещё. В голову приходит заполнить 1.4Гб РИПами, взять потоков 10 и дёргать случайные куски из случайных мест файлов. Насколько такой тест будет адекватным? Вопрос только - как средствами shell правильно обращаться в середину файла? tail/head, полагаю, это не то получится.
Harsky> дело привычки. по мне - сервер должен работать, а не emerge в кроне пускать каждые 15 минут
Да, дело привычки. Уверяю тебя, что после первого же серьёзного взлома через невовремя обновлённую библиотеку, привычки начнут меняться
А у меня это изменение произошло в 2003-м в шоковом режиме, когда Slapper домашнюю машинку мне взломал и за 4 часа нагенерил трафика больше чем на мою месяяную зарплату ($500 тогда)
Да, дело привычки. Уверяю тебя, что после первого же серьёзного взлома через невовремя обновлённую библиотеку, привычки начнут меняться
А у меня это изменение произошло в 2003-м в шоковом режиме, когда Slapper домашнюю машинку мне взломал и за 4 часа нагенерил трафика больше чем на мою месяяную зарплату ($500 тогда)
у меня сервера только изнутри ломать можно, а за это служба безопасности спасибо не скажет...
Copyright © Balancer 1997..2025
Создано 11.06.2008
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 11.06.2008
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
