Какой сервер нужен для поиска по большой базе MySQL?

Ааа. Понятно. Знакомые грабли.

Не знаю конечно, что за софт используется, может ему это действительно нужно, но, как показывает практика, использование pconnect приводит только к перерасходу памяти, не давая ничего взамен.

Рекомендую использовать простой connect и будет счастье.

да в том-то и дело, что раньше использовался connect

и после простановки везде pconnect уменьшилась нагрузка на 20-30% на серв

может и странно,но факт

p.s. стоит max_connections=1000 , хватает ,

если сделать меньше , то юзеров просто не пускает на сайт

может, у Вас до этого была вот именно такая пролблема, поэтому и

кажется , что connect лучше...

мнения в Рунете по этому поводу расходятся

Куда столько? Вот и нету памяти.

На сайт что, заходит одновременно 1000 человек и открывается 1000 коннектов к базе? Что это за сайт такой? ;)

Реально с одной страницы обычно открывается один коннект к базе, независимо от количества генерируемых ею запросов, скрипт отработал - коннект грохнулся автоматом, память освободилась. Если использовать pconnect то он не грохается, а остается висеть и только занимает память.

Для примера у ресурса с посещаемостью 10к хостов в сутки Max used connections=40 при трехсуточном аптайме.

my.cnf

max_connections = 150

table_cache = 768

key_buffer_size = 1000M

sort_buffer_size = 256M

read_buffer_size = 256M

read_rnd_buffer_size = 256M

join_buffer_size = 256M

tmp_table_size = 2000M

query_cache_limit = 64M

query_cache_size = 256M

Объем БД ~2.4GB, но вся база и индексы помещаются в ОЗУ (6гб) pconnect-ы не используются.

Вот LA сейчас глянул: 1.36, 1.85, 2.01. Серв-2 x XEON

Тут мне сделали справедливое замечание, что указание tmp_table_size без max_heap_table_size не очень осмысленно, ибо выбирается меньшее значение, так что исправляюсь:

tmp_table_size = 2000M

max_heap_table_size = 2000M

Хотя особого смысла во временных таблицы в два гига нет. У меня эта настройка осталась после каких то игрищ с мускулом и поскольку реальная цифра была 16М то соответственно не использовалась.

онлайн около 500 человек вечером, по 2-5 запросов на каждого...

pconnect открывает соединение и потом не закрывает в конце запроса, следующий юзер по точно такому же запросу уже не нагружает базу, а использует данные из первого, если такой запрос не последовал в течение 20 секунд, данные убиваются...

а connect каждый раз коннектится, закрывает и т.д.

Вообще с кешем в my.cnf надо помудрить, как у Вас... может, и connect нормально заработает,

на 2 Гб оперативки и Xeon какие параметры могут быть оптимальны?

у Вас на 6 гб и 2 ксеона..

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

Но это вовсе не означает, что все 500 юзеров одновременно генерят запросы к базе. Вероятность того, что все они синхронно нажмут кнопку "Read" итп крайне мала. Все равно запросы даже от такого количества пользователей будут размазаны во времени и закладываться на такое количество коннектов нет никакого смысла.

pconnect всего лишь навсего не закрывает соединение и более ничего. Он ничего не кеширует. И если следующий запрос будет повторять предыдущий, то данные отдадутся из query cache, если он включен, к pconnect-e это не имеет никакого отношения. Какой либо выигрыш от использования pconnect-а может получиться только при огромном (десятки тысяч в сек?) количестве запросов на соединение с базой. В Вашем случае столько точно нет. С другой стороны, если созданные соединения по какой либо причине не будут использоваться повторно, а будут создаваться все новые и новые, то память кончится очень быстро. Возможно именно в этом и дело. Посмотрите в статсах количество коннектов и их максимальное количество. Последите за этими цифрами. Выключите на несколько минут http сервер и посмотрите.

А если есть желание что-либо кешировать, то на query cache лучше много памяти не тратить, а использовать например ADODB и кешировать все на диск. Очень полезная штука.

http://adodb.sourceforge.net/#docs