LINUX.ORG.RU

Программист Intel нашел проблему масштабирования linux на SMP.


0

0

Программист Intel, Yanmin Zhang, прислал патч для glibc-2.5, [возможно] исправляющий проблему масштабирования Linux на SMP, продемонстрированную красочными тестами с графиками провала роста производительности mysql на более чем 8-ми процессорах, которая так активно мусолилась весь предыдущий месяц.

Еще неделю назад, Anton Blanchard выяснил, что проблема оказалась вовсе не в ядре Linux, а в GNU libc (glibc), в функциях malloc/free.

(Спасибо MaratIK за конструктивное исправление текста новости)

Изменено: Casus

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от Deleted

> проблема, связанная с проблемой

Это где ж такое?

dmesg
() автор топика

Такая новость не может не радовать, пускай даже я и не пользуюсь восьмиголовыми процами :)

h8 ★★★
()
Ответ на: комментарий от soko1

>всего три строчки (см. патч) изменили мир к лучшему:)

+1 :)

хорошая новость

dotcoder ★★★★★
()

Да, это действительно радует. Интересно, подвержены ли более старые версии glibc, типа 2.4

Valmont ★★★
()

вот еще бы решил проблему с firefox наконец-то ;) Поставил аллокатор от openbsd все равно:

PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND

1482 asshole 15 0 303m 166m 29m R 0 18.8 firefox-bin

Oceanborn
()

Респект!

> всего три строки!
+1

anonymous
()
Ответ на: комментарий от Valmont

> Интересно, подвержены ли более старые версии glibc, типа 2.4

Если по ссылке таки сходить, то можно будет увидеть ту же проблему на rhel4u3 c glibc 2.3 %)

mv ★★★★★
()
Ответ на: комментарий от no-dashi

>У соляриса выбили из-под ног еще одну пузомерку? :-)

сравнение было линакс вс фряха. причем здесь соляра? на больную мозоль наступила?

aydef
()

в интерл правильные девелоперы сидят. эх, мне бы туда уехать... (ушел убивать себя об стену)

wieker ★★
()
Ответ на: комментарий от aydef

>сравнение было линакс вс фряха. причем здесь соляра? на больную мозоль наступила?

последнее сравнение было именно с соляркой
интересно а почему это не мешало ораклу первые места на tpc занимать на 128 ядрах ?

anonymous
()
Ответ на: комментарий от Oceanborn

>вот еще бы решил проблему с firefox наконец-то ;) Поставил аллокатор от openbsd все равно:

Мысль вслух: прикрутить бы к нему pool-аллокатор от Apache, и тупо выделять по пулу на страницу, чтобы с закрытием оной этот пул уничтожать...

AsphyX ★★★
()

Кетаец - мужик!

anonymous
()
Ответ на: комментарий от anonymous

>интересно а почему это не мешало ораклу первые места на tpc занимать на 128 ядрах ?

может он пользует свою собственную glibc?

anonymous
()

> Программист Intel нашел проблему масштабирования linux на SMP.

я так понял по тексту, что программист из интел нашел РЕШЕНИЕ проблемы масштабирования linux на SMP, сама по себе проблема была известна до него, поправить бы заголовок надо

anonymous
()
Ответ на: комментарий от soko1

> всего три строчки (см. патч) изменили мир к лучшему:)

Ещё не изменили -- пока только временная затычка, чтобы проверить справедливость гипотезы о виновности glibc.

baka-kun ★★★★★
()

Между прочим, первым, кто указал, что ошибка кроется в glibc, был не
программист Intel, Yanmin Zhang, а программист SAMBA, Anton Blanchard.
Он же и провел первый тест не с GNU libc-шной реализацией malloc: http://ozlabs.org/~anton/linux/sysbench/

Anton Blanchard
date Mar 13, 2007 1:00 AM
subject Re: SMP performance degradation with sysbench
mailed-by vger.kernel.org

Hi Nick,

> Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
> at this, send me a mail (eg. especially with the sched_setscheduler issue,
> you might be able to do something better).

I took a look at this today and figured Id document it:

http://ozlabs.org/~anton/linux/sysbench/

Bottom line: it looks like issues in the glibc malloc library, replacing
it with the google malloc library fixes the negative scaling:

# apt-get install libgoogle-perftools0
# LD_PRELOAD=/usr/lib/libtcmalloc.so /usr/sbin/mysqld

Anton

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

MaratIK
()
Ответ на: комментарий от MaratIK

Причем, это он проделал еще за неделю до китайца

MaratIK
()

Уберите из новости эти слова:

> нашел причину проблемы масштабирования Linux на SMP

иначе это будет вызывающе неверной информацией.

MaratIK
()
Ответ на: комментарий от MaratIK

"Новость" должна выглядеть так:

Программист Intel, Yanmin Zhang, прислал патч для glibc-2.5, исправляющий проблему масштабирования Linux на SMP, продемонстрированную красочными тестами с графиками провала роста производительности mysql на более чем 8-ми процессорах, которая так активно мусолилась весь предыдущий месяц.

