https://opennet.dev/openforum/vsluhforumID3/48639.html В списке рассылки FreeBSD появилось (http://lists.freebsd.org/pipermail/freebsd-performance/2009-January/003660.html) сравнение производительности сервера MySQL на 8-процессорной платформе Intel(r) Xeon(r) CPU E5405 2.00GHz, выполненное утилитой sysbench (http://sysbench.sourceforge.net/). Результаты поразили самого автора, поскольку выяснилось, что при увеличении числа потоков от 1 до 8 производительность чтения/записи на Solaris 10 (SunOS 5.10) увеличилась всего в полтора раза (c 4286.61 до 6949.80 операций/сек), во FreeBSD 6.2 уменьшилось на 8% (с 6091.80 до 5614.48<br>). В тоже время на FreeBSD 7.1 прирост оказался почти 4-х кратным (с 6741.98 до 28091.60).<br><br>URL: http://lists.freebsd.org/pipermail/freebsd-performance/2009-January/003660.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=19990<br> https://opennet.dev/openforum/vsluhforumID3/48639.html#56 Thu, 29 Jan 2009 23:19:22 GMT &gt; ... Результаты поразили самого автора,...<br><br>http://lists.freebsd.org/pipermail/freebsd-performance/2009-January/003663.html<br><br>Ещё бы, поспешишь - людей насмешишь.<br> https://opennet.dev/openforum/vsluhforumID3/48639.html#55 Thu, 29 Jan 2009 15:34:40 GMT &gt;В FreeBSD 7.x, насколько я понял, заменили стандартную библиотеку malloc на jemalloc <br>&gt;(см. http://www.freebsd.org/releases/7.0R/announce.html ), по той же причине, т.е. оптимизации multithreading (см. <br><br>Да там комплекс - новый ULE scheduler, jemalloc, вычистили сетевой стэк (покиляли вроде бы все Giant_lock'и) и соптимизировали на текущее железо.<br>Хотя в 5-ть раз это конечно тестировщик явно план перевыполнял :) К очередному съезду?<br>У меня postgresql + lighttpd + python 2.5.4 + Django - те же восемь корок на два сокета (Dell 2950) - после апгрейда просто взлетел! Правда в основном в части postgresql :) Но всё одно - впечатляитЪ! (Не всё апгрейдом закончилось! Усли у вас система была "заточена" - придётся "перетачивать" - но это уже Welcome FreeBSD_Mail_Lists.<br> https://opennet.dev/openforum/vsluhforumID3/48639.html#52 Thu, 29 Jan 2009 15:02:02 GMT &gt;А что у тебя не глючило? С 5.0-5.2.1 все понятно, а со <br>&gt;всем, что было после, никаких проблем не было. <br>&gt;<br>&gt;Описание проблем улыбают: "зависали", "не инсталлировалось", "не бутился", "не запускалось". Как в <br>&gt;форуме районной локалки, дожили... <br><br>"Описание" проблем просто заняло бы тут весь форум. К тому же - если при инсталляции например не грузится ацпи.ко, или просто на этапе обнаружения девайса система виснет нахолодно - как еще подробнее описать эти проблемы? =)<br>Я не вел никаких записей для версий Х.0 так как во-первых я изначально был готов к тому, что они не будут ставиться, во-вторых, мне главное было, чтобы система работала, а заниматься мастурбацией типа "поставь-ка его еще с десяток раз, может прокатит или поймешь в чем трабл" мне было некогда и не на чем, и в-третьих, я могу прожить и на старой системе, если она работает, так как это не венда, которую если не обновишь, есть шанс потерять полностью (правда, если обновишь, то этот шанс еще больше=)))<br>Соглашусь, что всё индивидуально, зависит https://opennet.dev/openforum/vsluhforumID3/48639.html#51 Thu, 29 Jan 2009 14:03:26 GMT А что у тебя не глючило? С 5.0-5.2.1 все понятно, а со всем, что было после, никаких проблем не было.<br><br>Описание проблем улыбают: "зависали", "не инсталлировалось", "не бутился", "не запускалось". Как в форуме районной локалки, дожили...<br> https://opennet.dev/openforum/vsluhforumID3/48639.html#50 Thu, 29 Jan 2009 13:25:13 GMT &gt; "знатоки", которые от X.0 нос воротят потому что якобы "не стабильно".<br><br>знатоков не знаю, но (лично у меня): <br>5.0 глючило до 5.3 (помнят все)<br>6.0 глючило до 6.1 (просто не инсталлировалось с ЦД, при обновлении с 5.3 кернел не бутился)<br>7.0 глючило до 7.1 (иксы зависали при выходе, не обнаруживался сата-винт, ацпи.ко не запускалось ...)<br>И все эти глюки были вполне стабильны.<br> https://opennet.dev/openforum/vsluhforumID3/48639.html#49 Thu, 29 Jan 2009 11:40:14 GMT В случае MySQL + Solaris на многопроцессорно/ядерных системах рекомендуется для оптимизации производительности в multithreading использовать вместо стандартной библиотеки malloc использовать mtmalloc - см. MySQL InnoDB Performance Tuning for the Solaris 10 OS // SDN ( http://developers.sun.com/solaris/articles/mysql_perf_tune.html ).<br><br>В FreeBSD 7.x, насколько я понял, заменили стандартную библиотеку malloc на jemalloc (см. http://www.freebsd.org/releases/7.0R/announce.html ), по той же причине, т.е. оптимизации multithreading (см. Jason Evans, A Scalable Concurrent malloc(3) Implementation for FreeBSD - http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf).<br> https://opennet.dev/openforum/vsluhforumID3/48639.html#48 Thu, 29 Jan 2009 07:59:58 GMT &gt; Это даже не вопрос - все тот же linux, т.к. комманда в целом все еще та же.<br>&gt; Более того, внутри сана даже java-у пишут под linux <br><br>:) Это откуда такая инфа ?<br> https://opennet.dev/openforum/vsluhforumID3/48639.html#47 Thu, 29 Jan 2009 07:34:15 GMT &gt; то автор не писал бы про солярис <br><br>почему? мы используем его в продакшене<br><br>&gt; тем более про масштабируемость в целом. <br><br>однако, нам нужна именно эта характеристика относительно mysql<br> https://opennet.dev/openforum/vsluhforumID3/48639.html#46 Wed, 28 Jan 2009 23:54:21 GMT &gt;Хороший караван, к нам такие больше не ходят :) <br><br>Нормальный у вас караван, вы даже ник правильно не смогли написать ;)<br><br>