ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] mod_accel - вопросы к разработчику и к тем, кто его использует



On Sun, Feb 10, 2002 at 07:32:59PM +0500, Alexey Zvyagin wrote:
> Евгению. возможно вы и правы, что тогда у меня количество процессов росло
> только из-за того, что Keep-Alive squid выставлял. Хотя в документации к
> squid и везде (сегодня просмотрел почти все топики про squid на их maillist
> архиве) нигде не сказано, что надо keep-alive отключать на backend-е и
> pconn_timeout в ноль. А если squid себя так ведет без этих поднастроек, про
> которые я услышал только от вас - это не в его пользу.

 А я вовсе не уверен, что дело в keep-alive. Это лишь гипотеза, хотя она
 порождает некоторые вопросы, например: если сквид действительно плодит
 keepalive-коннекции, то почему он их НЕ использует для НОВЫХ запросов?

 Ведь, казалось бы, естественное поведение должно быть таким: сквид сделал
 запрос, быстро проглотил ответ, шланг освободился для нового запроса от
 нового клиента, правильно? Тем более что в следующем абзаце Вы пишете, что
 виртуальных хостов всего 10, а не 10000, скажем. Логично ожидать, что
 keep-alive соединений между frontend'ом и backend'ом тоже должно быть чуть
 больше 10, если сквид лишь имена различает (на самом деле это не так, он
 различает ip-адреса, так что коннекций может быть еще меньше).

 Прежде всего следовало бы посмотреть server-status работающего апача -
 в каком состоянии находятся эти сотни деток? Если в "К" - верна моя гипотеза,
 если "W" - скорее Вы правы, и сквид почему-то не может засосать ответы.

 Следующим шагом может стать рассмотрение статистики сквида (via cachemgr.cgi).
 Там много всего... Для Вас могут быть интересны ссылки "Memory Utilization"
 (там должно быть видно, насколько забита память транзитными объектами),
 а также "Process Filedescriptor Allocation", "In-Memory and In-Transit
 Objects" и "Objects with Swapout files open".

 Можно заглянуть в "Persistent Connection Utilization Histograms", раздел
 server-side. Для правильно работающего акселератора следует ждать пик
 в районе max-keepalive сервера. Моя гипотеза соответствует пику в единице.

 Наконец, применение tcpdump - с целью выяснить окончательно, что именно
 тормозит - сквид или апач. Пока мне не покажут фрагмент с win=0, я не
 поверю, что тормозит сквид (и тогда уже встанет вопрос "почему?").

> Если меня устроит новая версия mod_accel, то забуду о squid, а иначе вернусь
> к нему и посмотрю. Все таки переконфигурить снова 10 виртуальных сайтов, на
> которые народ ходит каждую секунду ради эксперимента не хочу сейчас.

 А не надо СРАЗУ конфигурить 10 сайтов, ставить их под полную нагрузку и
 пытаться разобраться в этой каше. :) Можно сначала поставить сбоку от
 Вашего сайта squid-accel, 2-3 медленных клиента, и посмотреть, что там
 происходит. Если дело не в недостатке памяти сквида, а в дефектном алгоритме
 работы с backend'ом - наверняка это проявится и в такой конфигурации.

 PS. Я вовсе не собираюсь разводить агитацию за сквид, который у Вас,
 наверное, давно в печенках сидит. Но если Вы доведете дело до bug report,
 или до абзаца в FAQ, это уже будет польза.
-- 
 Eugene Berdnikov
=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.