Еще неделю назад, Anton Blanchard выяснил, что проблема оказалась вовсе не в ядре Linux, а в GNU libc (glibc), в функциях malloc/free.

ЗЫ: следовательно, новость в топку.

MaratIK
()
Ответ на: комментарий от wieker

Интел есть в москве, есть в томске, есть в новосибирске (думаю есть еще где-то, просто я не в курсе). Куда тебе приспичило ехать? icc пишут в том числе и в россии (значительный кусок девелоперов).

eXOR ★★★★★
()
Ответ на: комментарий от soko1

> всего три строчки (см. патч) изменили мир к лучшему:)

я как-то видел патч к коду на C++ который в одну строку и один kbiybq символ существенно изменил всю систему к лучшему, а тут целых три строчки...

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от eXOR

В нижнем новгороде еще есть, у меня туда знакомый уехал

anonymous
()
Ответ на: комментарий от eXOR

>Интел есть в москве, есть в томске, есть в новосибирске (думаю есть еще где-то, просто я не в курсе). Куда тебе приспичило ехать? icc пишут в том числе и в россии (значительный кусок девелоперов).

я знаю. просто так выразился.

wieker ★★
()
Ответ на: комментарий от MaratIK

Не прислал патч.

The patch is just to verify my idea instead of the final solution.

Пока это патч для проверки этой идеи. И еще не оттестировано на AMD.

jackill ★★★★★
()
Ответ на: комментарий от MaratIK

> MaratIK

Маратика несло и не попускало... :-)

dmesg
() автор топика
Ответ на: комментарий от aydef

>сравнение было линакс вс фряха. причем здесь соляра? на больную мозоль наступила?

на мозоль которая у тебя в голове, и уже в череп не вмещается, раз ты не осилил до сих пор как слово "линукс" писать надо

anonymous
()
Ответ на: комментарий от anonymous

> интересно а почему это не мешало ораклу первые места на tpc занимать на 128 ядрах ?

Потому что Oracle не потоками работает, а процессами (вроде бы) И Postgres тоже по-этому лучше MySQL-а масштабировался

funny_falcon
()
Ответ на: комментарий от MaratIK

> еще бы не помешало тему новости сменить.

Новость совершенно верная. Программист интел конкретно нашел конкретно участок кода с конкретной пролемой. Кто _до_ него нашел участок кода, где именно проблема? И где об этом можно почитать? А то вони от тебя много, а толку что-то мало.

dmesg
() автор топика
Ответ на: комментарий от klalafuda

>я как-то видел патч к коду на C++ который в одну строку и один kbiybq символ существенно изменил всю систему к лучшему, а тут целых три строчки...

А у меня как-то иногда одна ветвь проги не работала. Поправилось изменением одного символа. :)



Изменим жизнь к лучшему (с) см. выше

vada ★★★★★
()
Ответ на: комментарий от vada

>>я как-то видел патч к коду на C++ который в одну строку и один kbiybq символ существенно изменил всю систему к лучшему, а тут целых три строчки...

> А у меня как-то иногда одна ветвь проги не работала. Поправилось изменением одного символа. :)

неужели то-же '~' ?

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от baka-kun

> Ещё не изменили -- пока только временная затычка, чтобы проверить справедливость гипотезы о виновности glibc.

куда катится мир? код УЖЕ воспринимается как некий чёрный ящик, которому проще дать сигнал на вход (тестовый патч) и смотреть на выход (производительность), чем разобраться как ЭТО работает. и это OS!

LowLevel
()
Ответ на: комментарий от LowLevel

> код УЖЕ воспринимается как некий чёрный ящик, которому проще дать сигнал на вход (тестовый патч) и смотреть на выход (производительность), чем разобраться как ЭТО работает. и это OS!

хинт: кода много.

anonymous
()
Ответ на: комментарий от MaratIK

Да, malloc из google performance tools рвёт malloc из glibc на большом количестве процессоров. И это известно давно. Основная проблема с масштабируемостью программ (особенно написанных на C++ -- больно уж много работы с динамической памятью в стандартной библиотеке) на large SMP -- плохая масштабируемость malloc().

Всем, кто хочет знать, каким должен быть malloc для SMP -- вот сюда: http://google-perftools.googlecode.com/svn/trunk/docs/html/tcmalloc.html

iliyap ★★★★★
()
Ответ на: комментарий от wieker

>в интерл правильные девелоперы сидят. эх, мне бы туда уехать... (ушел убивать себя об стену)

Да-да, поедь к ним, и объясни что крепления для кулеров они делают говняные! И что процессор это "для считать", а не кремниевый нагреватель.

manokur ★★
()
Ответ на: комментарий от soko1

> всего три строчки (см. патч) изменили мир к лучшему:)

Это только PoC, а не final solution.

anonymous
()

"Порадовал" комментарий прямо перед пропатченными строками.

Выходит, что этот Yanmin "писатель" ;(

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.