2007/1/13, Дмитрий Леоненко <dmitry.leonenko@xxxxxxxxx>:
Улыбнуло это мнение...
По всем топам (а я их сюда кидал очень много) видно, что свободной
памяти
просто ПРЕДОСТАТОЧНО.
Этот вариант как раз наиболее невероятен... ИМХО
Кстати... а как mysql собран? Не знаю как посмотреть. НЕ должен быть
собран с linux_threads.
Расскажи, пожалуйста, поподробнее - почему именно mysqld не стоит собирать
с linuxthreads? К каким проблемам это приводит?
Я все Звуковские и часть РУ-Центровских серверов пользую собранными с
linuxthreads - каких граблей мне ожидать? В какой ситуации?
В 6-ке для mysql лучше использовать libthr, а - в 4-ке - linuxthreads.
А 5-ку лучше вообще не использовать :)
Спасибо, Игорь, но это - голые выводы.
А - хочется ещё и обоснований. Желательно - немного более развёрнутых, чем
"5-ка - это поломанная 4-ка, которую починили только к 6.0"
Какие именно грабли\траблы будут и как именно они будут проявляться? В каких
ситуациях?
В 5-ке у libpthread и libthr были всякие странности, а в 6-ке libthr by
Jeff Roberson была заменена на другую библиотеку by David Xu с тем же
названием. Она в общем опиралась на предыдущий код, но была существенно
переработана в части синхронизирующих примитивов - mutex'ов и condtion
variables, например, захват свободного mutex'а не требует перехода
в ядро. Причём измения делались с оглядкой на результаты mysql'ного
super-smack benchmark.
Граблей с linuxthreads на 6.x, скорее всего, не будет, а будет, скорее всего,
медленее. Дело в том mutex'ы и condtion variables в linuxthreads сделаны
на сигналах, что требует нескольких переключений контекста user/system.
Игорь Сысоев
