On Tue, 25 Jun 2002, Alexey Zvyagin wrote:
> Вы сказали "Если число ждущих или соединённых фронтендов достигло
> максимума...". А вообще, возможно, чтобы пользователь получал 503 ошибку не
> тогда когда MC дошло до своего максимума или MW до своего, а тока тогда,
> когда MW дошло до максимума?
Нет, по крайней мере, в текущей реализации.
> Вот пример: у меня бекенд использует SQL, я не могу поставить MC более 25
> например, потому что буду знать точно, что будет больше persistent коннектов
> к базе, если бекендов будет более 30, а значит к SQL будет много в паралелль
> очередей, и ресурсы быстро будут истощятся. Поэтому мне хотелось бы, чтобы
> бекендов всегда было около 30. Но если я ставлю MC=35 например, то как тока
> коннектов 35, фронтенд сразу отдает 503 клиенту, несмотря на то, что может
> быть MW не достигло скажем своего максимума в 500, к примеру (я вижу, что
> фронтендов у меня обычно 1000, хотя и 2000 мог бы сервак потянуть, так как
> память сильно шарится...). Вот если бы фронтенд дойдя до пика в 35 коннектов
> к бекенду, не отдавал 503 пока не достигнет кол-ва процессов в базилоках до
> 500, мне кажется, было бы лучше, по крайней в той ситуации, когда 90%
> запросов - это динамические страницы с Pragma: no-cache и многие документы
> отсутсвуют в кеше. Я вижу, что бекенд мог бы разрулить больше запросов, так
> как чаще он недогружен, но вот фронтенд частенько сыпет в access.log 503
> ошибку клиенту.
>
> Уже проапгрейдил mod_accel до 1.0.20 (особых изменений не заметил), пробовал
> менять многие параметры, сильно оптимизировал SQL команды и бекенд уже не
> так нагружен. Но вот большинство запросов, например:
>
> /redir.cgi?quesry_string
>
> У меня летят на 503 ошибку, и все потому что:
>
> 1. Они не кешируемы, а значит многие прелести кеширования в устареванием
> ответов бесполезны
> 2. Сервер бы мог обработать в параллель условно говоря, несколько
> /redir.cgi?quesry_string, для этого я ставлю первые два параметра
> AccelBusyLock примерно в 2-3 секунды, и это помогает, но вот третий в
> параллель процесс мог бы подождать в базилоке, но как только коннектов к
> бекенду становится ровно как MC, так пользоатель видит 503. Тут все
> работать, как и задумано у вас и как описано в доке.
> 3. Без busylocks работает все хуже гораздо, но только потому, что фронтенд
> не скупится на соединения в бекендом. А много соединений уже просто
> расшатывают SQL по одновременным UPDATE, DELETE и SELECT командам. Когда
> коннектов тока около 20-30 то все работает шустро.
> 4. Хотелось бы, чтобы фронтенд в такой ситуации тоже ограничивал по
> соединениям бекенд, но как я уже сказал, выдавал 503 ошибку тока когда
> достигло MW своего максимума, а MC тоже ограничивалось, но при максимуме
> процессы ждали в базилоках до MW пика.
Прежде всего хочу заметить, что MC и MW разрабатывались для того,
чтобы загруженный бэкенд не забрал на себя все процессы фронтенда,
а не для того, чтобы ограничивать число процессов бэкенда. Число бэкендов
легко ограничивается на самом бэкенде.
Если бэкенд не может обработать больше 30 соединений одновременно,
то ему нужно поставить MaxClients 30 и всё.
В этом случае запросы фронтенда будут становиться в очередь,
длина которой равна backlog'у listen() на бэкенде.
Если фронтенд обслуживает ещё что-нибудь кроме этого бэкенда, то
MC можно поставить 500, для того, чтобы только эта часть запросов
ушла к бэкенду и осела в его backlog'е.
Backlog можно увеличить:
ListenBacklog 1000
ну и в OS его подкрутить, если он меньше нужного значения.
Игорь Сысоев
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
