Опубликованы (http://www.phoronix.com/scan.php?page=article&item=ext4_then...) результаты тестирования производительности файловой системы EXT4 в Linux ядрах 2.6.28, 2.6.29, 2.6.30, 2.6.31, 2.6.32 и 2.6.33-rc4. Два теста (IOzone, Threaded I/O Tester) показывают заметное падение производительности EXT4 начиная с версии Linux ядра 2.6.31. В тесте на производительность работы СУБД PostgreSQL при использовании Linux ядер 2.6.32 и 2.6.33-rc4 скорость упала почти в 5 раз, по сравнению с более старыми версиями ядра.При тестировании пакетами Dbench, AIO-Stress и PostMark производительность EXT4 наоборот возросла начиная с версии ядра 2.6.30. Ощутимый прирост скорости наблюдается также при монтировании с опцией "nobarrier".
URL: http://www.phoronix.com/scan.php?page=article&item=ext4_then...
Новость: http://www.opennet.me/opennews/art.shtml?num=25057
Терпеть не могу такой стиль изложения, очень характерный для mail.ru "Опубликованы результаты", на мой взгляд существенно лучше писать - Такой-то провел ряд сравнительных тестов производительности файловой системы и т.д.
А то получается сенсация вроде "Определен конец света!" или "Показан самый крутой в мире девайс" и т.д.!
никак нельзя. Народ в первой фразе увидит "фороникс" и не откроет материал :)))
У народа и так первая мысль при чтении подобных заголовков: "фороникс".
Умеете лучше - сделайте.
Надо признать, столь же интересные вопросы в плане сравнения производительности (разных ядер, разных осей, разных ФС) никто кроме них на сегодня не задаёт.
Всё-таки надо заметить: скорость, например, операций с СУБД упала за счёт повышения надёжности, phoronix на этом несколько раз заострял внимание. Так что это не просто 100% отрицательные регрессии, иначе их бы уже исправили.
И никто конечно не сравнивал как была реализована работа Delayed allocation в разных версиях ядра и про то как раньше терялись данные при некорректном выключении. Неоправданно жертвовать надежностью в сторону производительности.
>про то как раньше терялись данные при некорректном выключении.Откуда этот слух пошел? ФС тут неособо причем - это либо дистрибутив(установлены более высокие задержки на сброс дисковых кешей) либо опять же заморочка с бекпотрами(в более старое ядро бэкпортировали код из более нового). такой прямой потери данных нис того ни с сего никогда не было
А почему с .31 скорость чтения упала?
В кои-то веки дельное что-то сравнили на хворониксе!Не то чтобы есть смысл сравнивать ядра (ведь если кто консервативен в силу каких-то причин, тот привязан на .27), да и не о производительности собственно речь, но интересно следить, как ext4 пилят -- а сколько времени прошло с тех пор, как с нее сняли ярлык EXPERIMENTAL?
Чем так многих фороникс не устраивает? Есть другие ресурсы регулярно тестящие всякие линуксы?
Это местные тролли. Фороникс делает - они ноют :) А самим что-нибудь сравнить - сразу в кусты, это не нужно, ламерство и т.п.
> В тесте на производительность работы СУБД PostgreSQL при использовании Linux ядер 2.6.32 и 2.6.33-rc4 скорость упала почти в 5 раз, по сравнению с более старыми версиями ядра.видимо PostgreSQL использует какието "хаки" для повышенного работы с файлами..
..наиболлее вероятно что эти хаки перестали работать (начали работать навред) в новых версиях ядра
# p.s.: ничего не имею против PostgreSQL (которую щитаю наиболее прогрессивной) .. но версия всёже те или иные "хаки" то и дело имеют место быть в различных программах...
А с чем связаны такие сильные регрессии на операция чтения в IOzone?
Фороникс не осилил man mount и /Documentation ?
странно-гугл недавно перешел на ext4. не враги же они семи себе
гугл ext4 всвоей конфигурации с отключенным журналом и barrier использует.