|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 08 Jan 2003 23:09:16
To : Konstantin Nikonenko
Subject : Re: Threads (was: Re: FreeBSD & load avg >50)
--------------------------------------------------------------------------------
>>> Konstantin Nikonenko wrote:
>> Ой не надо сказок. Фрёвые треды в реализации libc_r в 4.x - ужас на
>> крыльях
>> ночи и использовать их можно только в детской песочнице.
KN> [сами ужасы skip-нуты]
KN> все как бы в сравнении ;) наверняка Вы помните времена 2.2.X - там было
KN> лучше? ;)
Hу, хуже. И что с того? Сравнивать-то предлагали с linuxthreads.
KN> в линухе вообще сделали workaround, а не реализацию.
У линуховой реализации не так много проблем.
KN> Я не готов обсуждать
KN> частности,
KN> но со слов Igor Khasilev ситуация с год назад была следующей - solaris,
KN> freebsd, linux.
У Хасилева очень ограниченные запросы, извините за откровенность.
Oops - самостоятельный демон (=> нет проблем с разделением дескрипторов
с nonblocking), у него собственный worker thread pool (сделанный ради солярки,
но пригодившийся для всех), нет SysV, простые виды взаимодействий (не
требуется SysV IPC), и он не пожалел применить aio там, где оно есть.
То есть все основные грабли libc_r он аккуратно обошёл, пусть даже и не имея
такой цели.
>> Mysql'ю пересборка с linuxthreads может оказаться полезной _реально_,
>> я данных привести не могу, но от коллег поступали сообщения, что это дало
>> существенное улучшение на нагруженных системах.
KN> наверное даёт, т.к. работает уже другой механизм, реализованный, возможно,
KN> аккуратнее.
даёт потому, что разные видимые ядру задачи могут параллельно работать
с диском. libc_r это даёт только при aio, mysql не использует aio.
>> Hа слабонагруженных - да, с libc_r лучше, как по отсутствию лишних
>> движений
>> админа, так и по невозможности mysql'ю пригнуть систему больше чем на один
>> процесс ;))
KN> Память течет и это очевидно. Hаблюдал несколько раз отстрел того же oops
KN> из-за этого,
KN> но падать сам он уже перестал ;)
KN> Согласен с тем, что нынешние фри! реализации для песочницы, но для подобных
KN> нагрузок есть та же соляркa, причем под sun only ;)
Да там ещё очень далеко было до тех нагрузок, когда надо спарка ставить.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
