форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Обеспечение работы системы монитори..."

Сообщение от auto_tips on 14-Окт-08, 13:52

Web-сервер apache наверное самый лучший web-сервер, но при настройке web-интерфейса для nagios можно обойтись и без него, что сейчас и будет описано. Применительно к FreeBSD:    portinstall /usr/ports/www/nginx В /etc/rc.conf.local    # nginx    nginx_enable=YES nginx не может выполнять php и cgi скрипты. Для этого можно использовать backend серверы. Схема получается следующая:                                       mini_httpd                     ---*.cgi--->  192.168.0.200:1081                    /       nginx       /                    lighttpd 192.168.0.200:80------*.php--->   192.168.0.200:1082                   \                    \                    Каталог                     ---*.html-->  /usr/local/www/... В этой схеме nginx слущает на порту запросы, производит авторизацию, статические файлы отдает сам, cgi-скрипты перенаправляет к запущенному на внутреннем порту 127.0.0.1:1081 mini_httpd (/usr/ports/www/mini_httpd), который в свою очередь и выполняет эти скрипты. Схема может показатся сложной, но в моём случае переход на нее оправдался: опрос nagios производится 1 раз в минуту из Firefox (спец.плагин), и машина с nagios испытывала некоторые трудности с производительностью. После запуска данной схемы нагрузка на машину значительно снизилась. Если используется pnp4nagios (http://www.pnp4nagios.org/pnp/install) для построения графиков производительности сервисов, то выполнение php-скриптов возможно с помощью запущенного на внутреннем порту 127.0.0.1:1082 lighttpd (/usr/ports/www/lighttpd). Конфигурационные файлы nginx хранятся по умолчанию в /usr/local/etc/nginx/. /usr/local/etc/nginx/nginx.conf    user       www www;    worker_processes  1;    error_log  /var/log/nginx/error.log;    pid        /var/run//nginx.pid;    worker_rlimit_nofile 8192;    events {       worker_connections  4096;    }    http {     include    mime.types;     include    proxy.conf;     default_type application/octet-stream;     log_format   main '$remote_addr - $remote_user [$time_local] $status '                       '"$request" $body_bytes_sent "$http_referer" '                       '"$http_user_agent" "$http_x_forwarded_for"';     access_log   /var/log/nginx/access.log  main;     sendfile     on;     tcp_nopush   on;     server_names_hash_bucket_size 128; # this seems to  be required for some vhosts    ## интранет   server {     listen 192.168.0.200:80;     server_name 192.168.0.200 ns.contora.local;     access_log /var/log/nginx/access.log;       include nagios.conf;       include nagios-pnp.conf;     location / {         root                    /usr/local/www/apache22/data/;     }     include error-pages.conf;    }   } /usr/local/etc/nginx/nagios.conf    location /nagios/ {         auth_basic              "Nagios ";         auth_basic_user_file    /usr/local/www/nagios/.htpasswd;         alias                   /usr/local/www/nagios/;    }    location /nagios/cgi-bin/ {         auth_basic              "Nagios ";         auth_basic_user_file    /usr/local/www/nagios/.htpasswd;         proxy_pass              http://localhost:1081;         proxy_redirect          http://localhost:1081/nagios/cgi-bin/ /nagios/cgi-bin/;         set                     $referer        $http_referer;         proxy_set_header        Referer         $referer;         proxy_set_header        X-Real-IP       $remote_addr;         proxy_set_header        Host            localhost:1081;         proxy_set_header        REQUEST_METHOD  $request_method;         proxy_set_header        REMOTE_USER     $remote_user;         proxy_set_header        REMOTE_ADDR     $remote_addr;         proxy_set_header        SERVER_NAME     localhost;         proxy_set_header        SERVER_PORT     1081;         proxy_set_header        HTTP_COOKIE     $http_cookie;    } /usr/local/etc/nginx/nagios-pnp.conf         location ~* /pnp/.*\.php$ {             root   /usr/local/share/;             fastcgi_pass   127.0.0.1:1082;             fastcgi_index  index.php;             fastcgi_param  SCRIPT_FILENAME  /usr/local/nagios/share/$fastcgi_script_name;             include        fastcgi_params;         }         location ~* /pnp/ {                 root   /usr/local/nagios/share/;                 index  index.php index.html index.htm;         } /usr/local/etc/nginx/error-pages.conf         error_page   500 502 503 504  /50x.html;         location = /50x.html {          root   /usr/local/www/nginx-dist;         }         error_page   401  /401.html;         location = /401.html {           root   /usr/local/www/nginx-dist;         }         error_page   404  /404.html;         location = /404.html {           root   /usr/local/www/nginx-dist;         } Ссылки: http://sysoev.ru/nginx/ http://www.lighttpd.net/ http://www.acme.com/software/mini_httpd/ http://www.lissyara.su/?id=1532 URL: http://opensolution.org.ru/nagios/nginx Обсуждается: http://www.opennet.dev/tips/info/1795.shtml

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по ответам | RSS]

	1. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от rusty_angel on 14-Окт-08, 13:52
	Зачем городить nginx<->lighttpd<->php, если nginx сам может с php по FastCGI общаться?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	2. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Gular (ok) on 14-Окт-08, 15:16
	Правильно. Либо lighttpd использовать один. Насколько процесс nginх меньше занимает, чем lighttpd?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от rusty_angel on 14-Окт-08, 15:21
	>Правильно. Либо lighttpd использовать один. >Насколько процесс nginх меньше занимает, чем lighttpd? Не сравнивал. Лайти постепенно превращается (да если честно - уже превратился) в апач с кучей модулей, и он, если мне не изменяет склероз, threaded, поэтому я использую либо nginx либо nginx+apache.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от одмин on 14-Окт-08, 16:16
	никогда он не был threaded.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Anton (??) on 14-Окт-08, 16:26
	лайти - глюкалово еще то.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от rusty_angel on 14-Окт-08, 16:42
	>лайти - глюкалово еще то. Мы просто готовить его не умеем. Вот в Wikimedia Foundation - умеют.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от rusty_angel on 14-Окт-08, 16:43
	>никогда он не был threaded. Значит ошибаюсь.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Anton (??) on 14-Окт-08, 16:49
	безотносительно к викимедии, посмотрите на кл-во security updates в Debian дляlighttpd и для nginx.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "Обеспечение работы системы мониторинга Nagios при помощи Ngi"
	Сообщение от uldus (ok) on 14-Окт-08, 16:55
	>Зачем городить nginx<->lighttpd<->php, если nginx сам может с php по FastCGI общаться В Nagios нет PHP, там CGI на Си написаны и скомпилированы. Другое дело, что для таких CGI, как в nagios без разницы с точки зрения производительности/расхода памяти на чем их пускать, на по максимуму урезанном apache или на nginx/lighttpd, там же коннектов единицы, keepalive поменьше сделать и все будет ok.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от rusty_angel (ok) on 14-Окт-08, 17:02
	>безотносительно к викимедии, посмотрите на кл-во security updates в Debian дляlighttpd и >для nginx. А если помножить эти количества на "долю серверов на рынке"? :) Я не защищаю лайти, у самого с ним отношения не сложились: пробовал как-то, и он тёк по-чёрному. Просто объективным быть хочется.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Anton (??) on 14-Окт-08, 17:41
	http://survey.netcraft.com/Reports/200809/ А мы задолбались с этим лайтим уже. По историческим причинам его используем как реверс-прокси, переходим постепенно на энджинкс.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от User294 (??) on 14-Окт-08, 19:46
	>threaded, поэтому я использую либо nginx либо nginx+apache. Лайт не запускает по треду на юзера - какой он нафиг threaded? В нем есть несколько тредов для разных операций.И только.А то так и nginx можно обозвать форкающим - он же может несколько worker-процессов форкнуть.А то что один процесс обслуживает ораву народа можно и не уточнять :) P.S. схема предложенная тут - оверкилл.Вижу следующие тупняки: 1) PHP можно выполнять через fast-cgi которое nginx умеет.Более того, только через фаст его и надо цеплять т.к. через просто cgi - тормознуто и отстойно. 2) lighttpd если уж его вкорячили умеет и fast-cgi и просто cgi.Если уж CGI натурально надо.А надо оно обычно только для совместимости с старьем которого в другом виде нет.CGI пользоват не стоит потому что его логика работы тормозная по определению (форк процесса для обслуживания запроса). Итого: зачем 3 сервера если можно обойтись одним (все спихнуть на один lighttpd) или, если его буферинг вывода от CGI напрягает (если вы будете таким макаром стримить исошку - памяти выжрется немеряно, что логично) - как максимум, двумя серверами?А нафиг три?Вам не влом будет поддерживать весь зоопарк?Следить за обновлениями, дырами, etc?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от User294 (??) on 14-Окт-08, 19:49
	>лайти - глюкалово еще то. У меня работает как часы на нескольких серверах уже более года.Я что-то делаю не так?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от User294 (??) on 14-Окт-08, 19:52
	>как реверс-прокси, переходим постепенно на энджинкс. Лайт по-моему не особо интересен как реверс-прокси.В этом плане нжинкс явно сильнее.А вот если надо самостоятельный легкий сервер который сможет в разы больше чем апач на том же железе - все с точностью до наоборот, потому что nginx нифига кроме fastcgi не умеет а это порой икается.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "Обеспечение работы системы мониторинга Nagios при помощи Ngi"
	Сообщение от User294 (??) on 14-Окт-08, 20:03
	>урезанном apache или на nginx/lighttpd, там же коннектов единицы, А это от доброжелателей не зависит?А то если оно извне доступно... апачи очень любят когда им на хилой тачке обламывается несколько сот конекций :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Anton (??) on 14-Окт-08, 21:38
	не нагружаете его
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "Обеспечение работы системы мониторинга Nagios при помощи Ngi"
	Сообщение от uldus (ok) on 14-Окт-08, 23:18
	>>урезанном apache или на nginx/lighttpd, там же коннектов единицы, > >А это от доброжелателей не зависит?А то если оно извне доступно... апачи >очень любят когда им на хилой тачке обламывается несколько сот конекций >:) Кто же систему мониторинга из вне доступной делает, если и делают то с аутентификацией, хитрой точкой входа и лимитом на число соединений.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от User294 (??) on 14-Окт-08, 23:39
	>не нагружаете его Да?Тут как-то сказочники рассказывали про утечки памяти при нагрузке.Ну так вот, я из интереса прогнал тест под нагрузкой с пристрастием - порядка 10 000 000 запросов файлов весом по 10Мб.Двести конекций в параллель, утилиткой http_load из комплекта thttpd (весьма веселый тул который может оперативно и демонстративно отправить в нокаут апача, особенно он на не очень крутой машине, впрочем не только апача - можно доставить веселья любому threaded или fork-based приложению).При этом достигнутая в случае использования локалхоста скорость отгрузки была порядка 9Гбит (весьма заметный процент скорости RAM машины!).Если это не нагрузка - то я пас.Мне как-то больше честное слово, не нужно и в ближайшее время не понадобится(ну не гугл я, не вики и не youtube :D).И что-то я не понял что там должно было работать не так.Память не текла, ничего не падало.Хм.Может быть благородные доны тогда приведут какой-то конкретный пример конфигурации в которой проблемы, версию лайта и прочая?Или под нагрузкой имеется в виду что-то иное?Как минимум статику лайт отгружает тоннами без каких либо проблем по моим наблюдениям.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Anton (??) on 15-Окт-08, 00:12
	>Да?Тут как-то сказочники рассказывали про утечки памяти при нагрузке. Лично фиксил memory-leak. Дальше читать не стал.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Anton (??) on 15-Окт-08, 00:38
	дочитал ) 200 параллельных соединений -- это не много, конечно. Надо хотя бы тысячу.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	21. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от rusty_angel (ok) on 15-Окт-08, 00:41
	9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел девять гигабит? Я думал, такие только на лоре встречаются.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	22. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Anton (??) on 15-Окт-08, 01:39
	>9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел >девять гигабит? Я думал, такие только на лоре встречаются. Я так понял, что это на одном хосте вообще происходило.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	23. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от User294 (ok) on 15-Окт-08, 02:22
	>9Gb говоришь? На каких таких дисках и каких таких сетевухах ты имел >девять гигабит? Я думал, такие только на лоре встречаются. Это был локалхост с 2 ядрами + порядочно оперативы (5Gb).Файло в итоге весьма быстро забуферилось в дисковый кэш а нагрузка от http_load и лайта честно размазалась на 2 ядра, оба жрали примерно поровну CPU. Сетевухи на данную скорость разумеется не было - данные гонялись по локалхосту чтобы посмотреть "а что оно вообще может выжать?" и ускорить по максимуму процесс тестирования на утечки памяти (а вы не заколебетесь ждать пока 10 000 000 запросов 10Мб файлов пропихнутся в реальную сетевуху доступную простым смертным?На гигабите ждать почти вдесятеро дольше в идеальных условиях.А данные сервак 1 фиг одинаково в сокеты пихает - несмотря на синтетичность теста для отлова memleaks он мне кажется ОК).Единственное но - версия была не очень древняя (1.4.18 если не ошибаюсь).А модулей было не особо много.В конце концов меня интересовала именно стабильность и текучесть лайта а не туевой хучи его модулей которые несколько отдельный разговор (текучесть и бажность конкретного модуля это все-таки не текучесть лайта самого по себе, IMHO).Почему 200 конекций?Потому что бОльшее число конекций уже не увеличивало скорость теста а то и делало хуже.В реальной жизни 200 постоянных конекций на сайте еще постараться огрести надо.Это не проблема только для YouTube какого-нибудь да порно-варезных сайтов разве что.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от rusty_angel (ok) on 15-Окт-08, 02:39
	Судя по всему, файлов немного. Не катит, имхо, для тестов. Надо много файлов, разных, плохо кешируемых. Хотя я не знаю, что именно тогда текло (давно было, в каких-то 1.3.х версиях, если не ошибаюсь), может Ваш-то тест и выявил бы тот лик. Сейчас поправили наверняка. Осадок просто остался, а с nginx я лучше, чем с лайти умею обращаться, вот и всё. Получить 200 коннектов - не такая уж проблема. Хотя от специфики сильно зависит. Один "мой" (в кавычках - потому что не мой, я его только под нагрузки оптимизировал и чуть-чуть по мелочам доделывал) столько имеет на единственном сервере, а с другой стороны хостинговые серверы с двумя-тремя сотнями сайтов, с которыми я непосредственно по работе вожусь, редко имеют больше  60-80 параллельных коннектов.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Basov E. on 15-Окт-08, 16:04
	http://balancer.ru/forum/ работает на lighttpd. Статистику нагрузки можно посмотреть к примеру тут http://www.mapyourvisitors.com/map2537.php
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Anton (??) on 15-Окт-08, 17:55
	речь о высокой нагрузке.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	27. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от User294 (??) on 15-Окт-08, 22:14
	>Судя по всему, файлов немного. Штук 20. Цель была сгенерить много запросов т.к. тогда пипл утверждал что течет на каждый запрос - вот это и хотелось проверить.Проверил.Для как минимум базовой части сервака и несложного набора модулей и свежей на момент тестов версии 1.4.18 - не подтвердилось. >Не катит, имхо, для тестов. Тесты бывают разные.Если цель теста - посмотреть как сервак поведет себя на большом числе запросов и не потечет ли память - по-моему, мой тест вполне адекватен.Как минимум, гипотеза что lihgttpd сам по себе смущает большое число запросов - не подтверждается.Может быть тек какой-то модуль или при каких-то настройках или при специфичных запросах?Или сто лет починено, поскольку при раздаче файла вики и ютубом они должны были бы мягко говоря заметить саму по себе утечку памяти на отгрузке файла - при их объемах отгрузки она должна быть ДИКАЯ :) >Надо много файлов, Кому надо?Зачем?И что это даст?Не вижу почему если память не течет на 20 файлах то вдруг потечет на 200 или 2000 или сколько там еще?Я где-то не прав?Что изменится? >разных, плохо кешируемых. Плохо кешируемых?А что это даст для такого теста?Кроме тормозов.Ну, скорость проведения теста замедлится в несколько раз.А что от этого изменится в условиях работы программы?В конечном итоге файл читает система по системному вызову.Попало оно в дисковый кэш или нет лайт вообще по идее не знает - его дело маленькое, нужные системные вызовы дернуть.А попало оно там в кэш или нет - вообще не его дело в общем случае. >Хотя я не знаю, что именно тогда >текло (давно было, в каких-то 1.3.х версиях, если не ошибаюсь), может >Ваш-то тест и выявил бы тот лик. 1.3.x я не использовал.Начал его юзать эээ ... с версии 1.4.13, чтоли.А тестил лик на 1.4.18 - что-то не натестилось нифига.Недавно они кстати прибили забавный лик при duplicate хидерах в HTTP запросе, кажись.Но это уже экзотика. >Сейчас поправили наверняка. Осадок >просто остался, а с nginx я лучше, чем с лайти умею >обращаться, вот и всё. Судя по списку рассылки в нжинксе тоже есть много разных интересных багов и еще больше разных интересных багов поправлено :-).Почему-то у народа часто и красочно падают воркеры например.Я правда такого не встречал(но если честно то особо и не злобствовал - специальных краш-тестов не проводил).Правда я больше лайт юзаю, т.к. в моих конфигурациях никаких граблей у меня нет. >Получить 200 коннектов - не такая уж проблема. Хотя от специфики сильно >зависит. Хм.Для обычного сайта простого смертного это подразумевает популярность здорово выше средней.Для такого как правило надо как попасть на слэшдот или что-то типа того. >а с другой стороны хостинговые серверы с двумя-тремя сотнями сайтов, >с которыми я непосредственно по работе вожусь, редко >имеют больше  60-80 параллельных коннектов. Ну вот и я о чем. P.S. апача с префорком кстати данный тест выносит в хлам, особенно если файлы не 10 Мб а поменьше.Ему как правило становится очень нехорошо от форка на скорость 200 процессов.А на хилой машине они еще и сжирают всю RAM если админ не ограничил число процессов :D
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	28. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от rusty_angel (ok) on 16-Окт-08, 07:56
	> >P.S. апача с префорком кстати данный тест выносит в хлам, особенно если >файлы не 10 Мб а поменьше.Ему как правило становится очень нехорошо >от форка на скорость 200 процессов.А на хилой машине они еще >и сжирают всю RAM если админ не ограничил число процессов :D > Апач тоже надо уметь готовить. В Яху это делать умеют, к примеру. По своему опыту могу сказать, что кроме экстремальных случаев, апач нифига не хуже лайти или nginx. Только процессов больше и top кажется более катастрофическим. Реально нагрузка на железку не сильно отличается.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	29. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от User294 (ok) on 16-Окт-08, 08:38
	>Апач тоже надо уметь готовить. Угу, обычно эта готовка сводится к тому что на сервер тупо впихивают дофига оперативы под зиллионы тредов или процессов апача и хренадцать процессоров.Спасибо, я гайд по оптимизации апача читал - после его прочтения сложилось стойкое ощущение что они борятся с проблемами которых у других изначально нет.Да и то что нагруженные сайты уважают лайт и нжинкс наводит на такие мысли. >В Яху это делать умеют, к примеру. Будучи яхой можно позволить себе парк серверов пожирнее, кучу процессоров, оперативки дофигища и прочая.И там даже апач может вольготно форкать свое добро в свое удовольствие. Но случаи бывают разные.Например, на VDS больше оперативки == больше цена.Или вон та машина - уже есть и оперативки в ней вот столько и баста.Ну и так далее.Так по опыту - если оперативка ограничена, с апачом все сводится к двум вариантам: или неограниченый форкинг или трединг выжирает RAM или, если ограничить число воркеров, как только число соединений растет - все начинает работать медленно и печально.Что в общем то чертовски логично и предсказуемо.С другой стороны, лайт или нжинкс и на такой конфигурации пашут крайне ядрено.Так что завалить их параллельными даунлоадами на такой конфигурации... нуууу... это будет нелегко.Им на доступный объем оперативки как-то пофиг почти из-за особенностей конструкции. >По своему опыту могу сказать, что кроме экстремальных случаев, апач нифига >не хуже лайти или nginx. Смотря что считать за экстремальный случай.Видел дофига случаев когда замена апача на лайт или нжинкс буквально вдыхала в хилый и медленный сервак новую жизнь - он после этого становится уже ни разу не хилый и не медленный.А если вы корпорация яху - конечно фигня вопрос - ставим побольше серваков понавороченнее да и все дела.Только вот такой подход для простых смертных зачастую не катит потому что для этого требуется толстый кошелек. >Только процессов больше и top кажется более катастрофическим. Ага, а оперативка тоннами случайно не жрется заодно?Или это только кажется?На отдаче статики в большинстве случаев лайт и нжинкс вообще апача обидят с неприятным для него счетом, имхо :).А то у неподготовленных админов с не очень крутыми серверами апач если туда пустить http_load своими сотнями процессов выжирает оперативку и ставит систему колом.Внушительное зрелище :).Можно конечно настройками число воркеров урезать.Но тогда начнет тормозить отгрузка контента юзерам. >Реально нагрузка на железку не сильно отличается. Ну, вообще-то, потребление RAM отличаятся изрядно.В этом злом тесте на 200 конекция и 10M аплоадов лайт обошелся ~4Mb RAM.Я что-то здорово сомневаюсь что апач сможет столько же отгрузить треская столько же RAM.У меня после попытки покрутить его параметры сложилось ощущение что нормально работать он может только на супер-серверах с кучей ядер и дофигища оперативки.Если вдруг что-то меньше то получается tradeoff между тормозами и выжиранием невъ...нного объема оперативки.И кстати на дворе год 2008.Железка?Хм.А вы слово "виртуализация" слышали?А то оно довольно актуально в 2008 году.Удобно, эффективно по ценам, позволяет ряд весьма эффектных и эффективных фокусов типа сохранения состояний или live-миграции ну и все такое :)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	30. "Обеспечение работы системы мониторинга Nagios при помощи Ngi..."
	Сообщение от Df_Yz (ok) on 10-Ноя-08, 19:18
	А что мешает пустить .cgi через lighttpd?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]