Linux за българи: Форуми

Имам една машина с апаче и sql, но често умира поради надвишен брой едновременни заявки. Опитвам да вдигна числото от 256 на по-голям, брой, но ми връжа това:

WARNING: MaxClients of 1024 exceeds compile time limit of 256 servers,
 lowering MaxClients to 256.  To increase, please see the
 HARD_SERVER_LIMIT define in src/include/httpd.h.

Някакви идей? Предварително благодаря.

каква е версията на apache ?

Идеите са следните

не обичаш да четеш какво ти казва софтуер.

В превод ... Апача ти е компилиран с МАКС 256 едновременни клиента повече от това не можеш да дигнеш.

Решение ... прекомпилирай си го със вдигнат лимит

zeridon, ти също не четеш всичко но както и да е.

От общи наблюдения и обща култура:

* apache не умира поради надвишен брой заявки. Просто клиентите, уцелили неподходящият момент  биват "отрязвани".
* 256 едновременни заявки не са малко, въпреки че това е доооста отностително казано, но да кажем че за един уебсървър хостващ 50-ина фирмени сайта (name-based vhosts), рядко съм виждал над 30-40 едновременни заявки. Естествено, зависи и от популярността на сайтовете де.
* Ако все пак наистина са толкова, имаш ли наблюдения за колко време средно се обслужва една заявка? "Влаченето" може да се дължи на "затормозена" работа с SQL backend-a на уеб приложенията ти. Ако те чакат примерно 60 секунди да завърши един прост SELECT, то определено по-добре е да си оптимизираш таблиците в базата, отколкото да вдигаш максималния брой клиенти. В противен случай, рано или късно ще чукнеш момента, в който ще ти свърши паметта и ще стане грозно. А може би пък РАМ-та точно е проблема, навлизаш в swap-a и заради това всичко се бави?
* Дори netstat може да ти каже дали това не е някакъв тъп опит за DoS, при положение че 9/10 от заявките са от един и същ адрес например, нещата са доста съмнителни.
* Без да вдигаш MaxClients, можеш да вдигнеш ListenBackLog-a, така клиентите няма да се "дроп-ват", ами ще чакат докато се освободи някакъв worker да ги обслужи
* Както каза teh, важна е версията, защото 1.3 по спомени форк-ваше по един процес за всеки request. При 2.0/2.2 моделът е малко по-различен, както и конфигурационните директиви са по-различни. Има варианти вместо процеси да се използват нишки, което спестява много процесорни и РАМ мъки по копиране на данни в паметта, както и по отношение на context switching-a, особено при 2.6 където атомарната единица на task scheduler-a е нишката, не процеса (NPTL / грубо казано). Нещата всъщност не са дори толкова прости, но ще стане дълга тема за разговор ако трябва да се обсъжда, така че за това - дотук.
* 99% сигурен съм че не се нуждаеш от вдигане на MaxClients, а от друго решение, но както и да е. Прекомпилиране на apache с други #define-s е тегава и впоследствие водеща до потенциални проблеми операция. Ако си slackware или BSD потребител, сигурно си свикнал, но повечето хора, включително мене, трудно биха го възприели.

Решението си е твое

Именно! Но питащия не пожела да сподели версията си.

За да се отърве от лимита на 256 сървъра (което при apache 2.0/2.2 използващи prefork(1) модела е равно и на реално максималния брой клиенти които уеб сървърът може да обслужи) той просто трябва да избере друг модел - за препоръчване е т.нар. worker(2) модел.


1. http://httpd.apache.org/docs/2.2/mod/prefork.html
2. http://httpd.apache.org/docs/2.2/mod/worker.html

BTW, напоследък малко съм излязал от тия неща и не съм много запознат. Има ли вариант apache да обслужва няколко завки от един workthread (не процес) едновременно ?!? В 2.0 не можеше, но на 2.2 за MPM-то не съм много сведущ?

От край време си има select()/poll() механизми, може да са скапани, но има epoll варианти, които преодоляват недостатъците им.

Въпроса ми е защото съм се пробвал да си пиша http load-balancer, който използва смесен модел (бройка нишки обслужват собствен epoll set от клиентски сокети). Опитът беше катастрофален, защото когато една нишка си заключваше мутекс-а (не ползвах pthread възможностите, реших да си правя собствен locking механизъм с (хах) глобални променливи), тогава всички останали нишки "спят" , съответно голяма част от клиентите, които се обслужват чакат. Въпреки че се ползват non-blocking сокети (иначе щеше да е убийствено), пак не е достатъчно - тъпата ми реализация караше когато пристигне нова заявка, всички останали клиенти да чакат, докато се осъществи TCP сесия с backend-a например. И най-вече поради тъпо измислен локинг механизъм понеже за да не хабя памет, нишките си споделяха повече структури от данни, отколкото трябва - например една голяяяма таблица със SESSIONID-та и информация за бекендите асоцирани със сесията (stick-вам бекенд-ите по някакво SESSIONID от Cookie: полето, така че заявките да не ходят на машини, които не знаят за такава сесия, както  и rewrite-вам някои Host: хедъри). В края на краищата, моят "load-balancer" държеше по-малко едновременни заявки отколкото всеки един от apache backend-ите, които бяха с 2.0 и вдигаха по нишка на заявка, което ужким трябваше да е проблем заради многото context switching. Тестовете ги правих с httperf.

Та интересно ми е, ако в apache са реализирали подобен механизъм, който на теория би трябвало да е прекрасен вариант, как точно са си решили проблемите с конкурентността?

За нишките при 2.2 почти всичко е обяснено:

http://mail-archives.apache.org/mod_mbox/ofbiz-user/200612.mbox/thread
http://httpd.apache.org/docs/2.2/misc/perf-tuning.html

А верно кой Apache е?

Здавейте,

Благодаря на всички за отговорите и идеите!
Версията е Apache/1.3.33, kernel 2.4, slackware 9.0

MySQL е ок вече, оптимизация на базите...
Проблем има само с АПАЧА, които не умира, а просто остава > 256-та канекция на там да чакат. Което е неприятното. Смятам да прекомпилирам АПАЧА с по-нов и съответно с по-голямо число за MaxClients. Хардуера го позволява.

На сървъра има 10-тина сайта, но от скоро има и торент и от там големия интерес, особено след като подгониха големите тракери

Още веднъж благодаря!