imho.ws
IMHO.WS  

Вернуться   IMHO.WS > Веб-мастеру > Веб-программирование
Опции темы
Старый 09.01.2006, 15:24     # 1
AleXXXSoft
Guest
 
Сообщения: n/a

Question Странное поведение апача

Исходные данные:

Linux Debian Sarge, ядро 2.6.8-2-686-smp
Apache/1.3.33 (Debian GNU/Linux) mod_throttle/3.1.2

Сайт посещаемый (1500 уников, 15000 хитов), тут же на апаче реализован сервис скачки файлов, файлы льются подолгу, одноврменно льет около 100-150 человек, процессы спокойно висят жрать не просят, все работает. Каждый процесс апача весит около 6 метров, памяти хватает.

Проблемы:

Ни с того ни с сего (где-то день-два после рестарта) все чайлдовые процессы валятся в глубокий ступор... висят в топе с высоким приоритетом и в состоянии R, проц при этом скушан на 97%, load average всегда разный, но всегда необычно высок от 6 до 180... рестарт апача сразу помогает.

Некоторые настройки и подозрения на них:

Сперва думал что досят (слишком много форкалось апачей постоянно, поставил лимиты с помощью троттла - 10 запросов в секунду к закачке и 100 запросов в секунду ко всему сайту), все работало нормально, по статистике троттла лимиты превышаются периодически в 1.5-3 раза, он их отправляет на 503-ю, то есть все хорошо.

В конфиге:

Код:
Timeout 10
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 10

SendBufferSize 1048576

MinSpareServers 2
MaxSpareServers 7

StartServers 10
MaxClients 220
MaxRequestsPerChild 0
Потом пало подозрение на MaxRequestsPerChild - там было число около 200, то бишь чайлд отработав 200 запросов прибивался и запускался новый, так как чайлды висели подолгу (отдавая файлы) то их в такой ситуации копилось слишком много, и все падало, сейчас поставил ноль, то бишь не ограничиваю кол-во запросов на чайлда.

Собственно вопросик:

Сталкивался ли кто с таким, и как бороли?

P.S. Nginx и прочие легковесы для отдачи статики не предлагать, тут есть свои хитрости, ибо каждый байтик на счету, за него заплочены деньги клиентов.

В догонку:

только что в логе заметил, в момент последнего падения вот что:
server reached MaxClients setting, consider raising the MaxClients setting

я почему-то думал, что у меньшая это значение, апач не сможет насоздавать потомков больше, чем я указал.... или я не прав?
 
Старый 10.01.2006, 03:01     # 2
xse15
Junior Member
 
Регистрация: 16.03.2003
Адрес: 192.168.177.15
Сообщения: 78

xse15 Путь к славе только начался
Я у себя наблюдал подобное поведение при "глюках" с mod_perl и php. Причина была проста - "зацикливался" скрипт, а так как он исполнялся в embedded perl (под mod_perl) то, соответственно зависал потомок apache.
И как результат - 50-70 таких запросов - 50-70 залипших потомков. Что-бы обслужить новые запросы apache создает новые процессы и так пока не дойдет до 'MaxClients' процессов. а потом - апач работает, данные отдает, но новые запросы не принимает. и умоляет нас в логах - "consider raising the MaxClients setting"...
Вычислял "залипающие" скрипты с помощью /server-status. в его отчете видно что и какой процесс исполняет.
xse15 вне форума  
Старый 10.01.2006, 06:40     # 3
AleXXXSoft
Guest
 
Сообщения: n/a

ну да, файл отдается с помощью mod_php, он не зацикливается, но тем не менее, таймаут скрипта стоит 3600 сек (1 час) но за час ситуация не разруливается при зависании, жестких системных лимитов правда не стоит, может есть смысл поставить? я имею ввиду cpu time (seconds, -t) unlimited вот это

или сделать апачевский RLimitCPU? но как я понял он только на CGI влияет?

P.S. не хотелось бы нагружать апачик сервер-статусом... да я в принципе итак знаю, в каком месте виснет, вопрос только в странной периодичности...
все же попробую лимиты проставить...
 
Старый 25.01.2006, 10:59     # 4
AleXXXSoft
Guest
 
Сообщения: n/a

...
 


Ваши права в разделе
Вы НЕ можете создавать новые темы
Вы не можете отвечать в темах.
Вы НЕ можете прикреплять вложения
Вы НЕ можете редактировать свои сообщения

BB код Вкл.
Смайлы Вкл.
[IMG] код Выкл.
HTML код Выкл.

Быстрый переход


Часовой пояс GMT +4, время: 18:58.




Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.