|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 08 Jan 2003 13:47:47
To : Konstantin Nikonenko
Subject : Re: FreeBSD & load avg >50
--------------------------------------------------------------------------------
>>> Konstantin Nikonenko wrote:
>> 5. попробовать собрать мускуль с linux-threads
KN> ой, а это зачем? во фре трэды уже давно получше/быстрее линуксовых.
Ой не надо сказок. Фрёвые треды в реализации libc_r в 4.x - ужас на крыльях
ночи и использовать их можно только в детской песочнице.
Hачнём с того что до сих пор не исправлена AFAIK потеря 1K на каждый созданный
тред (при join память не забирается обратно). Далее, дикие дурные пляски
вокруг O_NONBLOCK (так как uthread врапперы через него делают неблокирующие
сисколлы), порча этим O_NONBLOCK дескрипторов, разделяемых с другими
процессами, и от этого странные и дикие эффекты в этих других процессах.
Блокировка на незаврапленных сисколлах типа msgrcv(), которые конструктивно
невозможно заврапить в аналог select/poll/kqueue (а периодический поллинг
не реализован). Блокировка всего процесса на чтениях с диска и отсутствие
реализации read() через aio_read() даже там где aio_read() разрешён.
И прочая и прочая и прочая...
Hа LN крутятся мильтеровые фильтры под тяжёлой нагрузкой. Общее поведение
любого фильтра - разбухание до сотен мегабайт за день-два и схлопывание
по превышению rlimit'а на память - это из-за всё той же потери 1K на тред,
то есть на каждое входящее соединение. Thread pool мильтеровцы не умеют,
им это ни к чему, видите ли...
Mysql'ю пересборка с linuxthreads может оказаться полезной _реально_,
я данных привести не могу, но от коллег поступали сообщения, что это дало
существенное улучшение на нагруженных системах.
Hа слабонагруженных - да, с libc_r лучше, как по отсутствию лишних движений
админа, так и по невозможности mysql'ю пригнуть систему больше чем на один
процесс ;))
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
