Я медленно удаляю apache с сервера

    image
    Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
    Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
    Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.


    Краткое содержание этой серии:
    Вместо предисловия — Новичок и его сервер
    1. Слушаем чужие советы и тратим время на чепуху
    2. Реверс-прокси и еще один админ (ставим и коряво настраиваем nginx)
    3. Наконец-то взялись за ум (nginx + php-fpm + eAccelerator)

    Начнем с истории


    Сервер ставился по вот этому мануалу — классический LAMP + Хостинг-панель + phpMyAdmin.
    Позже на него поставили Redmine, который пользовали по прямому назначению и SVN. И тот, и другой в качестве web-сервера используют Apache. Один через Passenger, второй через mod_dav_svn. Это важно, потому что Apache после этих установок потяжелел.

    Оптимизация первая — mpm_worker (лишний шаг)


    Через некоторое время пошла первая волна подвисаний. То ли сайтов стало больше, то ли посещаемость их так сильно выросла, то ли активная разработка (и соответственно активное использование Redmine + SVN) стала тому виной. Но ложился сервак постоянно и всерьез. Нашел среди знакомых вроде более-менее адекватного линуксоида, но толкового ответа от него не добился. (Ну не считать же таковым совет поменять сетевую карту!)
    Другой админ провел 3-х дневную инспекцию, посоветовал перевести Apache в режим worker. Ок, сели, рукава засучили, сайты в ISPConfig на FastCGI попереводили (там поле типа select в админке:)), вокруг phpMyAdmin c бубном потанцевали, все .htaccess на предмет директив php_* просмотрели. Админ потерялся. Ну ок, своими силами переставили Apache в worker.
    Сервер более-менее нормально (зависая не чаще раза в неделю) работал пару месяцев.
    Ссылок на манулы не даю, поскольку шаг действительно лишний.

    Оптимизация вторая — welcome to nginx (шаг в правильном направлении)


    Опять нашли какого-то админа, но на этот раз схитрили — сначала поговорили, он про MPM и не слышал ничего, читать конфиги апача не умеет, уровень квалификации был признан неудовлетворительным.
    Правда, пару раз обмолвился о nginx. Я погуглил, почитал Хабр и решил поставить nginx в качестве реверс-прокси перед Apache. Переезжать полностью на nginx было страшно, почему-то был уверен, что PHP-скрипты будут чуствовать себя неудобно (наверное вспомнился какой-то давний случай, когда правил чужой код на чужом сервере без апача, и там то ли расширений не стояло, то ли сам php старенький был). Вот так вот детские травмы влияют на дальнейшую судьбу серверов.
    Итак, ставим nginx на Debian (не забываем, что у нас ISPConfig) вот по этому мануалу. В принципе — все стандартно. Сначала переводим Apache на порт :82 (порт :8080 занят — на нем висит ISPConfig):
    vi /etc/apache2/ports.conf
    

    После этого меняем порт у всех ранее созданных виртуальных хостов
    sed -ie 's/YOUR-IP:80/YOUR-IP:82/g' /etc/apache2/sites-available/*.vhost
    mkdir /root/apache2_vhost_backup/
    mv /etc/apache2/sites-available/*.vhoste /root/apache2_vhost_backup/
    

    Осталось не забыть сменить порт для наших приложений (в моем случае это были phpMyAdmin, SVN и Redmine), конфиги которых лежат вне /etc/apache2/sites-available/ (в мануале об этом умалчивают).
    Следующий шаг — сделать так, чтобы вновь создаваемые через ISPConfig сайты тоже слушали 82-й порт (в мануале тут ошибочка, если делать как у них — ничего не получится. У меня по крайней мере (ISPConfig 3.0.2) вновь создаваемые сайты слушали 80-й. А комментарий мой на эту тему под статьей я почему-то уже не вижу):
    cd /usr/local/ispconfig/server/
    cp conf/apache_ispconfig.conf.master conf-custom/
    cp conf/vhost.conf.master conf-custom/
    #открываем оба исходных файла и меняем порт на :82
    vi conf/apache_ispconfig.conf.master conf/vhost.conf.master  
    

    Дальше — стандартная установка/настройка libapache2-mod-rpaf (чтобы апач видел IP пользователя) и nginx
    apt-get install libapache2-mod-rpaf nginx
    


    Дописываем в конфиг Apache /etc/apache2/apache2.conf 2 строчки
    RPAFsethostname On
    RPAFproxy_ips 127.0.0.1 YOU_IP_ADDRESS
    


    Заменяем default сервер nginx /etc/nginx/sites-available/default вот этим (это старый плохой конфиг, я его специально для статьи сохранил. Я его ниже переделываю. Отличается от мануального тем, что в мануальном все запросы вида www.site.com перенаправляются на site.com, а у меня обрабатываются — просьба/требование сеошников некоторых сайтов. Сходство с мануальным — каждый виртуальный хост можно найти по адресу /var/www/site.com/web/, статику нужно брать именно отсюда):

    server {
        listen   80 default;
        server_name  _;
        server_name_in_redirect  off;
        resolver  127.0.0.1;
    #ACHTUNG! так делать не стоит. Смотрите UPD снизу
        if ($host ~* ^(www\.)(.+)) {
            set $host2 $2;
        }
        if ($host !~* ^(www\.)(.+)) {
            set $host2 $host;
        }
        access_log  /var/log/ispconfig/httpd/$host/access.log;
        location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|swf|flv|mp3)$ {
            root   /var/www/$host2/web;
            access_log off;
            expires 30d;
        }
        location / {
            root   /var/www/$host2/web;
            index  index.html index.htm index.php;
            access_log      off;
            proxy_pass http://127.0.0.1:82/;
            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
    

    Перезапускаем apache и nginx (лучше именно в такой последовательности)
    /etc/init.d/apache2 restart
    /etc/init.d/nginx restart
    

    Все! Прокси стал. Только вот толку от него немного (на моей конфигурации). Ну хорошо, статику отдает теперь nginx. И че? В общем, через пару месяцев сервак опять плачет и жалуется на жизнь. Симптомы те же — раз в 2-3 дня load average > 20, перезапускаем апач — через минуту все нормализуется.

    Оптимизация третья — а зачем нам Apache?


    Предыстория закончилась. В эту субботу лежу я на диване, читаю интервью и понимаю — время пришло. Поскольку впереди времени немеряно (целые выходные! никому ничего не обещал! ну почти...), решаю даже сделать это правильно — сначала собираем прототип на рабочем ноутбуке (Debian Squeeze), а только потом лезем на живой сервер.
    Сказано — сделано. Тушим апач, ставим nginx, переписываем порты у апача, эмулируем в директории /var/www/ перечень доменов (у ISPConfig именно так), забираем с сервера описанный выше конфиг, запускаем оба сервера — профит, прокси готов. Все гуд, тестовый сайт на wordpress бегает.

    Подшаг 3.1 (лишний) — fastcgi-wrapper

    Ок, если не передавать запросы на Apache — кому тогда? Гугл-гугл, ты могуч… Ага! Отдай запросы FastCGI через wrapper. Супер! так просто! И мануал на русском! Класс! Так, так. Ага, предлагают поставить lighttpd. Ради 1 скрипта? Хм… Ну ладно, ноутбук, не сервер же. Пробуем.

    $ sudo aptitude install lighttpd                
    # ок, поставили (кстати, внимательный глаз в процессе установки заметит, что в Squeeze нужный нам скрипт spawn-fcgi идет отдельным пакетом. но от этого только хуже. я его ставил отдельным пакетом, потом сносил, потом опять ставил, но уже весь lighttpd)
    $ sudo /etc/init.d/lighttpd stop                  
    #ок, остановили
    $ sudo update-rc.d -f lighttpd remove    
    #ок, убрали из автозагрузки
    $ sudo /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 \
                      -u www-data -g www-data \
                      -f /usr/bin/php5-cgi \
                      -P /var/run/fastcgi-php.pid
    #получаем что-то похожее на ошибку - "child process return 2" - в общем ничего не стало, никто никого на :9000 не слушает, все плохо. А почему? А все просто в системе нет "/usr/bin/php5-cgi"!
    $ sudo aptitude install php5-cgi
    

    Все, после установки php5-cgi все сразу станет хорошо — spawn-fcgi запустится, помещенный в /etc/rc.local запустится — в общем все будет хорошо. А нифига! Мануал написан на русском? Жди беды! И точно — на ноутбуке процесс постоянно отваливался, будучи перенесенным на сервер — на тяжелых запросах через два на третий отдавал пустую страницу. Но мы то еще об этом не знаем, nginx на 127.0.0.1:9000 еще ничего не проксирует! Просто не делайте так, я чуть ниже покажу как лучше.

    Подшаг 3.2 — настраиваем nginx

    На эту тему написано немеряно. На хабре и снаружи. Из интересного —
    ветка форума — хорошо видна эволюция понимания настроек nginx — forum.woweb.ru/topic47631.html
    как не надо делать — habrahabr.ru/blogs/nginx/74135
    «достойно всяческого порицания» — vkurseweba.ru/files/nginx-doc.pdf — улыбнула фраза
    за вики простите, но все же прочтите — wiki.nginx.org/NginxHttpCoreModule

    Итого, у меня получилось 2 файла конфигурации, один для реверс-прокси к Апачу (назвал его proxy):
    server {
    #слушаем 80-й порт, это сервер (в терминах конфига nginx) по-умолчанию
        listen   80 default;
    #перечень доменов, которые крутятся на этом сервере
        server_name  mysite.com www.mysite.com;
    # http://nginx.org/ru/docs/http/ngx_http_core_module.html#server_name_in_redirect
        server_name_in_redirect  off;
    http://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver
        resolver  127.0.0.1;
    #парочка некрасивых if, предназначены для определения пути к директории виртуального хоста
    #ACHTUNG! так делать не стоит. Смотрите UPD снизу
        if ($host ~* ^(www\.)(.+)) {
            set $host2 $2;
        }
        if ($host !~* ^(www\.)(.+)) {
            set $host2 $host;
        }
    #надеюсь не нуждается в комментариях
        access_log  /var/log/ispconfig/httpd/$host/access.log;
        access_log off;
    #DOCUMENT_ROOT виртуального хоста
        root   /var/www/$host2/web;
    #извините, не могу прокомментировать что именно делает данная директива
        index  index.html index.htm index.php;
    #пошли разбираться с полученным урлом. Первым делом проверяем на существование файла. Если файл есть - отдаем его. Если нет - отправляем запрос на index.php в корне домена. (Не волнуйтесь, запросы вида /some-file.php сюда не попадут, они будут сразу обрабатываться соответствующим location)
        location / {
            try_files $uri /index.php;
        }
    #именно этот location будет обрабатывать запросы вида /some-file.php, и как следствие - на него мы перенаправим запросы на несуществующие файлы из предыдущего location
        location ~* \.php$ {
            proxy_pass http://127.0.0.1:82;
            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
    


    И второй сервер (в терминологии nginx), для работы непосредственно с php (я назвал его default):
    server {
        listen   80;
        server_name  _;
        server_name_in_redirect  off;
        resolver  127.0.0.1;
    #ACHTUNG! так делать не стоит. Смотрите UPD снизу
        if ($host ~* ^(www\.)(.+)) {
            set $host2 $2;
        }
        if ($host !~* ^(www\.)(.+)) {
            set $host2 $host;
        }
    
        access_log  /var/log/ispconfig/httpd/$host/access.log;
        root   /var/www/$host2/web;
        access_log off;
        index  index.html index.htm index.php;
    #работает аналогично соответствующей location из первого файла
        location / {
            try_files $uri $uri/ @fastcgi;
        }
    #именованный location, нормальным образом запросы сюда не попадут, только перенаправленные из других частей конфига. В предыдущем proxy я не создавал такого, поскольку внутри named-location нельзя использовать proxy_pass вида http://127.0.0.1:82 - nginx при перезагрузке ругается, хотя это наверное можно обойти с помощью upstream (смотрите еще ниже). Именно сюда мы переправляем запросы с ЧПУ. Можно было обойтись без него и как в предыдущем примере перенаправлять не на @fastcgi, а на /index.php,  но мне почему-то хочется верить, что так будет отрабатывать чуть быстрее.
        location @fastcgi{
    #указываем куда передавать запросы
            fastcgi_pass 127.0.0.1:9000;
    #инклюдим файл /etc/nginx/fastcgi_params
            include fastcgi_params;
    #задаем скрипт-обработчмк
            fastcgi_param  SCRIPT_FILENAME  /var/www/$host2/web/index.php;
        }
    #все как в предыдущем примере
        location ~ \.php$ {
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /var/www/$host2/web/$fastcgi_script_name;
            include fastcgi_params;
        }
    }
    

    А теперь самое вкусное. Наличие этих двух серверов включенными (не забываем создавать символические ссылки в папку sites-enabled) у nginx позволяет мне спокойно уйти спать с чуством глубокого внутреннего удовлетворения. Наконец-то я смогу спокойно, один за одним, выбирая самые нагруженные сайты на сервере переводить их на nginx, перепроверять, и в случае проблем за 1 минуту переводить обратно. Можно не самые нагруженные — можно самые массовые. Текущая конфигурация default удовлетворяет правила ModRewrite от Wordpress по умолчанию на 100%. После минимального допиливания — будет удовлетворять еще и джумлу, и Битрикс. А это уже ~80% моего хостинга. К сожалению, ModRewrite для CodeIgniter будет несовместим с этой версией. Но отличаться она будет не сильно. Так что серверов в конфиге nginx будет не 2 — «на Апач» + «на php», а побольше. А разные велосипеды с 48 строками в .htaccess специально на apache оставлю, пусть сволочи помучаются.
    Обратите внимание, у первого (proxy) файла стоит listen:80 default; Что это означает? Это означает, что все виртуальные хосты, не указанные в остальных файлах по умолчанию будут отправлены на обработку к Apache. Это-то нам сейчас и нужно. Потом, хочется верить, я перепроверю все сайты и сделаю default сервером по умолчанию (из-за этого и выбрано имя сервера). А на proxy оставлю несколько «счастливчиков».

    Вся конфигурация была проверена на ноутбуке и перенесена на сервер без каких-либо неожиданностей. На первый взгляд все работает, крутится, несколько сайтов перевел на nginx, перенастроил default для Joomla, даже Битрикс — и тот завелся!

    Конфигурация не идеальная плохонькая (к примеру, .htaccess, .htpasswd, application.ini и файлы с расширением не-php nginx отдаст первому встречному попросившему), использовать ее для production не стоит. Камни и свои примеры в комментариях приветствуются.
    В сети было найдено немало упоминаний про онлайн-генератор конфигов под nginx на основе .htaccess.
    Все они указывают на одну и ту же, ныне не работающую страницу — http://www.anilcetin.com/convert-apache-htaccess-to-nginx/. Никто не встречал более-менее рабочего варианта? Есть на сервере несколько велосипедов с очень некрасивыми .htaccess. Хотелось бы их преобразовать во что-то похожее на конфиг nginx, пусть не 100% рабочий, можно и напильником допилить.

    UPD: В комментариях vbart показал более красивое решение определения имени домена без www.
    Для этого в /etc/nginx/nginx.conf в блок http добавляем map
        map $host $host_wo_www {
            default  $host;
            ~^www\.(?P<wo_www>.+)$  $wo_www;
        }
    

    И теперь во всех серверах мы можем избавляться от уродливого двойного if, а вместо переменной $host2 использовать $host_wo_www.

    Подшаг 3.3 — избавляемся от fastcgi-wrapper

    Воскресным утром обнаружились первые проблемы. Один из 5 переведенных сайтов периодически выдавал по запросу чистую страницу. Не страшно, сайт мой, а значит никто звонить не будет. Но неприятно именно тем, что такая ситуация может повториться и с сайтами клиентов. Оно нам надо?
    Где-то на Хабре нашел упоминание php-fpm в этом контексте. Нагуглил очередной мануал. Но вот беда — это возможно для php 5.3. А на сервере стоит 5.2. Система бэкапов у меня работает только для виртуальных хостов и баз данных. Кинул монетку и обновил.
    В файл /etc/apt/sources.list добавил строчки
    deb http://packages.dotdeb.org lenny all
    deb-src http://packages.dotdeb.org lenny all
    #в следующих двух строках я вместо stable (из мануала) поставил lenny - при stable apt-get отказался видеть php и php-fpm
    deb http://php53.dotdeb.org lenny all
    deb-src http://php53.dotdeb.org lenny all
    

    Потом все как всегда
    apt-get update
    apt-get install php php5-fpm
    

    При установке php5 попытался подняться lighttpd, но не смог — 80-й порт слушал nginx. (Я ставил несколько раз, поэтому пришлось пойти и переключить lighttpg на 81-й, все равно сейчас его удалим)

    На удивление — проблем почти не было (short_open_tag On и default_timezone в php.ini не в счет). А, да, еще упала одна Joomla из-за криворуких плагинописателей. Эту подняли уже аж в понедельник.

    Чувство update на живом сервере сродни прыжку с парашютом — мозгами понимаешь, что все будет гуд и на самый крайний случай откатимся назад или что-то придумаем, но ладошки потеют и куришь по 2 сигареты за раз.
    Потом полностью откатываем назад шаг 3.1 — убираем fastcgi-wrapper из автозагрузки, тушим уже запущенный (можно перезагрузиться, а можно подсмотреть id процесса в /var/run/fastcgi-php.pid и сделать kill), удаляем lighttpd.
    /etc/init.d/php-fpm start
    

    И все. И да, после этого все стало совсем хорошо и весело. На ноутбуке порт слушали, никто никуда не падал. На сервере исчез белый экран смерти.
    UPD: ниже Nc_Soft (спасибо!) указал на одну уязвимость.
    Идем редактируем файл /etc/php5/fpm/php.ini, заменянем/дописываем cgi.fix_pathinfo=0

    Подшаг 3.4 — а почему собственно :9000?

    И раз уж на то пошло — а почему вообще сетевой интерфейс? Мы ведь в линуксе, правильно? Надо работать через сокеты! Четкого понимания что же такое сокет нет. Опять гуглим. Читаем. Настаиваем php-fpm — /etc/php5/fpm/pool.d/www.conf:
    ;listen = 127.0.0.1:9000
    listen = /var/run/php5-fpm.sock
    

    Настраиваем nginx — /etc/nginx/nginx.conf, заодно делаем upstream — так красивее
    ...
    http{
    ...
    #этот блок должен быть обязательно в контексте http - иначе nginx при перезапуске ругается unknown directive
        upstream php5-fpm-sock {
            server unix:/var/run/php5-fpm.sock;
        }
    ...
    }
    ...
    

    В настройках наших серверов заменяем 127.0.0.1:9000 на php5-fpm-sock. Сервер proxy, естественно, не трогаем.

    Перезапускаем nginx и php-fpm
    /etc/init.d/nginx restart
    /etc/init.d/php-fpm restart
    

    Возможно я не прав, пусть знающие люди в комментариях осудят, поймут и простят подскажут, но я, тысячу чертей, не понимаю, почему во всех встреченных мною мануалах все back-end'ы nginx слушает именно по сетевому протоколу. И никто словом не обмолвится — мол, в дальнейшем замените сетевой сокет на UNIX-сокет (POSIX или как там его правильно).

    Подшаг 3.5 — выеживаемся

    Это почти все. После мануала из предыдущего подшага захотелось странного — кешировать опкоды. При попытке установить php-apc apt-get потребовал downgrade php и remove php-fpm. Я показал ему фигу и с помощью checkinstall поставил eAccelerator из исходников вот по этому этому мануалу. После установки появилась одна проблемка — eAccelerator не захотел работать с сайтами, которые сейчас крутятся под Apache (то ли они у меня на самом деле работают в режиме cgi, то ли еще в чем проблема). Вернее сайты работают, но почему-то выдают warning на пустом месте — то файл не найден (хотя на этой строчке include жестко захардкожен и файл реально существует), то переменная не определена (1 строчкой выше приравнена пустому массиву!).
    В общем, убрал я eaccelerator.ini из /etc/php5/conf.d и дописал его содержимое в конец /etc/php5/fpm/php.ini
    Для сайтов, работающих через php-fpm eAccelerator включен.

    В этом месте возникла еще одна проблема — даже при выполнении php -v из командной строки, php ругался на apc.so. Я пошел и удалил apc.ini из /etc/php5/conf.d/. Все вроде стало нормально. И только на следующий день заметил замертво лежащий сайт на Joomla. Расследование показало, что, невзирая на отсутствие в системе php-apc, Joomla упорно вызывала apc_fetch. Я ее конечно в коде закомментировал и сделал вид, что она всегда возвращает false, но хотелось бы побороть проблему чуть более красиво. Или отучить джумлу лезть за кешем именно в apc, или поставить в php фейк apc (Debian Lenny). Если кто-то сможет помочь — добро пожаловать в комментарии.

    Итоги


    Сегодня сервер проработал целый день, load average выше 2 не поднимался (это только 5 переведенных сайтов, больше не переводил — день длинный и тяжелый, после таких-то выходных). Ни на ноутбуке, ни на сервере самописные сайты на Zend Framework работать отказываются наглухо, по ощущениям даже не создается объект Application — пойдем перепроверять base_path.

    PS: я в дальнейшем планирую перевести Redmine и SVN за nginx, поставить Node.js, посмотреть как сращиваются Nginx и git. Если будет на то воля Хабра — могу отписаться. Постараюсь сделать это покороче.

    UPD: учел замечание от пользователя VBart, подправил конфиги.
    UPD: добавил в описание установки php-fpm дополнение от Nc_Soft.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 184

      +12
      почему во всех встреченных мною мануалах все back-end'ы nginx слушает именно по сетевому протоколу

      Вероятно потому, что фронт с nginx и бекенд с php – разные сервера. Если же все на одном сервере – логично использовать socket.
        +2
        Недавно здесь на хабре читал что проводили експерименты которые показали что TCP более производителен нежели sockets
          +5
          Подобные фразы нельзя просто вырывать из контекста. Все очень сильно зависит от профиля, качества и особенностей нагрузки. Для каждого отдельного сервера такие решения необходимо принимать индивидуально.
            +2
            Не поленился найти, вот тот вопрос. Тест никакого отношения к реальности не имеет, конечно, как минимум из-за ab вместо нормального siege, но всё-таки заставляет задуматься.
              0
              Ммм, а в чем проблема ab?
                0
                Синтетические тесты покажут сферических коней в вакууме. Все эти цифры будут сильно отличаться от реальных цифр реальной работы всей системы с реальными пользователями.
                  0
                  Я прикинул — наверное, всё-таки это больше дело вкуса. С другой стороны, siege даёт возможность долбиться не на один адрес, а на список адресов из .txt файла, а ab такого не умеет. Конечно, всё это имеет мало общего с реальными пользователями, но проверка списка адресов вместо проверки скорости отдачи кеша главной страницы — по-моему, на шаг ближе к тому, что требуется от тестирования.
                    +2
                    ab медленный, плохо работает с keep-alive и там ещё могут быть косяки. Да и в целом, как уже было сказано, такие синтетические бенчи могут только ввести в заблуждение.

                    Однажды было вообще очень забавно. Кто-то в рассылке nginx однажды написал, что у него при выключении логов RPS падает (а должен бы расти, ведь меньше логики задействовано и меньше записи на диск). Человек тестировал видимо с помощью ab. У меня получилось это воспроизвести.

                    Действительно, выключаем лог и RPS падает. Начал исследовать вопрос. Оказалось, с выключенным логом nginx начинал обрабатывать запрос так быстро, что ab не успевал прислать следующий и не обнаружив новых данных nginx уходил в epool, а это становилось для такого «Hello world» тестирования достаточно дорогой операцией.

                    Итого, nginx может обрабатывать запросы быстрее, чем ab их посылать, причем локально и на многоядерном процессоре всего с одним воркером. =)
                  0
                  Мне кажется до 10 миллионов хитов в день на сервер нельзя заметить такую разницу.
                  0
                  пол года назад фиксил оч странную багу, хорошо что почти сразу пришло в голову обратиться к апачу напрямую, напрямую всё работало стало понятно где копать.
                  +3
                  Для начала на mpm_worker имеет смысл переводить, только в случае если используется mod_php. Только в этом случае достигается реальный профит. Опять же использование apache так же может давать профит исключительно только в режиме mod_php. Если вы его не используете и используете cgi, то не вполне понятен смысл установки apache. Второй момент, кешер надо ставить как можно раньше. И вместо eaccelerator можно использовать xcache. Он к тому же всякую красивую статистику дополнительно рисует. И еще дополнительно стоит посмотреть какие настройки СУБД и какая у вас дисковая активность наблюдается. А то помнится тут уже были деятели которые вместо того чтобы купить больше памяти покупали более быстрые и дорогие диски. Когда проблема решалась установкой пары планок памяти и подкруткой настроек СУБД.
                    0
                    как жеж непонятен? а великие и могучие .htaccess?
                    кто будет регулярки тоннами переписывать для несчастных программистов?
                      +1
                      В таком случае не используйте fastCGI. Есть великий и могучий mpm-itk. Всяко будет быстрее чем apache+cgi
                      –2
                      Для кеширования можно использовать Memcached.

                      В частности для Wordpress нужно поставить серверную часть Memcached, плагины advanced-cache.php, object-cache.php Memcached, WP Memcached Manager
                      • НЛО прилетело и опубликовало эту надпись здесь
                          –1
                          Согласен, я о дальнейшем снижении нагрузки.
                          +3
                          опкод будете тоже им кешировать? :)
                            –2
                            нет, но будет кешировать объекты и значения.
                              +3
                              ну да, а потом eval! уииии!
                                0
                                извините, вырвалось:)
                            0
                            А XCache лучше eaccelerator'a? У меня почему-то не заставить eaccelerator хранить сессии в памяти (freebsd) что ни делаю — не подхватывает и всё.
                              0
                              Когда я работал в одном хостинге, мы проводили бенчмарки xcache vs eAccelerator.
                              xcache лучше держит экстремальные нагрузки, более 150 запросов в секунду. eAccelerator тупо к segmentation fault приводил + ещё xcache на таких нагрузках работает незначительно, но быстрее.
                                0
                                какая версия eAccelerator была? Более 150 запросов в секунду — это не так много еще.
                            +25
                            (кстати, правильно это слово читается «энжинкс»)

                            Cкажите об этом Сысоеву и попросите, чтобы на сайте у себя поправил: www.nginx.org/ru/
                            Читается: nginx [engine x] (э́нджин-э́кс)
                              0
                              Тоже сразу обратил на это внимание. Да и не благозвучно «энджинкс» для русского языка.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  +5
                                  Да и не благозвучно «энджинкс» для русского языка

                                  Спорно. Как по мне, проще произнести «энжынкс», чем «энжынэкс».
                                    +1
                                    Наверное, это уже дело привычки.
                                      0
                                      Я обычно это название произношу как написано: «нджинкс».

                                      Интересно: что заставило автора столь причудливо зашифровать произношение? И почему бы не назвать софт «Engine-X», если он хочет, чтобы именно так оно произносилось?
                                    0
                                    engine-x что в транскрипции энджин-икс… ну или экс
                                    0
                                    А прослушать произношение можно тут.
                                      0
                                      Спасибо, исправляю.
                                        +4
                                        Hello, this is Igor Sysoev and I pronounce «Nginx» as «Engine-X».
                                        +8
                                        Где ж вы таких админов только берете. «Трехдневная инспекция, обмолвился про nginx».
                                        А вообще очередной сериал по сотому разу how to become highload-ready. Статей на эту тему уже столько понаписали ))
                                        Сколько вы в итоге времени потратили, чтобы прийти к очень распространенной (можно сказать типовой) в наши дни конфигурации?
                                          +26
                                          Это проблема почти всех linux-based администраторов. Называется гугль-обучение. Нормальных (читай, фундаментальных, долговечных и достоверных) источников получения знаний в этой части ИТ мира нет. А те хорошие (и толстые) книги про Unix, которые я видел уже устарели и их мало кто способен «осилить» в силу толщины.

                                          Поэтому (чисто мое личное имхо) очень много людей допущено к системам, которые они воспринимают как загадочный черный ящик с несколькими известными входами и выходами. Постичь который можно только путем тривиальных манипуляций с онными.

                                          В результате читаешь вот такие статьи и думаешь — оспади, как же можно настолько не понимать основы, что бы без балды писать про «опасения, что php скрипты будут неудобно чувствовать себя под nginx» и оправдывать это «детскими травмами».

                                          Впрочем, все поправимо.
                                            +2
                                            Киньте названием толстой книжечки, пожалуйста, а? Вам многие будут благодарны.
                                            +2
                                            Согласен, это проблема. Легкий доступ к практическим «рецептам» делает возможным другой способ обучения — через практику, результат-ориетированный — «Сначала поставим и настроим, а потом уже разберемся что же именно мы поставили и как оно вообще работает».
                                            Лично мне знаний не хватает катастрофически. Но времени на их получение тоже не хватает. Когда-нибудь позже, предварительно набив еще несколько шишек и поигравшись еще с чем-то, я смогу с удовольствием просматривать те самые толстые книги, что-то пропуская, потому что и сам знаю, что-то перепроверяя на практике, открывая что-то новое. Боюсь, что сейчас прочтение такой книги мне только даст неперевариваемо огромный объем информации.
                                            Но за ссылку все равно спасибо.
                                              +1
                                              А вот «опасения, что php скрипты будут неудобно чувствовать себя под nginx» и «детские травмы» — это все-таки шутка, видимо неправильно преподнесенная.
                                              Все равно спасибо.
                                                –1
                                                " оспади, как же можно настолько не понимать основы, что бы без балды писать про «опасения, что php скрипты будут неудобно чувствовать себя под nginx" — да запросто например php.net/manual/en/ref.apache.php а то, что может быть вызвано через system вообще предугадать нельзя.
                                              –1
                                              У меня сервер крутится на FreeBSD. Из используемого только php.
                                              В своё время купился на spawn-fcgi, который был в составе lighttpd. Пытался его поставить совместно с nginx. Всё работало хорошо до момента обновления через порты. Потом всё упало. Времени разбираться не было и решил перейти на lighttpd, который и крутится по сей день.
                                              Позже spawn-fcgi выделился в отдельный проект. Но вроде всё работало и не хотелось снова всё ломать.
                                              Ну а сейчас перешёл на php-fpm. Теоретически без разницы что использовать lighttpd или nginx. Связь идёт через socket.
                                                +2
                                                Здесь, конечно, сильно зависит от ситуации, но во многих случаях схему nginx + apache можно сохранить, подходя к оптимизации индивидуально. Например, для гостей и роботов данные можно выдавать из кэша, а авторизированным пользователям выдавать данные посвежее от бэкенда. Аналогично и с магазинами, товар добавил в корзинку — получи куку и доступ к апачу, а до этого — извини, тебя обслуживает nginx.

                                                Собственно, речь только о том, что описанное решение — не панацея и не универсальное лекарство от всех бед.
                                                  +11
                                                  Я бы здесь прикрутил картинку «слоупок.жпг»: на дворе уже 2012 год и то что потребление ресурсов Apache на нагрузке превышает аналогичное на nginx ни для кого не секрет уже года четыре. Все же поздравляю с успешной настройкой сервера.
                                                    +2
                                                    За поздравления спасибо.
                                                    За слоупока тоже — хоть узнал что это такое.
                                                    Сыш, ты кого слоупоком назвал?

                                                    Это как бы и для меня не было секретом. С теоретической точки зрения. Теперь вот на практике проверил.
                                                      +1
                                                      Посмотрел что выдает гугл по «слоупок» и понял что это могло выглядеть несколько грубо с моей стороны. Я не хотел ничего обидного сказать :)
                                                    0
                                                    Чем планируете заменить mod_dav_svn?
                                                      –3
                                                      svn co svn+ssh://server/path/to/repository
                                                        0
                                                        Еще не знаю, буду искать.
                                                        Здесь основная сложность в 1 хотелке — сделать авторизацию при SVN запросах через Readmine.
                                                        Сейчас эта связка работает.
                                                          0
                                                          Сейчас точно такая же проблема стоит. На Apache нас держит только svn… Кстати вы к svn напрямую к апачу коннектитесь или через nginx проксируете? Он нормально справляется? (Читал несколько отрицательных отзывов про проксирование mod_dav_svn)

                                                          А так то в идеале было бы на gerrit народ перевести вместо svn, но народ упирается :(
                                                          (на второй работе так и сделали)
                                                            0
                                                            на gerrit народ перевести вместо svn

                                                            Вы наверное имели в виду Git? Да, есть такая хотелка, Redmine с ним работает, nginx, говорят, с ним сращивается нормально. Если бы получилось схему авторизации для git сделать из базы Redmine (чтобы у пользователей одинаковые логины и пароли были и к Redmine, и к Git) — вообще бы сказка была.

                                                            При работе с SVM я запросы отправляю прямо к Apache (на 82-й порт), поскольку в моей корявенькой предыдущей конфигурации nginx проверял расширение файла и комиты, содержащие .js или .css файлы не проходили (nginx пытался найти файлы на сервере, не мог и возвращал 500-ю ошибку).
                                                            Ой чувствую меня сейчас пинать за такую конфигурацию опять начнут

                                                            Сейчас буду от этого уходить, конечно. А git — это да, git — немного интереснее svn.
                                                              0
                                                              Для svn у нас используется доменная авторизация.
                                                              Самостоятельно собирать с народа ключи для git не хочется, хочется веб интерфейс с авторизацией в LDAP и загрузкой ключей. Gerrit всё это предоставляет + Code Review. Используем его на другой работе.
                                                              Как и многие другие продукты Google он весьма хорош.
                                                              0
                                                              у себя я SVN перевел на https и прямой коннект через апач, т.к. через nginx разного рода грабли возникали.
                                                            0
                                                            заменил ssh+git, доволен как слон :)
                                                            +1
                                                            А в чем собственно профит отказа от apache preforked?
                                                              +6
                                                              Профит вообще в отказе от apache, можно было написать только это.
                                                                +4
                                                                В том то и дело, что, как правило нет. Профит в установке проксирующего фронтэнда, это я верю. А замена apache на php-fpm профита обычно дает меньше чем доступных apache возможностей.
                                                                  0
                                                                  Какие, например возможности ?) mod_rpaf ?)))
                                                                    0
                                                                    .htaccess и иже с ним — mod_rewrite, авторизация, allow, deny и т.д. В nginx все это конфигурится заметно сложнее.
                                                                      0
                                                                      То есть возможности = простота конфигурации? Вы сейчас описали функционал, присутствующий также и в связке, допустим, nginx+php5-fpm, причем функционал для фронтенда. Неважно, как это конфигурируется, важно как это потом работает под нагрузкой ))

                                                                      А мы сейчас вообще говорили про apache/не apache в качестве именно бэкенда, чья задача незатратно прожевать и отдать динамику. Apache при таком решении все же очень затратен по ресурсам и медленнее, чем все остальное, в чем же профит?
                                                                        +1
                                                                        А вы измеряли, насколько он медленнее и затратнее по ресурсам?
                                                                          +1
                                                                          Измеряли, поэтому не используем. Довольны как слоны. Я уже молчу, что при совсем диких нагрузках apache, когда ему перестает хватать памяти, вместе с сервером впадает в кому и LA добегает до 800.

                                                                          php5-fpm прожимает до 15000rps. Мы довольствуемся в наших проектах 500rps, для apache это практически недостижимо при равных технических условиях.

                                                                          Но это лишь наш частный случай, никак не аргумент в споре. Скажем так, это success story из практики и личного опыта. 15000 на badoo, они на highload рассказывали, сам я таких цифр не видел.
                                                                            +1
                                                                            На таких нагрузках мы используем самописный web-сервер, который делает то что нам нужно и взаимодействует с, например, базой данных по четко регламентированному расписанию. В случае badoo или vk такая оптимизация, конечно оправдана. Даже ради выжать дополнительные 500rps. В случае автора — получены дополнительные точки отказа, задача с большой вероятностью решалась более простым способом.
                                                                            Как то так.
                                                                          +2
                                                                          Это миф, что он прямо очень сильно затратнее и медленнее. Нетрудно это доказать, написав скрипт на PHP, который отрабатывает за 30-60 мс, и затем натравить на него ab 2 раза: для случая с apache и для случая с php-fpm (все на локалхосте, естественно). Разницы не будет практически совсем (если конфигурация правильная, конечно).
                                                                            +1
                                                                            Так считать нельзя. Представьте, что у меня много кода, много базы данных, везде включен кэш.
                                                                            ab отработает в keep-alive и разные кэши, в итоге будет стопицот rps и 0мс.

                                                                            Реальный пользователь зайдет на страничку, авторизуется, отрендерит себе динамически 17 виджетов, каждый из которых лезет в базу, напишет комментарий, чем обновит еще с 500 виджетов из кэша. На него в это время трудятся три фронтенда и куча бекендов. Нужен инструмент с имитацией деятельности пользователя, тот же tsung.
                                                                            Поверьте, разницу заметить будет несложно )
                                                                              +3
                                                                              В принципе, вы могли бы еще тут добавить про то, что взаимное расположение Юпитера и Марса должно быть определенным, и уж тогда мерить. :-)

                                                                              Вы этим будете мерить разницу не между mod_php и php-fpm, а между одной конфигурацией вашей системы и другой. Я же выше написал, как сравнить именно в чистом виде накладные расходы от apache+mod_php+nginx и php-fpm+nginx. Эти накладные расходы (при правильной конфигурации!!!) практически одинаковы, как по памяти, так и по CPU (что неудивительно: и там и там prefork, и там и там выполняется одинаковый код, а значит, расходуется примерно одинаковое количество памяти). А раз все это одинаково, то тот выигрыш, который вы получили, был связан не с уходом от apache, а с различием в конфигурации.

                                                                              Ну почему же люди так склонны превращать в фетиш все, что связано с nginx-ом и «высокими нагрузками» © ® (tm)…
                                                                                –2
                                                                                А зачем нужны эти расходы в чистом виде? Мне нужно, чтобы система в целом работала )) Реалии таковы, что apache, к сожалению, нетащет более-менее серьезные проекты.
                                                                                Поэтому я останусь при своем мнении, что лучше его сразу убрать, а не тогда, когда проект из трех строк кода перерастет в этот самый «более-менее».
                                                                                  +1
                                                                                  Вконтакте он «тащет». А в чистом виде — я думаю, нужно тем, кто хочет разобраться в причинах проблемы, а не просто делать магические пассы и случайно добиваться увеличения производительности, даже не разобравшись, откуда оно взялось.
                                                                                    –3
                                                                                    Вы сразу пишите, сколько всего бекэндов у вконтакте. Тысяч 15? ))) Это нечестно )) С таким количеством железа можно чудеса highload показывать на любом софте )
                                                                            0
                                                                            Вот картинка с одного из серверов:
                                                                            last pid: 34637; load averages: 3.61, 3.80, 3.85 up 35+21:12:56 13:39:24
                                                                            2924 processes:5 running, 2917 sleeping, 2 stopped
                                                                            CPU: 19.0% user, 0.1% nice, 2.4% system, 0.2% interrupt, 78.3% idle
                                                                            Mem: 9406M Active, 9691M Inact, 3429M Wired, 437M Cache, 2465M Buf, 838M Free
                                                                            Swap: 4096M Total, 60M Used, 4036M Free, 1% Inuse

                                                                            Вот эти 3000 процессов это все apache. Обращаю ваше внимание на показатель LA и Idle. На память не смотрите, она сожрана Mysql-ем.
                                                                              –2
                                                                              Приложите сюда еще профиль нагрузки, netstat, счетчики с сетевых интерфейсов хотя бы.

                                                                              load average: 1.59, 2.00, 2.11
                                                                              Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie
                                                                              Cpu(s): 13.2%us, 1.1%sy, 0.1%ni, 85.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
                                                                              Mem: 14680064k total, 1575808k used, 13104256k free, 0k buffers

                                                                              вот здесь сейчас 12000 пользователей онлайн.
                                                                                0
                                                                                Дмитрий Котеров выше за меня ответил. Такое сравнение будет бессмысленым. Я показал данные, которые говорят о том, что 3000 процессов apache не генерят LA over 9000. Хотя они выполняют порядка 800 разных задач (физически разный код). Значит дело было точно не в apache.
                                                                                  0
                                                                                  У меня 100% проблема была не в Apache, а в том, что я не смог его настроить. Я верю, что если бы я отвязал лишние модули и недельку почитал умные книги и статьи, я бы смог настроить Apache лучше. Только вот где ее взять, эту недельку?
                                                                                    +1
                                                                                    К слову, отключение модулей как раз мало помогло бы (ниже я в комментарии приводил навскидку вещи, которые могли бы влиять). И, я подозреваю, вы теперь в будущем потратите в сумме значительно больше недели на вылавливание всех побочных эффектов, к которым привел отказ от проверенной рабочей конфигурации на живых десятках проектов (вы, например, пропатчивали что-то — как обновлять будете теперь?). Ну да уж что сделано — то сделано.

                                                                                    Лично я люблю ставить php_fpm+nginx, а не apache+mod_php+nginx, исключительно по одной причине: так конфигов меньше. В первом случае — всего лишь конфиг nginx, а во втором — надо следить и за конфигами nginx, и за конфигами apache, что неудобно.
                                                                                      +1
                                                                                      Прошу прощения, но в моем случае это не «отказ от проверенной рабочей конфигурации», а скорее «отказ от уверенно падающей конфигурации»
                                                                                    0
                                                                                    Хорошо. Как объяснить факт, что стало лучше, когда его убрали, а все остальное не изменили?
                                                                                    Ваши количества процессов и LA не значат ничего, если неизвестен профиль нагрузки.
                                                                                      +1
                                                                                      Очень просто — апач был неверно сконфигурирован. Без фронтэнда он тратил время своей работы на медленных клиентов.
                                                                                  0
                                                                                  А можно узнать, что за процессор стоит (количество ядер, частота)?

                                                                                  (интересно… моя не для придирок спросилъ)
                                                                                    0
                                                                                    Там воткнуто два Xeon-а E5620
                                                                                0
                                                                                apache2-utils ставится без апача целиком и спасает мир.
                                                                                  +1
                                                                                  При чем здесь набор утилит-то?
                                                                                    0
                                                                                    Нормальная работа рерайтов, авторизации по htpasswd и прочей лабуды без собственно апача. Я его ставил, правда, только для авторизации в Меркуриале.
                                                                                      0
                                                                                      Поделитесь ссылочкой, где про это можно почитать.
                                                                                      0
                                                                                      А есть ссылочка, где можно почитать именно про использование ModRewrite без Apache?
                                                                                        0
                                                                                        Не интересовался данным вопросом, увы. Мне было достаточно того, что htaccess и htpasswd работают как должно.
                                                                                  0
                                                                                  Чем же сложнее то? Все эти rewrite, allow deny — играючи переносятся в nginx.
                                                                                    +1
                                                                                    Ну не играючи, не нужно. Есть конструкции, которые мы не смогли перенести. Там правда правил rewrite было строк на 200.
                                                                                    Или, пример:
                                                                                    error_page 412 = @search;
                                                                                    location = / {
                                                                                    if ($query_string ~ 'search=')
                                                                                    {
                                                                                    return 412;
                                                                                    }
                                                                                    proxy_pass 127.0.0.1:81/;
                                                                                    }
                                                                                    location @search {
                                                                                    access_log /var/log/search_log;
                                                                                    proxy_pass 127.0.0.1:8081;
                                                                                    }


                                                                                    Я вот, к примеру, иного способа сделать описанное не нашел. Так что не все однозначно с этим.
                                                                          +1
                                                                          кстати, правильно это слово читается «энжинкс»

                                                                          Вы не правы, сам Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс».
                                                                            –5
                                                                            тогда уж энджяйн икс
                                                                              +2
                                                                              false, как ай «i» тут точно не будет читаться, т.к. идет после согласной в закрытом слоге.

                                                                              Вы же не читаете sit как «сайт», а как «си(ы)т» Зато читаете like как «лайк»
                                                                                0
                                                                                да уж плохая память, Ваша взяла.
                                                                              0
                                                                              спасибо, исправил
                                                                              0
                                                                              >посмотреть как сращиваются Nginx и git.
                                                                              Хорошо и качественно скрещиваются, проверено.
                                                                                0
                                                                                Название поста — замануха.)
                                                                                  +1
                                                                                  Вы ожидпли чего0то дркгого?
                                                                                  +2
                                                                                  if ($host ~* ^(www\.)(.+)) {
                                                                                  set $host2 $2;
                                                                                  }
                                                                                  if ($host !~* ^(www\.)(.+)) {
                                                                                  set $host2 $host;
                                                                                  }

                                                                                  Странная конструкция, так не проще?


                                                                                  set $host2 $host;
                                                                                  if ($host ~* ^(www\.)(.+)) {
                                                                                  set $host2 $2;
                                                                                  }

                                                                                    0
                                                                                    Спасибо, обязательно попробую
                                                                                      +2
                                                                                      Да и так очень странная. Как правильно смотрите ниже.
                                                                                      0
                                                                                      Извиняюсь за отклонение от темы, но не могу ни спросить: какой у вас канал? И как такой сервер может держать 40 сайтов или же скорее всего другой вопрос какая посещаемость у ваших сайтов?
                                                                                        +3
                                                                                        уже достаточно давно в пакетах дебиана есть
                                                                                        spawn-fcgi — A fastcgi process spawner
                                                                                        отдельно от lighttpd

                                                                                        + удобно разделять процессы по пользователями — каждому сайту своего пользователя и свой php.ini
                                                                                        /usr/bin/spawn-fcgi -s /tmp/fcgi-site1.sock -C 5 -u site1 -g site1 -- /usr/bin/php-cgi -c /var/www/site1/etc
                                                                                        /usr/bin/spawn-fcgi -s /tmp/fcgi-site2.sock -C 5 -u site2 -g site2 -- /usr/bin/php-cgi -c /var/www/site2/etc
                                                                                        chown :www-data /tmp/fcgi*
                                                                                        chmod g=+r+w+x /tmp/fcgi*

                                                                                        как-то так…
                                                                                        также это решает проблему пермишнов на аплоад файлов через пхп — пользователь через фтп работает под своим аккаунтом, пхп работает под тем же юзером — каталоги овнеру доступны на запись, не нужно делать chmod 777 как некоторые рекомендуют в своих «мануалах»…
                                                                                          0
                                                                                          уже достаточно давно в пакетах дебиана есть
                                                                                          spawn-fcgi — A fastcgi process spawner
                                                                                          отдельно от lighttpd

                                                                                          для Squeeze нашел, в статье это описывал, для Lenny не нашел.

                                                                                          За остальное спасибо, обязательно попробую
                                                                                            0
                                                                                            Да, только у них перед апачем тоже nginx стоит. ;)
                                                                                            +8
                                                                                            Мне кажется, вам помог не переезд с apache на php-fpm, а просто был какой-то баг в конфигурации apache (или связки apache+nginx). Когда не стало apache, не стало и данного бага тоже. Ваш способ похож на метод лечение головной боли путем отрубания головы и выращивания новой, другой расы.

                                                                                            Я бы смотрел в сторону:
                                                                                            — правильных размеров буферов nginx (чтобы apache реально не ждал, пока контент отдается);
                                                                                            — нет ли в правилах mod_rewrite зацикливаний (защита от зацикливаний там из рук вон плохая);
                                                                                            — правильных настроек MaxClients apache (в случае, если правильно настроен nginx, там нужно совсем небольшое количество);
                                                                                            — eAccelerator, конечно же, должен стоять (если глючит — надо подбирать версии PHP и eAccelerator, чтобы работало стабильно, это возможно — по крайней мере, я много лет пользуюсь eAccelerator и за это время всего пару багов ловил, так что вам не повезло просто, скорее всего);
                                                                                            — max_execution_time правильный был? (в php-fpm есть свой прибиватель, поверх этого, он иногда помогает)
                                                                                            — есть такие утилиты, strace/ptrace, когда что-то виснет, удобно ими смотреть, что происходит.

                                                                                            Даже статику не обязательно напрямую через nginx отдавать во многих случаях, чтобы существующие конфиги не трогать лишний раз — при правильных буферах сойдет и через apache (правда, тут надо смотреть все же, что будет происходить — может, у вас там видеоролики или mp3).

                                                                                            Вконтакте, говорят, работает на apache+mod_php+nginx, и ничего. В целом — это и понятно.
                                                                                              –1
                                                                                              — eAccelerator, конечно же, должен стоять (если глючит — надо подбирать версии PHP и eAccelerator, чтобы работало стабильно, это возможно — по крайней мере, я много лет пользуюсь eAccelerator и за это время всего пару багов ловил, так что вам не повезло просто, скорее всего);

                                                                                              Нет, здесь не невезение, здесь все намного хуже. Я просто не уверен что даже сейчас четко понимаю, как именно реализована связка Apace — PHP на моем сервере. А это плохо.

                                                                                              Где-то в описании eAccelerator читал, что он плохо отрабатывает, если PHP работает в режиме CGI из-за каких-то проблем с памятью. Вы так не пробовали случайно?
                                                                                                0
                                                                                                Постоянно использую его и под php-fpm (с точки зрения eAccelerator это тот же CGI), и под mod_php, и под консольные скрипты php-cli (хотя для консольных толку мало, ну да он все равно там включен). Все работает нормально (были баги, когда catch в PHP не срабатывал в некоторых случаях, но оказалось, что это конфликт с xdebug, и выключение xdebug проблему решило).

                                                                                                Кстати, еще я бы не стал связываться с Apache MPM worker. От лукавого вся эта многопоточность, в смысле — ненадежная она очень.
                                                                                                  0
                                                                                                  Под php-fpm он и у меня завелся.
                                                                                                  Вот здесь, например, в 1-м же абзаце со ссылкой на офсайт указывают
                                                                                                  eAccelerator only works with mod_php or php in fastcgi mode. It can't be used in cgi or cli because eAccelerator needs to set up shared memory, and this can only be done when all php instances that need to access it are forks of the first process


                                                                                                  По mpm_worker — согласен, буду переводиться обратно на prefork.
                                                                                                    +1
                                                                                                    Ну я и говорил — толку для консольных скриптов от него мало (как и для CGI). Но и вреда нет.
                                                                                                +5
                                                                                                Естественно там был MaxClients за сотню, память кончалась и своп тормозил сервер. Удаление одной!!! цифры с большой вероятностью все проблемы ТС решило бы.
                                                                                                  –2
                                                                                                  Вы абсолютно правы! Но вот беда — сколько я этих цифр не удалял — так и не нашел той, волшебной.
                                                                                                    +2
                                                                                                    Разработчики apache вообще — странные ребята. Знают же, что главная и самая болезненная проблема apache — медленные клиенты, и видят, как nginx прет. Ну что бы им ни встроить прямо в apache reverse-proxy? Самый наипростецкий (такой пишется на раз, строк 5000 всего или около того), но — по дефолту из коробки. Сразу бы nginx задавили обратно. Так нет же, заставляют людей кушать кактус.
                                                                                                      +2
                                                                                                      Вообще-то разве его там давно — лет этак 10 — нет? www.apachetutor.org/admin/reverseproxies

                                                                                                      Вот в чём они действительно идиоты — MaxClients надо не 150 ставить по умолчанию, а 15. B добавить комментарий про него. 90% вопросов сейчас по апачу связаны с завышенным значением.
                                                                                                        –2
                                                                                                        Я немного не об этом. Mod_proxy надо настраивать дополнительно, не всегда очевидным образом (он еще и не event-driven, кстати). Я же имел в виду, чтобы абсолютно все запросы и по умолчанию проходили через reverse proxy (исключительно для срезания медленных клиентов). Т.е. чтобы воркеры apache отстреливали контент и освобождались сразу же, а не висели в ожидании, когда клиент все примет. Всего-то и нужно, что поставить «из коробки» безусловный и простейший буфер между клиентом и тем apache, который мы имеем. Ни единой директивы конфигурации для этого добавлять не надо даже (разве что максимальный размер буфера).
                                                                                                          +3
                                                                                                          Наверно если посмотреть на сложность nginx — той части, которая событиями заведует, то ответ будет очевиден, только на отладку уйдёт несколько лет, и то не факт что будет работать — это же фактически будет комбинация воркерных процессов и event'овых, то есть тот же nginx и получится. Тем более что есть по крайней мере три популярных решения проблемы.

                                                                                                          А может быть тут другая совсем причина. Кто финансирует апач? Производители железа. Им выгодно чтобы он потреблял ресурсы, вот и сделали такого пожирателя памяти.
                                                                                                            –2
                                                                                                            Сложность nginx в этом конкретно месте не такая высокая. Сетевое взаимодействие на libev писать также довольно просто. Я выше давал оценку — 5000 строк, это немного. Насчет комбинации: тут скорее не комбинация, а просто еще один, совершенно отдельный процесс, который только и занимается, что reverse-проксированием.

                                                                                                            Apache понемногу теряет рынок, данное решение могло бы помочь ИМХО. Наверное, они не хотят рынок терять все же?..
                                                                                                  +4
                                                                                                  Когда не стало apache, не стало и данного бага тоже. Ваш способ похож на метод лечение головной боли путем отрубания головы и выращивания новой, другой расы.

                                                                                                  Не могу не вспомнить bash.org.ru/quote/415033. Конечно, можно не рубить голову, а потратить десятки лет, чтобы стать нейрохирургом и всё починить, но зачем, если новая голова отрастает за пару дней? Если использование нового инструмента даёт хороший результат с минимумом усилий, чем это хуже допиливания старого инструмента?
                                                                                                  0
                                                                                                  «Я медленно удаляю apache с сервера» — что-то мне это напоминает) Мем про плащ невидимку?
                                                                                                    0
                                                                                                    Плащик был себе вполне «видимка».
                                                                                                    Bloodninja: Oh yeah, aight. Aight, I put on my robe and wizard hat.
                                                                                                      0
                                                                                                      Да, это оно самое)
                                                                                                    +5
                                                                                                    Какие страшненькие конфиги.

                                                                                                    Вот это:

                                                                                                        if ($host ~* ^(www\.)(.+)) {
                                                                                                            set $host2 $2;
                                                                                                        }
                                                                                                        if ($host !~* ^(www\.)(.+)) {
                                                                                                            set $host2 $host;
                                                                                                        }

                                                                                                    Особенно не понятно зачем захват вокруг «www.» если все равно его не используете, и тем более не понятно зачем захваты во втором if-е.

                                                                                                    Срочно заменить на map, пока еще народ не начал себе копипастить, e. g.:

                                                                                                        map $host $host_wo_www {
                                                                                                            default  $host;
                                                                                                            ~^www\.(?P<wo_www>.+)$  $wo_www;
                                                                                                        }
                                                                                                      0
                                                                                                      Супер, спасибо огромное, буду ковыряться!
                                                                                                      Сейчас в статье подправлю
                                                                                                        0
                                                                                                        Я вам могу даже ещё лучше решение подкинуть:

                                                                                                            server {
                                                                                                                server_name ~^(?:www\.)?(?P<host_wo_www>.+)$;
                                                                                                                ...
                                                                                                            }
                                                                                                        
                                                                                                          0
                                                                                                          Выглядит просто супер!
                                                                                                          Только вот я его сейчас скорее всего включить не смогу — у меня в директиве server_name space-separated список доменов. Только если получится его срастить с этим выражением.

                                                                                                          Скажите, я правильно понимаю что директива map может быть использована в контексте http один раз для всех серверов?
                                                                                                            0
                                                                                                            «Скажите, я правильно понимаю что директива map может быть использована в контексте http один раз для всех серверов?»

                                                                                                            Директиве map все равно сколько у вас серверов. Она срабатывает в момент обращения к соответствующей переменной (в моем примере $host_wo_www).
                                                                                                        0
                                                                                                        Еще раз спасибо, можно сказать что и ради таких комментариев тоже писал статью.
                                                                                                        Во всех конфигах добавил коммент и отсылку на Ваше решение внизу статьи.
                                                                                                          0
                                                                                                          CentOS 6.0
                                                                                                          nginx 1.0.11

                                                                                                          тест конфига с директивой map выдает
                                                                                                          nginx: [emerg] "map" directive is not allowed here in /etc/nginx/conf.d/virtual.conf:6
                                                                                                            +2
                                                                                                            директиву надо задавать в секции http, а не server.
                                                                                                              0
                                                                                                              Странно, 5 минут назад ругалось.
                                                                                                              Спасибо.
                                                                                                          –19
                                                                                                          Как-то перестал читсать после 2х гигабайт рама. Вот из-за использования такого старье говно типо нгинкса и становится популярным…
                                                                                                            +2
                                                                                                            Ну не знаю, не знаю. Мне было интересно и приятно делать это все. А читать Ваш комментарий мне не приятно. Ловите "-".
                                                                                                              –4
                                                                                                              Apache — это не тормозная штуковина, которую можно заменить на темплый тамповый nginx. Это инфраструктура, связанная со многими вещами, типа Varnish, Esi, и прочим.

                                                                                                              К тому же, php5.4 быстрее работает в mod_, чем в fpm режиме, поедая одинаковое количество памяти, а nginx — динозавр времени HTTP 1.1. Эх.
                                                                                                                +6
                                                                                                                «динозавр времени HTTP 1.1»
                                                                                                                А что там у нас сейчас на дворе? HTTP 3.0? =)
                                                                                                                  –3
                                                                                                                  простите, 1.0 )
                                                                                                                    +1
                                                                                                                    Но ведь nginx поддерживает HTTP 1.1
                                                                                                                    Похоже вы не правы. =)
                                                                                                                      –2
                                                                                                                      код посомтрите. оно прикручено довольно кривым хуком )
                                                                                                                        +1
                                                                                                                        nginx поддерживает http 1.1 в сторону клиента, а в сторону сервера и 1.0 хватает (1.1 там не нужен — впрочем, они его и там тоже добавили, чтобы людям не надо было пару опций в конфигурацию добавлять лишних). А вообще — все это не имеет значения для оценки «динозаврости» ИМХО.
                                                                                                                          +1
                                                                                                                          Но вы я так понимаю смотрели, может расскажите? =)

                                                                                                                          Поддержка HTTP 1.1 и keep-alive соединений существует в nginx начиная с версии… 0.1.0 (первой публичной версии, вышедшей более 7 лет назад). =)
                                                                                                                      +3
                                                                                                                      Web 2.0, а маркетолухи обещают скоро Web 3.0 Зачем таким крупным специалистам вшивый HTTP.
                                                                                                                      –2
                                                                                                                      Я Вам верю. Просто статья про то, как новичок, не осиливший настроек Apache, на «таком старье» за выходные вытащил свой сервер из полной ж в чуть менее полную с помощью «говно типо нгинкса».
                                                                                                                        +2
                                                                                                                        И как же апач инфраструктурно связан с варнишем, к примеру?
                                                                                                                        –2
                                                                                                                        и да, кстати, как мы ispconfig будете обновлять без апача? и как он будет конфиги под nginx генерировать, или вы сайты будете руками добавлять? а то, что все сайты там подчинены сложной системе привилегий, исключающей то что кто-то через дырку в вордпрессе полазает по всей файловой системе, вы помните? или вы и suexec прикрутили и научили nginx с ним работать?

                                                                                                                        вообще, статья больше о том как вы к шесьерке на коленке прикрутили газ. едет хреново, техосмотр не пройдет, но зато жрет на 20 копеек меньше.
                                                                                                                          0
                                                                                                                          Почему без апача? Апач в системе стоит, пусть себе стоит. Его еще донастроить немного — и горя знать не буду.
                                                                                                                          Конфиги для nginx генерировать не надо. В статье же написано (ах, простите, вы не читали). Вновь добавленные через панель управления сайты будут обслуживаться nginx-сервером proxy. Потом уже ручками их можно будет перенести на один из php-fpm серверов.

                                                                                                                          И я не думаю, что при обновлении ISPConfig возникнут проблемы. С версии 3.0.4 он поддерживает nginx. Придумаю что-нибудь.
                                                                                                                            –4
                                                                                                                            ключевое слово: «уже ручками их можно будет перенести на один из php-fpm серверов».

                                                                                                                            читал. просто не хочу спорить о fpm и прочих глючных штуках.
                                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                        0
                                                                                                                        А они возьмут и поставят по нему веб сервер.
                                                                                                                          0
                                                                                                                          Пусть ставят, создадут рабочие места для настоящих админов, которым их творчество придётся разгребать.
                                                                                                                        +1
                                                                                                                        У вас клиенты юзают php, запущенного под юзером www.
                                                                                                                        Для каждого клиента безопаснее запускать свой сокет. Там же можно крутить персональные настройки и лимиты php.
                                                                                                                          +1
                                                                                                                          Тоже хотел это написать + cgi.fix_pathinfo = 0 в php.ini обязательно
                                                                                                                          0
                                                                                                                          Спасибо, поковыряю.
                                                                                                                            +5
                                                                                                                            Ну ничего себе!

                                                                                                                            Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+...

                                                                                                                            Ничего себе, «слабое железо»! (таг на топике).
                                                                                                                            Автор, очевидно, не в крусе mainstream предложений по хостингу для бюджетных сайтов.

                                                                                                                            Когда чуток подрастаешь «за» shared hosting, то на рынке предалаются недорогие VPS
                                                                                                                            с процом далеко не Athlon 3500, и оперативы не 2Gb а от 256Mb.
                                                                                                                            И такие предложения начинаются в общем-то от 10$/мес.

                                                                                                                            Это я всё к тому, что если речь идет о вебе
                                                                                                                            (php, nginx и т.п.)
                                                                                                                            то для 10-20 сайтов per server уровня «страничка фирмы»,
                                                                                                                            «авторского» железа тут за глаза хватит и на гораздо бОльшую нагрузку.

                                                                                                                            Это — так, просто, мнение.
                                                                                                                            За шаринг опыта — спасибо.

                                                                                                                            Я для себя уже какое-то время назад перешел на lighthttpd (с php и mysql) и доволен.
                                                                                                                            И результатами load-тестинга (согласно вложенным 10$) в том числе.
                                                                                                                              0
                                                                                                                              Наверное вы правы, первопричина проблем здесь не в железе, а в неумении воспользоваться его возможностями целиком.
                                                                                                                              Тэг подправил
                                                                                                                              –4
                                                                                                                              ЗАКАЗАТЬ-КУПИТЬ эту книгу в ОЗОН
                                                                                                                              Издана книга «Unix и Linux. Руководство системного администратора»
                                                                                                                              Эви Немет и др., 4-е издание, 1312 стр., «ВИЛЬЯМС», 2012

                                                                                                                              В интернет-магазине OZON.ru эту книгу уже можно сейчас заказать-купить

                                                                                                                              В блоге Виктора Штонда обсуждается только что вышедшая новая книга «Unix и Linux. Руководство системного администратора» Эви Немет
                                                                                                                                0
                                                                                                                                Это намек, что автору стоит что-то почитать? Или реклама Озона? Да, выше уже рекомендовали и именно эту книгу. В той же ветке я высказал опасение, что еще не дорос до такой серьезной вещи.

                                                                                                                                У меня даже внутренний спам-фильтр обрезал уведомление об этом комментарии))))
                                                                                                                                  0
                                                                                                                                  Это НЕ реклама ОЗОНа — это ИНФОРМИРОВАНИЕ о выходе важной книги, которую многие здесь ожидают
                                                                                                                                    0
                                                                                                                                    Ок, извините, был не прав.
                                                                                                                                    –2
                                                                                                                                    Подача обложки и параметров книги — это плохо?
                                                                                                                                      +4
                                                                                                                                      Хреново пихать туда свой реферальный код.
                                                                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                    +3
                                                                                                                                    За бэкграундом топика чувствуется «бюджет»

                                                                                                                                    Боюсь что не понял фразы. Вы утверждаете, что я кому-то что-то заплатил за написание поста? Или сам получил деньги от Игоря Сысоева? Или что за моей спиной стоит толпа системных администраторов и я сейчас довольно потираю потные ладошки в предвкушении сотен обратившихся клиентов, которым я (стоящие за моей спиной админы) небезвозмездно побегу(т) настраивать сервера? (Ох я вам там понастраиваю!)
                                                                                                                                    Я даже хотел бы, чтобы это было так. Чтобы статью мне за бабки какой-нибудь юный Пелевин написал. Чтобы это было просто вложением в рекламу моего растущего бизнеса. А я все выходные провел где-нибудь на Мальдивах, в понедельник прилетел, перечитал дал перечитать статью техническому директору (или еще какой-нибудь IT-шишке), он бы внес корректировки, чтобы все выглядело как первые шаги смышленого новичка.

                                                                                                                                    Посмотрите пожалуйста профиль — там написано — «я фрилансер». Я ни черта не смыслю в настройке серверов. Все знания — из гугла. Не уверен, что меня стоит использовать как админа — в первую очередь потому что я не могу гарантировать работоспособность даже собственного сервера. Второй день смотрю и нарадоваться не могу, что он не падает.
                                                                                                                                    Почитайте комментарии выше. Там меня в основном ругают. Я сделал довольно много глупостей в процессе настройки, и уже сам это понимаю. Ни в коем случае не в обиду Вам сказано — но, судя по другим Вашим комментариям, Вы этих ошибок не видите. Мы все мир через призму видим, у каждого своя.

                                                                                                                                    Елки-палки! Потратил два вечера (или ночи?), написал статью. Думал будет кому-то полезно. Думал выложу на Хабр — пусть такие же, как я, горе-админы потратят 2 часа вместо 2 дней на идентичную настройку. Может, кто-то что-то в комментариях для себя интересное найдет. Каюсь, целый день как идиот бегаю в профиль, смотрю на рейтинг/карму (Хабразависимость?). На комментарии стараюсь отвечать.
                                                                                                                                    Ко всему был готов — и что на вопросы из поста никто не ответит, и что ругать начнут за то, что своими грязными ручонками без теоретических знаний и толстых книг полез к святому, и железо старьем обзывать будут, и наоборот («да я бы на таких ресурсах огого!»). Но к тому, что обвинят в проплаченной рекламе готов не был, извините.
                                                                                                                                      +1
                                                                                                                                      Да не стоит ворчать, Вы написали, я узнал для себя много нового, за что Вам спасибо :)
                                                                                                                                        0
                                                                                                                                        Хоть скажите — в чем именно из перечисленного Вы меня подозреваете?
                                                                                                                                          0
                                                                                                                                          Извините, не сразу разглядел у кого спрашиваю
                                                                                                                                          0
                                                                                                                                          >Думал выложу на Хабр — пусть такие же, как я, горе-админы потратят 2 часа вместо 2 дней на идентичную настройку.

                                                                                                                                          Ну скорее горе-админы поймут, что надо всё-таки попроще сначала сделать — поставить MaxClients 10 и поставить nginx в стандартной конфигурации. Если проблемы исчезнут — работа закнчена. И это не два вечера, это минут 10 :)

                                                                                                                                          Не рекламы ресурса ради, — forum.searchengines.ru/forumdisplay.php?f=56 — каждый день обсуждение c хэппиэндом на тему как nginx лихо решает все проблемы. Ну и несколько замечаний по ходу обсуждения какие проблемы он решить не может.
                                                                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                          –2
                                                                                                                                          Хотите про оптимизацию? Будет Вам оптимизация.
                                                                                                                                          это не собственный опыт, но работа рядом с высоко-нагруженными системами немного дала опыта.
                                                                                                                                          Ненужные пункты можно выкинуть:
                                                                                                                                          Сетевая инфраструктура:
                                                                                                                                          L1/2/3: свичи, роутеры, линки между компонентами — 10 -> 100 — 1000 — оптика/fibre…
                                                                                                                                          Каждый элемент по своему — в зависимости от того, кто что использует. Иногда даже стоит сменить железку/производителя.
                                                                                                                                          Сеть — вланы, днс, балансеры, брандмауеры.
                                                                                                                                          Сами сервера:
                                                                                                                                          Вы не поверите, но совет сменить сетевую карточку — очень дельный. Даже хороший набортный гигабит сменить на внешнюю серверную интел может ощутимо помочь — иногда дешевле купить сетевую карту за сто баксов, к примеру, если это не совсем старый proliant G4 на вполне себе современном ксеоне.
                                                                                                                                          Про процессора, память, носители говорить не буду — SAS/NAS/RAID, SSD, на выбор, усмотрение — каждый выбирает то что ему удобнее.
                                                                                                                                          Корпуса, охлаждение, системы питания — блоки питания, упсы, генераторы
                                                                                                                                          стойки, кабельные органайзеры до кучи — оптимизация потоков воздуха.

                                                                                                                                          Теперь самое вкусное.
                                                                                                                                          начнем с оптимизации параметры ядра — размеры буферов сетевого и не только стека, потоки, квоты, использование памяти, планировщик.
                                                                                                                                          Оптимизация и отключение ниспользуемых модулей — что отключить, что в ядро, что в подключаемые по запросу.
                                                                                                                                          Оптимизация параметров файловых систем: размеры кешей, таймауты, распределение компонентов системы и сайтов по носителям — кеши, динамику, статику, скрипты, мультимедиа.
                                                                                                                                          Оптимизация сервисов — dns, ssh, ftp.
                                                                                                                                          Продумывание структуры фронтенда, бекенда, баз данных — ну и, соответственно оптимизация сервисов БД, самих баз.
                                                                                                                                          Оптимизация вебсерверов apache, nginx, lighthttpd, модулей вебсерверов — php, perl, python, cgi
                                                                                                                                          Я на одном проекте вообще встречал схему — dns balancer, сквид, nginx, и дальше по проектам — что-то лучше работало на apache 2, что-то жило на apache 1.
                                                                                                                                          причем все это было разнесено на десятки хостов — пачками фронтенды, бекенды, кеши, сервера бд.
                                                                                                                                          ну и последние фазы — не забываем про тщательную документация всего и вся и всех изменений, конфигурацию в свн, распространение контента по нодам, мониторинг, и централизованное управление нодами.
                                                                                                                                          и да, обновление.
                                                                                                                                          и тестирование обновлений в отдельной среде.

                                                                                                                                          Может я какие фазы забыл, но вот те с которыми регулярно сталкивался, вроде все описал.

                                                                                                                                          фух, выдохнул. пойду ка я дальше, писать скрипт на повершелле.
                                                                                                                                            0
                                                                                                                                            совет сменить сетевую карточку — очень дельный

                                                                                                                                            Да верю я, просто как Вы считаете — может ли в моем случае именно сетевая быть bottleneck'ом?
                                                                                                                                              0
                                                                                                                                              Сложно сказать, если честно, но помню как лет 6 назад знакомые в ДЦ очень придирчиво тестировали серверные карточки и меняли несколько серверов MS SQL с интел на топовые амд по тому времени, потому как прирост производительности сходу был в районе 15% на тестах на базе, развернутой из ночного бекапа на стенде
                                                                                                                                            0
                                                                                                                                            Не понимаю, как можно допускать людей, которые пользуются веб-панелями и советами из интернета (которых не понимают толком) к администрированию серверов и написанию об этом статьи на Хабре. Изучили бы основные принципы работы *nix — подобных систем, их архитектуру, права, файловые системы, /proс и /sys, bash с утилитами, bash-скрипты, монтирование дисков, менеджер устройств, блочные и строчные устройства, логи, утилиты мониторинга, сетевые протоколы, пакетные менеджеры, пам, nss-switch, iptables, сборку и компиляцию и что я еще забыл? Прочитали бы хотя бы несколько десятков man-страниц, руководство по apache, PHP и nginx. И после этого брались бы за сервера и статьи.

                                                                                                                                            Статья начинается с «То ли сайтов стало больше, то ли посещаемость их так сильно выросла, то ли активная разработка». То есть даже не разобравшись в причине проблем, автор полез «оптимизировать» сервер.

                                                                                                                                            Мышление в стиле «это не работает, давайте попробуем это» — это уж точно не тот путь, по которому должны идти читатели статьи-начинающие компьютерные специалисты.
                                                                                                                                              +1
                                                                                                                                              Извините, хотел ответить, но сначала заглянул в профиль. Еще раз извините. ))))
                                                                                                                                              –1
                                                                                                                                              Вы человек со стальными нервами. И похоже, учитесь гораздо быстрее меня. Я с nginx потратил уже не одни выходные!
                                                                                                                                                +3
                                                                                                                                                Этот топик, как мне кажется, совсем не об apache и nginx, а о том, как не надо заниматься администрированием, и как найти себе массу граблей из-за не понимания процессов, которые происходят и не знания основ. Какие-то метания с гуглением, вместо изучения проблем и их решения.
                                                                                                                                                  +3
                                                                                                                                                  Не знаю что там за 40 сайтов конечно, но не думаю, что они генерируют такую нагрузку, что не может справиваться один такой сервер с 2 гигами мозгов.

                                                                                                                                                  У меня на почти аналогичном сервере (только двухядернике, 2 гига рама) держит в день до 40000 уников и чуть более 100000 хитов и даже не кашляет (LA редко выше 2 в пиках), при этом это не много, можно выжать еще больше (это всего один сайт), думаю даже намного больше, есть что оптимизировать и куда расти.

                                                                                                                                                  Стоит nginx (реверс прокси)+apache (оттюненный)+mod_php+mod_dav_svn+eaccelerator.

                                                                                                                                                  Я бы на месте автора сначала поискал затыки и тогда уже думал, что делать, а не бороться с ветряными мельницами, не поняв своего врага.
                                                                                                                                                    0
                                                                                                                                                    вы на php 5.2 всё еще, раз используете eAccelerator? Это не вариант для 5.3
                                                                                                                                                      0
                                                                                                                                                      Где-то можно почитать о php 5.3 + eAccelerator?
                                                                                                                                                        0
                                                                                                                                                        Нашел одну ссылочку, если кому интересно. Действительно видел такую ошибку на сайтах, использующих Apache (думал, что проблема из-за cgi, а тут описана такая же ошибка при использовании basepath). Опять — таки нужно будет поиграться и применить.

                                                                                                                                                        kryoz, спасибо, натолкнули на решение.
                                                                                                                                                          0
                                                                                                                                                          Насколько я помню по данному вопросу главная проблема в отсутствии дальнейшей разработки eAccelerator.
                                                                                                                                                          Поэтому интерес сместился в сторону XCache и Php-Apc. Лично я предпочитаю последнее решение.
                                                                                                                                                          Не стоит благодарить. Не исключено, что eAccelerator будет работать нестабильно
                                                                                                                                                      0
                                                                                                                                                      Ни на ноутбуке, ни на сервере самописные сайты на Zend Framework работать отказываются наглухо, по ощущениям даже не создается объект Application — пойдем перепроверять base_path.

                                                                                                                                                      А как ругается то?
                                                                                                                                                        0
                                                                                                                                                        Как обычно — open_basedir restriction in action…
                                                                                                                                                          0
                                                                                                                                                          Надо перед компиляцией в файле eaccelerator.c:867 заменить строчку:
                                                                                                                                                          if (php_check_open_basedir(realfilename TSRMLS_CC)) {
                                                                                                                                                          на
                                                                                                                                                          if (php_check_open_basedir(p->realfilename TSRMLS_CC)) {
                                                                                                                                                        +1
                                                                                                                                                        Если вдруг автору интересно, для NginX есть mod-passenger, с которым у меня наипрекраснейше работает куча нагруженных инстансов редмайна.

                                                                                                                                                        А ещё хотелось бы автору порекомендовать поглядеть в сторону замены svn на git прямо во время миграции и не переносить его, чтоб меньше мучаться.

                                                                                                                                                        Ну и да, git-репы работают через nginx абсолютно без каких бы то ни было танцев с бубном, а gitweb/cgit и прочие — прекрасно цепляются через fcgi…
                                                                                                                                                          0
                                                                                                                                                          Остался только один нераскрытый вопрос — где можно подсмотреть success story по авторизации для git через с логином/паролем от RedMine?
                                                                                                                                                            0
                                                                                                                                                            _обычно_ для гита не используется логинопарольная авторизация, а используются ssh-ключи и пуш через git+ssh :)
                                                                                                                                                            Причём организуюся репозитории через gitolite.
                                                                                                                                                            К слову, и в redmine тоже можно настроить авторизацию по ssl-сертификату.

                                                                                                                                                            Ну и да, я говорил про pull из гит-репы по http.

                                                                                                                                                            А вот если подразумевался push в гит-репу через http, то, впринципе, особо танцевать тоже не надо, но пару раз взмахнуть бубном при чтении о настройке webdav, возможно, придётся.
                                                                                                                                                            Но мне сие не нравится меньшей секурностью, например.
                                                                                                                                                          0
                                                                                                                                                          Можно было первым шагом установить APC/Xcache и получить тот же результат.
                                                                                                                                                          Потому что кэшеры опкоа сразу приносит снижение нагрузки 3 раза, и без танцев с бубном.

                                                                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                                                          Самое читаемое