Jeff Roberson продолжает (http://jeffr-tech.livejournal.com/17426.html) работу над ULE, вводя новые алгоритмы распределения, на основе более точного анализа внутренней структуры SMP системы.
Новый экспериментальный алгоритм позволяет учитывать дополнительные факторы, такие как, например, общий кеш мультиядерных процессоров и их общие шины.
Результаты тестирования нового ULE на XEON системе с 16 ядрами:
- Тест BIND, NSD (http://people.freebsd.org/~kris/scaling/bind-nsd.png)
- Тест PostgreSQL (http://people.freebsd.org/~kris/scaling/pgsql-16cpu.png)
- Тест MySQL (http://people.freebsd.org/~kris/scaling/mysql-16cpu.png)URL: http://jeffr-tech.livejournal.com/17426.html
Новость: http://www.opennet.me/opennews/art.shtml?num=14072
Подобный бенчмарк уже выкладывал Крисс Кэнэвэй в виде PDFа.
Вот HTML версия если что: http://www.allunix.ru/page.php?10
Там и сравнения с линуксами и вообще тестов по-больше.
не сочтите за рекламу, я правда считаю. что это должно быть интересно, и не помню этого на опеннете, если найдете, можете переделать ссылку.
>и не помню этого на опеннете, если найдете, можете переделать ссылку.Было на opennet конечно, но тесты там другие - http://www.opennet.me/opennews/art.shtml?num=12489
Дтругие похожие тесты производительности:
http://www.opennet.me/opennews/art.shtml?num=11661
http://www.opennet.me/opennews/art.shtml?num=11096
http://www.opennet.me/opennews/art.shtml?num=11070
http://www.opennet.me/opennews/art.shtml?num=9937
http://www.opennet.me/opennews/art.shtml?num=9423
http://www.opennet.me/opennews/art.shtml?num=4860
Да, вот это: http://www.opennet.me/opennews/art.shtml?num=11661 как я понимаю то же самое.
Ну можете мой камент убрать тогда, следовало бы эти сылки в "Ссылки к новости" вставить. Или оно и там есть?
Тот pdf - это обобщение тестов проведенных в октябре прошлого года и еще раньше. Эти же, выполенны над CURRENT с новыми фичами.Просто динамика развития...
А, туплю. я думал там тоже семёрка.
Из теста постгреса видно, что opteron лучше (предсказуемее) масштабируется, чем xeon.
Хм, таки из ULE делают конфетку. Пока (в текущей 7.0) он мне кажется довольно ублюдским.
>Хм, таки из ULE делают конфетку. Пока (в текущей 7.0) он мне
>кажется довольно ублюдским.У меня на двухксеоновом интеловом серваке 6.3 с SCHED_ULE ядро виснет после определения винтов... Жду 7.0, чтоб потестить :))
Do NOT use ULE on 6.x. ULE has been revamped heavily on 7.0 and the
version on 6.x is old, and is known to contain some bugs.Use it in 6.x if you dare, just don't complain to us if it breaks your system :-)
i.e. if at any point you start experiencing problems, do not report them
until you have verified that they persist with 4BSD also.И всё равно, кажный раз отряд леммингов пытается воткнуть ULE на 6.x и взлететь :)
Вообще ИМХО им надо было его переименовать или индекс присвоить - ULE3 например. А то непонятки бывают... ;)
>И всё равно, кажный раз отряд леммингов пытается воткнуть ULE на 6.x
>и взлететь :)Тем не менее, на десктопе ULE отлично работает (мать Intel DG965WHKR)
Основная проблема с Firefox - т.к. это поделие жрет проц только в путь, оно считается неинтерактивным и начинает тормозить еще сильнее (разумеется, если есть что-то еще, что грузит проц). Т.е. make нужно все-таки запускать с nice или idprio, с 4BSD это не было нужно.
А что такого в 8.0 успели сделать по сравнению с 7.0 что bind так летает, что с ULE, что с 4BSD?
Со значительно более тормозной работой VFS, линуксоиды даже если ничего не изменят, быстрее всё-равно будет linux. :( Вот бы таких ребят как JRobertson и на ВСЕ ключевые подсистемы, тогда фря оживёт. А можно и по два... а то, пока он ULE мучает, 4BSD вообще официально списали на свалку (в рассылках при возникновении проблем с 7,8 и 4BSD тупо первый совет - использовать ULE)...
