Ресурс Phoronix провел (http://www.phoronix.com/scan.php?page=article&item=linux_262...) тестирование производительности Linux ядра начиная с версии 2.6.24 и заканчивая 2.6.33. В версии 2.6.33 отмечено заметное повышение производительности при выполнении текста Apache Benchmark. Незначительно увеличилась производительность последней версии ядра в текстах 7-Zip и LZMA. Примерно одинаковые результаты были продемонстрированы в тестах C-Ray, NAS Parallel Benchmark и Bullet Physics Engine.
По сравнению с версиями 2.6.30, 2.6.31 и 2.6.32, при использовании ядра 2.6.33 почти в 10 раз упала производительность при оценке скорости работы СУБД PostgreSQL (тест pgbench) и в два с половиной раза результаты ухудшились при выполнении теста PostMark. Незначительно уменьшилась производительность 2.6.33 в тестах FFmpeg и Bork File Encryptor.
При выполнении теста Dbench в однопоточном режиме, показатели ядра 2.6.33 ухудшились почти в 8 раз, но при увеличении числа потоков до 12, ядро 2.6.33 обогнало 2.6.32 более чем в два раза.URL: http://www.phoronix.com/scan.php?page=article&item=linux_262...
Новость: https://www.opennet.ru/opennews/art.shtml?num=25617
К чему бы это?
>К чему бы это?К тому, что продолжается пиление ядра под кластеры и прочий Ынтерпрайз - на десктопные системы кернелхацкерам давно начхать.
Видимо один CK для простых смертных старается...
Ещё чуть-чуть и надо будет бегом доводить до ума KDE для Windows.
Нет, просто нужно не использовать пионерские ядра, особенно на серверах. Регрессии постепенно устраняют, и в тех же el 2.6.18 ядрах, в которых куча новшеств из последних ванильных, проблема становиться не актуальной :)З.Ы. а что на десктопе юзать действительно не понятно.. Наверное, стоит посидеть на 2.6.31, и подождать, может что измениться с 2.6.32
>З.Ы. а что на десктопе юзать действительно не понятно..
на древнючем нтфсе то? удачи в этом направлении.
> Ещё чуть-чуть и надо будет бегом доводить до ума KDE для Windows.Я скорее поверю в то что ежи научатся летать чем в то что под виндовс появится реально юзабельный КДЕ.
Вспоминается небезызвестная история про то, как Нил Армстронг, будучи на Луне, произнес: "Удачи, мистер (Ковальски|Горски|Джефферсон|Мэрриот)!"
у PostgreSQL с последними ядрами резко упала производительность по вводу-выводу.Использую PostgreSQL 8.4.2, нагрузка примерно 2000-3000 INSERTов в секунду (самописная система для мониторинга MPLS-сети простроенной на CISCO, в БД складывается распарсенный Netflow v9).
Регрессия по сравнению с ядрами 2.6.17-2.6.30 где-то 1.5-2.5 раза в худшую сторону.
>мониторинга MPLS-сети простроенной на CISCO, в БД складывается распарсенный Netflow v9).
>Регрессия по сравнению с ядрами 2.6.17-2.6.30 где-то 1.5-2.5 раза в худшую сторону.Либо "регрессия", либо "в худшую сторону" лишнее. Иначе отрицание отрицания :)
>>мониторинга MPLS-сети простроенной на CISCO, в БД складывается распарсенный Netflow v9).
>>Регрессия по сравнению с ядрами 2.6.17-2.6.30 где-то 1.5-2.5 раза в худшую сторону.
>
>Либо "регрессия", либо "в худшую сторону" лишнее. Иначе отрицание отрицания :)Прошу прощения за масло маслянное =) Голова уже не работает
И что 33 будет в апрельском убунту 10.04? Кошмар.
>И что 33 будет в апрельском убунту 10.04? Кошмар.Там вроде как собирались .32 использовать, как раз из соображений что не успеют толком протестировать .33 ядро и отловить существенные проблемы, if any...
32ое ядро там будет.
на своём ноуте использую 33 ядро и вполне доволен.
использую также и постгри, но понятное дело на ноуте не под нагрузкой.
не кажется ли более логичным тюнить постгри под ядро (и фс), а не наоборот?
>на своём ноуте использую 33 ядро и вполне доволен.
>использую также и постгри, но понятное дело на ноуте не под нагрузкой.
>
>не кажется ли более логичным тюнить постгри под ядро (и фс), а
>не наоборот?Глубочайше извиняюсь конечно, но постргесом я уже 7 лет занимаюсь тюнить его и систему под него умею.
Процесс уходит в спячку, да так что порой через SELECT pg_cancel_backen(<pid>); не отстреливается
По top и iostat и sar видно гигантский IOWAIT, дело где-то в планировщике ядерного ввода-вывода.
Если удастся выяснить где именно, буду писать багрепорт на LKML, авось поможет.
И еще скажу, что по сравнению с 2.6.32.x у 2.6.33 IOWAIT значительно меньше, хоть и больше оного в старых ядрах.
ожидание ввода-вывода бывает ведь не только тогда, когда ввод-вывод перегружен, но и когда какой-либо ресурс занят (заблокирован. а блокировки - это вечный бич субд).
т.е. вполне возможно, что постгри не совсем корректно работает с нововведениями ядра и не оптимально лочит те или иные данные.
зы:
я так понимаю, что в тесте использовали ext4? а как будет на старом ext3, но под 33 ядром? или вообще на ext2? или на бтр?
>ожидание ввода-вывода бывает ведь не только тогда, когда ввод-вывод перегружен, но и
>когда какой-либо ресурс занят (заблокирован. а блокировки - это вечный бич
>субд).
>т.е. вполне возможно, что постгри не совсем корректно работает с нововведениями ядра
>и не оптимально лочит те или иные данные.
>зы:
>я так понимаю, что в тесте использовали ext4? а как будет на
>старом ext3, но под 33 ядром? или вообще на ext2? или
>на бтр?Сейчас все работает на EXT4, до этого сидело на EXT3 и ядро было 2.6.30.4
Btrfs пока страшновато юзать, но как стабилизируется буду юзать его или nilfs2.
IOSTAT показывал 100% загрузку дисков при тестах, но может это глюк IOSTAT какой.
а разные планировщики пробовали?
надо наверно для десктопа и для серверов использовать по разному скомпилированные ядра. кроме того наверняка не все программы написаны для использования на многоядерных процессорах.
у меня 8 потоков и что мне теперь делать :) ? обидно когда компьютер использует пониженную частоту и 1-2 ядра и приходится ждать завершения какой-н операции.
> обидно когда компьютер использует пониженную частоту [..] и приходится ждать
> завершения какой-н операции.К чему весь этот спич? Частота проца по мере необходимости поднимается, а понижается только когда делать нечего. Всякими там powernowd и прочими подобными по смыслу. Как бы -ck тут не при чем вроде?! oO
плохо частота поднимается. бывает работает процесс на 20-40%. может тормозит еще изза обращений к жесткому диску.
Фрониксы отсюда тесты тырят - http://kernel-perf.sourceforge.net/results.machine_id=14&opt...