Kris Kennaway опубликовал (http://lists.freebsd.org/pipermail/freebsd-arch/2007-August/...) результаты тестов PostgreSQL и MySQL, проведённых с целью выявления узких мест в операциях чтения-записи на FreeBSD.Из-за медленной дисковой подсистемы на тестовом сервере, Kris дополнительно провёл тестирование с использованием TMPFS. При росте количества параллельных запросов производительность MySQL резко падает, причём система в это время практически не загружена. В то же время, PostgreSQL ведёт себя более устойчиво, хотя и показывает меньшую производительность при малом числе параллельных запросов.
URL: http://lists.freebsd.org/pipermail/freebsd-arch/2007-August/...
Новость: http://www.opennet.me/opennews/art.shtml?num=11661
кто на linux потестит? :).
PS конец мифу что на bsd быстро работают базы? :)
Смотря на какой платформе. На *BSD базы действительно работают быстрее, чем на Линуксе. Примерно на 30%. Но это не из за баз, это из-за Линукса.
Замечание 1. База должна быть _большой_. Настолько большой, чтобы ОЗУ понадобилось больше 4 гигабайт. Тогда Линукс с трёхуровневым VM'ом будет нервно покуривать в уголку. :) А пока нет выигрыша по скорости работы виртуальной памяти -- все сравнения дают данные в пределах погрешности одинаковые.
Замечание 2. Да, я знаю, какой ценой даётся это быстродействие. Оборудование надо подбирать правильное, умеющее 64'х-битный DMA. :)
Вы что при объемах памяти больше 4 гиг до сих пор используете 32-битные системы?
>Смотря на какой платформе. На *BSD базы действительно работают быстрее, чем на
>Линуксе. Примерно на 30%.а это скока в попугаях? %)))
А может не 30? Или не быстрее? ;)
>Но это не из за баз, это из-за Линукса.
>Замечание 1. База должна быть _большой_. Настолько большой, чтобы ОЗУ понадобилось больше
>4 гигабайт. Тогда Линукс с трёхуровневым VM'ом будет нервно покуривать в
>уголку. :)Хэх... а бздуны все голой ж..й на саблю...
Это оно в исходниках в 3 уровнях и при компиляции вырождаеться в использование всего-лишь 2 уровней: на 32 бит платформе нижний и средний, на 64 - нижний и высокий.Угу, а если она будет ОЧЕНЬ большой? ;) гиг 20...
бздя не помрет под линейными лупами?
И это >4гиг нужно как? Одному процессу или где? Дык это тогда amd64...
Так может ты не о том линуксе говоришь?
>А пока нет выигрыша по скорости работы виртуальной памяти
>-- все сравнения дают данные в пределах погрешности одинаковые.лирика...
>Замечание 2. Да, я знаю, какой ценой даётся это быстродействие. Оборудование надо
>подбирать правильное, умеющее 64'х-битный DMA. :)фантазер...
Тебе мало 4гига чтоб разминуться в буферах с винтом? ГЫ :)
Ты это либо придумал либо линух с чем иным путаешь...
>Хэх... а бздуны все голой ж..й на саблю...Я бы попросил следить за речью.
>Это оно в исходниках в 3 уровнях и при компиляции вырождаеться в
>использование всего-лишь 2 уровней: на 32 бит платформе нижний и средний,
>на 64 - нижний и высокий.И как же после компиляции так происходит вырождение VM'а, что 32'х-битный драйвер начинает резко узнавать про то, что памяти больше 4 гигабайт?
>Угу, а если она будет ОЧЕНЬ большой? ;) гиг 20...
>бздя не помрет под линейными лупами?
>И это >4гиг нужно как? Одному процессу или где? Дык это тогда amd64...:) *BSD не нужно мапить всю память в адресное пространство. Тут вам не Линукс. :)
>Так может ты не о том линуксе говоришь?
О том, о том.
>>Замечание 2. Да, я знаю, какой ценой даётся это быстродействие. Оборудование надо
>>подбирать правильное, умеющее 64'х-битный DMA. :)
>
>фантазер...
>Тебе мало 4гига чтоб разминуться в буферах с винтом? ГЫ :)Моя не понимать, каким образом драйвер SCSI-контроллера, не знающий про 64-bit DMA, сможет мне положить данные с винчестера в пятый гигабайт ОЗУ.
Или кое-кто наивно полагает, что у него собственный MMU родиццо?-)
>Я бы попросил следить за речью.да, чуток загнул...
>>Это оно в исходниках в 3 уровнях и при компиляции вырождаеться в
>>использование всего-лишь 2 уровней: на 32 бит платформе нижний и средний,
>>на 64 - нижний и высокий.
>
>И как же после компиляции так происходит вырождение VM'а, что 32'х-битный драйвер
>начинает резко узнавать про то, что памяти больше 4 гигабайт?когда врублена поддержка >4G памяти - юзаеться верхний уровень таблиц.
Как в 64бит архитектурах.
Одна запись в верхнем уровне адресует 4M.
4M*2^32 = выше крыши
>:) *BSD не нужно мапить всю память в адресное пространство.Даже если было бы нужно - то _чье_ адрессное пространство? ;)
ядра или какого-либо процесса? занумером 1? или 2?
Аддр. пространство оно виртуальное и его много ;)
Так какого адресного пространства? :)
>Тут вам не Линукс. :)о... уже инересно...
А Линукс, значит, всю память мапит куда-то? ;)
Где ты дурь (не слишком загнул?) берешь?
>Моя не понимать, каким образом драйвер SCSI-контроллера, не знающий про 64-bit DMA,
>сможет мне положить данные с винчестера в пятый гигабайт ОЗУ.Через bounce буфер. Т.е. реально тока конечно в нижние адреса, а потом уже ядро переложит.
Конечно это нельзя считать чесным "положением".
С другой стороны, если это не умеет железо - то пофиг о чем знает драйвер (а драйвер,
все-таки знать может под amd64. Или мы тока о 32 битах?)>Или кое-кто наивно полагает, что у него собственный MMU родиццо?-)
как тока на заводе поставят - так и появицо :)
А если не поставили - то, как я тока шо сказал, пофиг что знает или нет драйвер.
>Даже если было бы нужно - то _чье_ адрессное пространство? ;)
>ядра или какого-либо процесса? занумером 1? или 2?
>Аддр. пространство оно виртуальное и его много ;)
>Так какого адресного пространства? :)
>Чтобы ответить на это вопрос нужно вспомнить с чем работает DMA (правильного варианта Вы не назвали ;) ).
>Чтобы ответить на это вопрос нужно вспомнить с чем работает DMA (правильного
>варианта Вы не назвали ;) ).Ну 64 битное DMA в linux kernel есть если на то пошло.
>
>>Даже если было бы нужно - то _чье_ адрессное пространство? ;)
>>ядра или какого-либо процесса? занумером 1? или 2?
>>Аддр. пространство оно виртуальное и его много ;)
>>Так какого адресного пространства? :)
>>
>
>Чтобы ответить на это вопрос нужно вспомнить с чем работает DMA (правильного
>варианта Вы не назвали ;) ).а должен был? ;)
кто мне тут затирает про "маппинг в адресное пространство"?
Я что-ли? Вот я и спрашил. Мои варианты никак не обязаны содержать правильный вариант.
Это ж не тест на IQ :)а по сути
"*BSD не нужно мапить всю память в адресное пространство."
Линуху тоже этого делать не надо, но человек почему-то уверен, что надо...
Кто тут неправ - вроде бы очевидно
Такого мифа как раз и небыло.
Хороший тест: ни структуры таблиц, ни конфигурации, ни типов запросов. Брехня - на более слабом железе БДшки под фрибздей показывали более сильные резулбтаты, на нетривиальных запросах.ПС. Зачем такой бред помещать в новость? Или все что содержит картинки будет вешаться на главную страницу?
да...
какая-то странная новость.
никаких деталей, чтоб можно было перепроверить.негросовт-style
Тесты проводились стандартным набором тестов http://sysbench.sourceforge.net/.
О чём в тексте письма написано.
Esli pravelno pod tyunit BSD, to bistree :)
А теперь внимание, господа знатоки, вопрос: кто в жопе вот на этом графике: http://people.freebsd.org/~jeff/mysqlwrite.png
>А теперь внимание, господа знатоки, вопрос: кто в жопе вот на этом
>графике: http://people.freebsd.org/~jeff/mysqlwrite.pngСлышал о программе негросовта в свое сремя GetTheFUCKs?
Так вот они сравнивали RH7.3 с XP...Ты тоже страдаешь таким легким "скрытым" "незнанием" реалий?
Где ты взял эту 7-ку? В CVSе. Еще и пачку патчей прикрутил.
А Линух какой ты взял? Древний. Пойди посмотри на kernel.org - какое щас последнее?
А если взять не .22, а .23 с CFQ шедулером? Нет охоты такой график показать людям?
Не, вот такие красноглазые линуксоиды меня всегда умиляют, разница на 1 в последней цифре номера версии ядра - всё, уже древнее, передернем-ка сравнением в несколько лет разницы, ага. А то, что тесты были сделаны почти полгода назад на свежих в то время версиях того и другого - это поинтересоваться не в состоянии, да. Впрочем, чему удивляться, если даже про sysbench не в курсе, зато следуют понты насчет методологии тестов, ага-ага.
>Не, вот такие красноглазые линуксоиды меня всегда умиляют, разница на 1 в
>последней цифре номера версии ядра - всё, уже древнее, передернем-ка сравнением
>в несколько лет разницы, ага. А то, что тесты были сделаны
>почти полгода назад на свежих в то время версиях того и
>другого - это поинтересоваться не в состоянии, да. Впрочем, чему удивляться,
>если даже про sysbench не в курсе, зато следуют понты насчет
>методологии тестов, ага-ага.Легкое напоминание из моей цитыты: "...Еще и пачку патчей прикрутил..."
Линух то ванильный...Так чта либо с ванилью бзд давай тягацо, либо давай правильных патчей положим на пингвина...
>Не, вот такие красноглазые линуксоиды меня всегда умиляют, разница на 1 в
>последней цифре номера версии ядра - всё, уже древнее, передернем-ка сравнением
>в несколько лет разницы, ага.А вот тут ты не прав, в 2.6.23(с _rc1) новый шедулер. Он есть и для .22 но в виде стороннего патча от Ingo Molnar. Ну и glibc был допилен в 2.6. Так что же тебя смущает?
То, что некто _Nick_, в лучших традициях ЛОРа, любит нагло пиздеть. Багфиксы и влитие патчей - это не то же самое, что древность, и уж тем более сравнение RH7.3 с XP.
>То, что некто _Nick_, в лучших традициях ЛОРа, любит нагло пиздеть.Любит - этого не отнять :)
Но чуть больше он любит выдать правду-матку. Чем чаще это случаеться тем лучше.
>>То, что некто _Nick_, в лучших традициях ЛОРа, любит нагло пиздеть.
>
>Любит - этого не отнять :)
>Но чуть больше он любит выдать правду-матку. Чем чаще это случаеться тем
>лучше.Это не правда матка. Это просто постоянный флейм. Причем с постоянной демонстрацией своей не компетенции в плане деталей реализаций и вообще всего. Я бы давно фильтр поставил на _Nick_ ибо ничего конструктивного от него не дождешься. Только "жопы с саблями" в разных вариантах.
БСДшники как правило всегда готовы к диалогу, если оно не скатывается на оскорбления.
>http://people.freebsd.org/~jeff/mysqlwrite.pngпатч от Nick Piggin вошёл в каком-то из 2.6.22-rc.
Ну и ессно ещё и фикс в glibc.
Так что стоит сравнивать 2.6.22+glibc-2.6
А потом включить и там, и там PAE и выкинуть Пингвиникс в помойку. :)
>А потом включить и там, и там PAE и выкинуть Пингвиникс в
>помойку. :)Знаете когда на рынке свободно доступны 64 битные системы, гордиться тем что в FreeBSD лучше реализован PAE, довольно таки смешно. Особенно учитывая, что если приложение оптимизировано под 64 бита, то прирост может быть до 30 процентов.
> Знаете когда на рынке свободно доступны 64 битные системы, гордиться тем что в FreeBSD лучше реализован PAE, довольно таки смешно.На рынке свободно доступен AMD64 (ну, или EM64T, один болт).
А ему нужно то же, что и PAE - 64'х-битный DMA.
Или куча костылей, которые в Линуксе называются трёхуровневым VM'ом, что для FreeBSD неприемлемо, так как приводит к деградации производительности, а в мозгах корпорации nVidia называются контролем за линейным адресным пространством областей, выделяемых функцией mmap().
zander из nVidia писал, что их GPU -- 32'х разрядные (в смысле внешней шины), и поэтому, чтобы появился драйвер для nVidia'вских карточек под FreeBSD/amd64, им нужно, чтобы...
[за необходимым -- на nvforum :)]
>На рынке свободно доступен AMD64 (ну, или EM64T, один болт).
>А ему нужно то же, что и PAE - 64'х-битный DMA.не наезда ради, но правды для...
64бит DMA нужно лишь для того, чтоб девайсы сами могли адресовать >4г, чтоб выложить в них
приехавшее из девайса.
К софтовому подходу это дела никакого не имеет (по крайней мере я не вижу проблем в нижних 4 гигах держать пару десят метров для DMA).
Поправь, если я неправ...>Или куча костылей, которые в Линуксе называются трёхуровневым VM'ом, что для FreeBSD
>неприемлемо, так как приводит к деградации производительности,да не приводит. Оно вырождаеться в 2 уровня при сборке еще.
(http://www.ibm.com/developerworks/ru/library/l-memmod/)>а в мозгах корпорации
>nVidia называются контролем за линейным адресным пространством областей, выделяемых >функцией mmap().ну, с Линухом то эта корпорация ужилась :)
И весьма неплохо ;)>zander из nVidia писал, что их GPU -- 32'х разрядные (в смысле
>внешней шины), и поэтому, чтобы появился драйвер для nVidia'вских карточек под
>FreeBSD/amd64, им нужно, чтобы...
>[за необходимым -- на nvforum :)]да... было такое :)
вот и иди тут расказывай о высоком... о BSD-style...
>На рынке свободно доступен AMD64 (ну, или EM64T, один болт).
>А ему нужно то же, что и PAE - 64'х-битный DMA.Который есть в 64 битном ядре. Не забываем что для AMD64 ядро собирается соответвующее и работает в соответвующем режиме. И DMA там тоже работает в необходимом режиме.
>Или куча костылей, которые в Линуксе называются трёхуровневым VM'ом, что для FreeBSD
>неприемлемо, так как приводит к деградации производительностиКак уже говорили выше это есть только на уровне исходных кодов при сборке не нужный уровень отсекается. И?
>zander из nVidia писал, что их GPU -- 32'х разрядные (в смысле
>внешней шины), и поэтому, чтобы появился драйвер для nVidia'вских карточек под
>FreeBSD/amd64, им нужно, чтобы...Или переделали шину или правильно написали драйвер чтобы он не клал ничего выше 4Gb лимита.
>Вот интересно, зачем в комментах обсуждают линукс, если новость
>была исключительно внутриBSDшная?..Совершенно согласен.
Лучше бы дали ссылки на тесты непосредственно mySQL и PostgreSQL как в линуксе так и во фряхе (иль другое бсд)... Свежие и из хороших источников, а не от "Вася Пупкинс Групп"...
>Лучше бы дали ссылки на тесты непосредственно mySQL и PostgreSQL как в
>линуксе так и во фряхе (иль другое бсд)... Свежие и из
>хороших источников, а не от "Вася Пупкинс Групп"...А чем производительность mysql мерять-то? Есть скрипт чтоб запустил и он все сам сделал? А то я-то могу тестов напридумать, но они вам вряд ли понравятся :)