text Настройкаphp-fpm，nginxнаvps

Posted 2021-05-02

В этом мануале мы попробуем настроить связку nginx и  php-fpm, так чтобы она могла работать на бесплатном тарифе. В уме мы держим, что в результате на этом сервере будет бежать drupal (весьма требовательный к ресурсам движок), но настройки подойдут и для массы других cms.
 
Надо сказать, что львиная доля этого how-to — это перепечатка (естественно с согласия авторов) статьи на [url=http://nixclub.pro/node/31]nixclub.pro[/url] Евгения Верещагина и Александра Кубашина, поскольку они написали, ну буквально про нас и написали хорошо.
 
Перед началом рекомендуем минимально настроить сервер с помощью [url=http://forum.serverscamp.com/viewtopic.php?f=14&t=202]этого[/url] руководства.
 
Далее текст перепечатки:
 
0.0 Введение (или зачем эта статья)
 
В Сети очень много руководств по настройке отдельных частей и компонентов web-серверов, а вот вменяемого описания по настройке web-сервера от А до Я найти достаточно сложно. Данная статья является описанием нашего опыта по установке и настройке веб-сервера при ограниченном числе ресурсов.
 
0.1 Что имеем:
 
Сервер в минимальной VPS-конфигурации: 5Gb HDD, 256Mb RAM.
Debian Squeeze, в качестве системы.
Желание поднять на этом "железе" сервер, на котором будет крутиться сайт под управлением Drupal 7.
В перспективе иметь возможность поднять ещё несколько виртуальных доменов.
 
0.2 Почему не Apache...
 
Apache является самым популярным сервером в современной Сети. Он имеет огромное число возможностей, много дополнительных модулей и кучу документации по настройке. Но невероятная гибкость Apache приводит к тому, что его грамотная настройка требует большого опыта (а поддержка web-серверов не является нашей профессиональной деятельностью), к тому же он весьма требователен к ресурсам, а мы в них очень ограничены.
 
0.3 Наш выбор
 
В качестве решения для нашего сайта мы выбрали связку из Nginx и PHP-FPM. Если очень коротко и не совсем точно, то первый является "лёгким" http-сервером, а второй тем, кто будет обрабатывать php-скрипты.
 
1.0 Поехали!
 
Найти пакет php5-fpm в официальных репозиториях Debian Squeeze не выйдет, нет его и в Backports. Зато есть очень достойный репозиторий на dotdeb.org, им мы и воспользуемся.
 
Прим. artleg: если вы воспользовались руководством про первоначальную настройку, то у вас уже добавлен этот репозиторий и ключ к нему.
 
1.1 Подключение репозитория
 
Добавляем информацию о репозитории в систему
 
echo "deb http://packages.dotdeb.org squeeze all" > /etc/apt/sources.list.d/dotdeb.list
Импортируем ключ
 
wget http://www.dotdeb.org/dotdeb.gpg
cat dotdeb.gpg | apt-key add -
Обновляем список пакетов
 
apt-get update
1.2 Установка основных пакетов
 
Прим. artleg: перед установкой рекомендуется убить процесс apache2, который запускается при каждом рестарте сервера (дефолтный конфиг openvz, который пока не переделан).
killall apache2
 
apt-get install nginx php5-cli php5-common php5-suhosin php5-cgi php5-fpm mysql-server php5-mysql php5-gd
Последние 3 нужны именно для Drupal (впрочем, и для большинства других сайтов).
 
Прим. artleg: поскольку на serverscamp.com к каждому тарифу предоставляется доступ и к  mysql-серверу, то рекомендую исключить mysql-server в целях облегчения оптимизации и экономии ресурсов.
 
1.3 Создание каталога для сайтов и установка прав
 
Все наши сайты физически будут находится в каталоге /var/www, который в случае отсутсвия нужно создать командой:
 
mkdir /var/www
Кроме того необходимо дать права на изменение этих файлов веб-серверу, точнее пользователю от которого он запущен (в Debian Nginx запускается от пользователя www-data). Команды по изменению владельца и установки соответствующих прав можно объединить в одну строку:
 
chmod -R a-rwx,u+rwX,g+rX /var/www && chown www-data:www-data -R /var/www
После загрузки и распаковки движка, дополнений или обновлений необходимо выполнить эти команды повторно.
 
На этом разминка закончилась, переходим непосредственно к настройке.
 
 
2.0 Настройка Nginx
 
Несмотря на то, что конфигурация Nginx состоит из нескольких файлов, сам nginx начинает читать единственный файл: /etc/nginx/nginx.conf, все остальные подключаются директивой include. С него и начнём:
 
2.1 /etc/nginx.conf
 
Прим. artleg:  у вас путь до конфига будет /etc/nginx/nginx.conf  
 
Большинство настроек (не все) повторяют конфиг, поставляемый с nginx, а наиболее интересные моменты снабжены комментариями.
 
user www-data;
# Рекомендуется устанавливать по числу ядер
worker_processes 1;
pid /var/run/nginx.pid;
# Директива уменьшает разрешение времени в рабочих процессах, за счёт чего уменьшается число системных вызовов gettimeofday().
timer_resolution 100ms;
worker_rlimit_nofile 8192;
error_log  /var/log/nginx/error.log;
events {
    # Максимальное число подключений к серверу на один worker-процесс
        worker_connections 1024;
    # Эффективный метод обработки соединений, используемый в Linux 2.6+
    use epoll;
}
http {
        ##
        # Базовые настройки
        ##
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65; #Прим. artleg: часто имеет смысл уменьшить это значение, я выставляю 5
        types_hash_max_size 2048;
        # При ошибках не говорим врагу версию nginx
        server_tokens off;
        include /etc/nginx/mime.types;
        default_type application/octet-stream;
    ##
    # Настройка логов
    ##
        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;
        ##
        # Настройки сжатия
        ##
    gzip on;
    gzip_disable "msie6";
        ##
        # Настройка виртуальных доменов
        ##
        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}
2.1 Настройка виртуального домена
 
Прим. artleg: Рекомендуется просто ознакомиться с пунктом 2.1 данного руководства, а сделать по пункту 2.2 (см. ниже).
 
В стиле Debian все файлы настройки виртуальных доменов создаются в каталоге /etc/nginx/sites-available, а для того, чтобы этот домен активизировать нужно просто создать символическую ссылку на этот файл в каталоге /etc/nginx/sites-enable. Мы советуем не отходить от этой практики.
 
В качестве примера будем использовать домен test.nixclub.ru:
 
# Настрока редиректов c url вида http://foo.test.nixclub.ru/bar на url http://test.nixclub.ru/bar
server {
        listen 80;
        server_name *.test.nixclub.pro;
        rewrite ^(.*)$ http://test.nixclub.pro$1 permanent;
}
 
# Настройка виртуального домена:
 
server {
    ##
    # Уникальные настройки для домена
    ##
    server_name test.nixclub.pro;
    # Папка с контентом сайта (удобно, когда совпадает с именем домена)
    root /var/www/test.nixclub.pro;
    # Настройка логов, каждому виртуальному домену - свой лог
    access_log /var/log/nginx/test.nixclub.pro-access.log;
    error_log /var/log/nginx/test.nixclub.pro-error.log;
    ##
    # Типовые настройки общие для всех доменов (если не захочется экзотики)
    ##
    listen 80;
    index index.php;
    # Реализуем "красивые" ссылки для Drupal (и для ряда других CMS)
    location / {
    try_files $uri $uri/ /index.php?q=$uri&$args;
    }
    # Передаём обработку PHP-скриптов PHP-FPM
    location ~ \.php$ {
 
  # Соединение по TCP.
    fastcgi_pass   127.0.0.1:9000;
    # На виртуальных хостингах VPS(OpenVZ, etc) полезно соединяться через сокет
    # так как число TCP соединений может быть ограничено.
    # (пример натройки php-fpm через сокет есть в разделе 3.5)
    #Прим. artleg: на  serverscamp.com сокет следует располагать внутри папки /var/www что также будет полезно при настройке chroot php-fpm (см. ниже)
    # fastcgi_pass   unix:/tmp/newpool.sock;
 
    fastcgi_index  index.php;
    fastcgi_intercept_errors on; # только на период тестирования
    # Включаем параметры из /etc/nginx/fastcgi_param
    include fastcgi_params;
    # Путь к скрипту, который будет передан в php-fpm
    fastcgi_param       SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    fastcgi_ignore_client_abort     off;
    }
    # Закрываем доступ к файлами .htaccess и .htpassword
    location ~ /\.ht {
        deny  all;
    }
}
 
2.2 Шаблоны сайтов в nginx
 
Когда доменов становится много и почти все их параметры копируют друг друга, то начинаешь задумываться: а нельзя ли вынести повторяющиеся моменты в отдельный файл. Особенно остро необходимость в этом встаёт, когда нужно внести однотипные изменения сразу в десяток конфигурационных файлов.
Чтобы решить эту проблему мы изначально поделили настойки на две части: уникальную для домена и типовую, общую для "большинства". Типовую часть можно вынести в файл /etc/nginx/templates/drupal (или любой другой, на Ваш вкус) и подключать её директивой include.
 
При таком подходе конфигурация домена будет выглядеть так:
 
server {
        listen 80;
        server_name *.test.nixclub.pro;
        rewrite ^(.*)$ http://test.nixclub.pro$1 permanent;
}
server {
    listen 80;
    server_name test.nixclub.pro;
    # Папка с контентом сайта (удобно, когда совпадает с именем домена)
    root /var/www/test.nixclub.pro;
    # Настройка логов, каждому виртуальному домену - свой лог
    access_log /var/log/nginx/test.nixclub.pro-access.log;
    error_log /var/log/nginx/test.nixclub.pro-error.log;
# Подключаем шаблон
 
include /etc/nginx/templates/drupal;
 
}
 
А сам файл шаблона (/etc/nginx/templates/drupal) будет содержать следующие строки:
 
    index index.php;
    # Реализуем "красивые" ссылки для Drupal (и для ряда других CMS)
    location / {
    try_files $uri $uri/ /index.php?q=$uri&$args;
    }
    # Передаём обработку PHP-скриптов PHP-FPM
    location ~ \.php$ {
    # Соединение по TCP.
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_intercept_errors on; # только на период тестирования
    # Включаем параметры из /etc/nginx/fastcgi_param
    include fastcgi_params;
    # Путь к скрипту, который будет передан в php-fpm
    fastcgi_param       SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    fastcgi_ignore_client_abort     off;
    }
    # Закрываем доступ к файлами .htaccess и .htpassword
    location ~ /\.ht {
        deny  all;
    }
2.3 Применение новых параметров
 
После изменения настроек nginx необходимо выполнить команду:
 
service nginx reload
 
 
При этом работа сайта ни на мгновение не останавливается, а если допущена синтаксическая ошибка, то nginx сообщит об этом и продолжит работать с предыдущей (корректной) конфигурацией.
 
2.4 Проверка работоспособности
 
Хотя подробная настройка PHP-FPM описана в следующем разделе, настроек по умолчанию вполне достаточно для проверки работы его связки с Nginx. Для этого мы создадим файл checkalive.php в корневом каталоге сайта (в нашем случае это /var/www/test.nixclub.pro/) следующего содержания:
 
<?php phpinfo(); ?>
 
И если конфигурация корректна, то при обращении к данному скрипту из веб-браузера (в нашем случае: http://test.nixclub.pro/checkalive.php) должна отобразится информация о текущих настройках PHP. Наличие этого скрипта на сервере является небезопасным, поэтому сразу после тестирования его лучше удалить!
 
Прим. artleg: Если  при переходе на http://test.nixclub.pro/checkalive.php вас встречает весёлая надпись «Welcome to nginx»,  то добавьте в каталог /var/www/test.nixclub.pro  пустой файл index.php, перейдите по адресу http://test.nixclub.pro/, а потом уже на http://test.nixclub.pro/checkalive.php
 
2.5 .htaccess !
 
В Nginx нет никакого аналога апачевского .htaccess, поэтому если работа сайта требует его наличия, то придётся переписывать его содержание в соответствии с синтаксисом nginx в основную конфигурацию домена. В нашем конфиге .htaccess был заменён следующим блоком:
 
  location / {
    try_files $uri $uri/ /index.php?q=$uri&$args;
    }
 
 
3.0 Настройка PHP-FPM
 
Конфигурация PHP-FPM в Debian разбита на две части: глобальную (/etc/php5/fpm/php-fpm.conf) и настройки для так называемых пулов (/etc/php5/fpm/pool.d/*.conf). Глобальные настройки мы трогать не будем, а вот настройки для пулов обсудим достаточно подробно.
 
3.1 Пулы
 
Для начала разберёмся зачем нужны пулы. В случае разных требований сайтов к PHP-окружению (различные параметры php.ini, разное число обработчиков и т.д.) может потребоваться создание дополнительных пулов. Данная операция в PHP-FPM весьма тривиально:
 
Настройка каждого пула в Debian представлена своим файлом в каталоге /etc/php5/fpm/pool.d/. По умолчанию системе есть единственный пул "www" (файл: /etc/php5/fpm/pool.d/www.conf) именно его настройкой мы и займёмся.
 
3.2 Workers (обработчики)
 
Самая спорная часть в настройке пула, это количество обработчиков php-скриптов. На первый взгляд, кажется, что чем больше обработчиков, тем эффективней обрабатываются php-скрипты. Но это не так! Во-первых: большое число обработчиков расходует больше памяти (а для нашего сервера память весьма критичный ресурс), во-вторых: если обработчиков очень много и, так случилось, что все они реально заняты работой, то у сервера может просто не хватить ресурсов на другие задачи (даже есть вероятность, что подключение по SSH станет практически не возможным).
 
Из личного опыта: на сайте с ~200 посетителями в сутки, среднее число обработчиков за единицу времени существенно меньше 1. В идеале число обработчиков должно быть таким, что даже при стрессовой нагрузке LoadAvarage системы оставался в разумных пределах. Т.е. пусть лучше при высокой нагрузке пользователи периодически получают сообщения о недоступности сервиса (ошибка 502: Gateway timeout), чем полная недоступность сервера даже для администратора.
 
В результате тестирования (о тестировании будет написано дальше) были выбраны следующие параметры:
 
    # Выбираем динамический режим создания процессов, т.е.
    # число запущенных процессов PHP-FPM будет зависеть от текущей нагрузки
    pm = dynamic
    # Максимальное количество дочерних процессов.
    pm.max_children = 7
 
    # Количество дочерних процессов, стартующих сразу при загрузке сервера. Т.к. время запуска каждого
    # нового процесса отлично от нулевого, то выбираем значение больше 1, не смотря на экономию ресурсов
    pm.start_servers = 3
 
    # Минимальное чисто простаивающих процессов. Должен согласовываться по логике с предыдущими
    # при экономии ресурсов будет удобно pm.start_servers = pm.min_spare_servers.
    pm.min_spare_servers = 3
 
    # Максимальное чисто простаивающих процессов. Естественно, что не более чем pm.max_children
    # и не менее pm.min_spare_servers. Остальные будут выгружены.
    pm.max_spare_servers = 4
 
Считать эти параметры "серебрянной пулей" ни в коем случае нельзя! Оптимальное число обработчиков зависит от ресурсов сервера, сложности php-скриптов, нагрузки, создаваемой на mysql-сервер и т.д. В любом случае оптимальное число обработчиков нужно подбирать на основе тестирования работы сайта.
 
 
Для запуска первого сайта на nginx данных настроек достаточно, далее идёт описание "продвинутых" возможностей PHP-FPM, некорректное использование которых может привести к "поломке" web-сервера.
 
3.3 Slowlog
 
Очень полезно знать какие скрипты выполняются слишком долго и почему так происходит. Для помощи в решении этой проблемы в php-fpm есть следующие два параметра:
 
    # Если скрипт будет выполняться больше указанного времени, то отладочная информация по нему будет записана в файл "медленных" запросов
    request_slowlog_timeout = 3s
    # Определяет путь к файлу "медленных" запросов (обязательный параметр, в случае определения request_slowlog_timeout)
    slowlog = /var/log/php-slow.log
 
3.4 Chroot
 
PHP-FPM имеет очень полезную, с точки зрения безопасности, возможность: выполнение скриптов в chroot окружении. Активация данной функции производится одноимённым параметром, для примера:
 
# Устанавливаем chroot окружение в каталоге /var/www
chroot = /var/www
Эта единственная и достаточная настройка php-fpm для chroot. Но работа в chroot вносит свои коррективы во всё, что связано с обработкой скриптов:
Во-первых, все пути php (error_log, sessions.save_path и т.д.) теперь будут относительными от директории /var/www.
Во-вторых, php-скрипты не смогут обращаться к unix-сокетам находящимися за пределами этого каталога, т.е. обращение к mysql теперь нужно делать через tcp соединение (в качестве адреса сервера нужно указывать 127.0.0.1, но не localhost!).
В третьих, не будет доступа к программам находящимися за пределами chroot. Если для отправки почты использовался /usr/sbin/sendmail, то придётся переводить работу скриптов на протокол smtp.
 
Теперь вернёмся к Nginx и обратим внимание на следующие строки внутри location ~ \.php$:
 
    # Путь к скрипту, который будет передан в php-fpm
    fastcgi_param       SCRIPT_FILENAME  $document_root$fastcgi_script_name;
Пока php-скрипты выполнялись вне chroot окружения значение переменной $document_root (равна значению директивы root для текущего запроса)  для php и статического контента совпадало (было равно /var/www/test.nixclub.pro), но после изменения настроек требуется корректировка данного параметра:
 
    # Путь к скрипту в случае использования chroot
    fastcgi_param       SCRIPT_FILENAME  /test.nixclub.pro$fastcgi_script_name;
Т.е. нам просто нужно "укоротить" путь на значение chroot, другими словами, убрать из начала пути /var/www.
 
3.5 Добавление пула
 
При увеличении числа обслуживаемых сайтов может понадобиться создание дополнительных пулов, для настройки различных параметров каждому сайту - своё. Данная операция в php-fpm, на наш взгляд, весьма тривиальна:
 
Нужно скопировать файл /etc/php5/fpm/pool.d/www.conf под новым именем (для примера назовём его newpool.conf)
Дать новому пулу имя: находим вверху нового файла строку [www] (имя первого пула) и меняем на [newpool]
Меняем адрес подключения к php-fpm (директива "listen"). Т.к. каждый адрес должен быть уникален, то нужно изменить:
listen = 127.0.0.1:9000
на
 
listen = 127.0.0.1:9001
Или, в случае использования unix-сокетов,
 
listen = /tmp/newpool.sock
Номера портов и путей к unix-сокетам во всех пулах должны быть разными!
 
3.6 Применение параметров
 
Для применения параметров после изменения php.ini (для PHP-FPM полный путь к файлу выглядит так: /etc/php5/fpm/php.ini) или собственных настроек PHP-FPM требуется перезапуск сервиса, при этом выполнение php-скриптов приостанавливается (на небольшой период времени).
 
Перезапуск производится следующей командой:
 
service php5-fpm restart
 
4.0 Немного об оптимизации
 
Грамотная оптимизация сервера требует наличия десятка сертификатов, нескольких тонн прочитанной литературы, огромного практического опыта и, конечно, правильной фазы луны. И это почти правда :)
Далее мы будем заниматься "простой" оптимизацией, польза от которой, тем не менее, тоже весьма заметна.
 
4.1 MySQL
 
Первое, что рекомендуют при оптимизации любой БД в Unix системах, это включение опции noatime для раздела с данными БД. При этом отключается запись информации о последнем обращении к файлам. Эту опцию нужно прописать в файл /etc/fstab в качестве параметра монтирования ФС. Для применения данного параметра без перезагрузки системы достаточно выполнить команду:
 
mount -o remount <точка монтирования раздела>
Далее выполним оптимизацию таблиц mysql, это делается следующей командой:
 
mysqloptimize --analyze --all-databases -u root -p
Информацию по приведённым параметрам можно (точнее нужно) посмотреть в справке по программе (man mysqloptimize).
Следующим шагом будет использование утилиты MySQLTuner. Она входит в основной репозиторий Debian, поэтому её установка весьма тривиальна:
 
apt-get install mysqltuner
Официальная документация рекомендует работу сервера хотя бы сутки, под типичной для него нагрузкой, перед использованием утилиты. А т.к. для достижения максимального эффекта нам придётся многократно запускать эту утилиту, то вместо суточного ожидания мы будем использовать короткое стресс-тестирование (подробное описание нагрузочного тестирования дано ниже).
 
При запуске утилиты будут запрошены логин и пароль администратора mysql, после чего будет выдан краткий анализ работы MySQL и набор параметров, которые рекомендуют добавить в конфигурацию сервера (/etc/mysql/my.cnf). После изменения параметров необходим перезапуск mysql:
 
 service mysql restart
Наш алгоритм использования этой утилиты выглядит следующим образом:
 
Запускаем нагрузочное тестирования web-сервера (запоминаем результаты)
Запускаем mysqltuner.
Изменяем параметры mysql в соответствии с рекомендациями утилиты.
Перезапускаем mysql.
Возвращаемся к 1-му пункту. Цикл нужно повторять до тех пор пока не закончатся рекомендации mysqltuner (чуть подробее описано ниже).
Очень часто mysqltuner при каждой итерации рекомендует увеличение одного и того же параметра (каждый раз на большее значение), причём даже после нескольких изменений подряд улучшения работы сервера нет (смотрите результаты стресс-тестирования). При этом нам известны два варианта: первый - параметр ещё не достиг значения при котором почувствуется эффект от его изменения (тут нужно просто набраться терпения и пройти ещё несколько итераций) и второй - эффект от данного параметра может и будет, но у нас просто не хватит на это ресурсов (т.е. если при очередной итерации Вам советуют выделить под какой-то параметр память сравнимую с общим объёмом в системе, а результата после этого всё равно нет, то нужно просто откатится на разумное значение этого параметра).
По нашему опыту: подбор верных параметров может увеличить общую производительность web-сервера в несколько раз!
Хотя данный набор советов весьма эффективен (как минимум для нас), но он не отменяет изучения официальной (и околоофициальной) документации по работе и оптимизации mysql сервера.
 
4.2 PHP-APC
 
Один из самых простых способов ускорения выполнения php-скриптов, это установка php-акселератора. Есть несколько весьма известных программ этого типа, но мы остановили наш выбор на php-apc (во-первых: у нас есть опыт работы с ним, во-вторых: он есть в репозитории).
Установка:
 
apt-get install php-apc
service php5-fpm restart
Уже после этих двух команд скорость выполнения php-скриптов должна возрасти, но при этом PHP-APC имеет более 30 параметров для настройки, грамотный подбор которых сможет ещё больше повысить производительность Вашей системы.
 
4.3 Swap
 
Прим. artleg: на ovz серверах, которым является наш «atom» этот номер не пройдёт.  
 
Хостер пожертвовал нам 128Mb виртуальной памяти, но нам этого явно не достаточно (сервер просто переставал отвечать при тестировании под нагрузкой), поэтому добавим ещё 512Mb:
 
dd if=/dev/zero of=/swapfile bs=1M count=512
mkswap /swapfile
swapon /swapfile
echo '/swapfile swap swap defaults 0 0' >> /etc/fstab
Если предыдущие советы рекомендуются к использованию на всех системах, то данный раздел больше применим при жёстком дефиците ресурсов.
 
5.0 Нагрузочное тестирование
 
Само по себе стресс-тестирование нам просто скажет какую максимальную нагрузку сможет выдержать сервер при текущих настройках, но нам этого не достаточно. Наша задача включает поиск "узких" мест в работе системы: какая именно программа наиболее активно использует процессор, достаточно ли памяти, не взлетел ли LoadAvarage (если Вы до сих пор не знаете, что это такое, то самое время обратится в Google).
 
5.1 Необходимое ПО
 
Во-первых, нам нужна сама утилита для нагрузочного тестирования веб-серверов. Мы остановили наш выбор на siege - это простой и при этом очень мощный инструмент. Во-вторых, нам нужна программа, отображающая текущую загрузку системы, для этих целей мы будем использовать htop (это более продвинутый вариант классической утилиты top).
 
Обе программы есть в стандартном репозитории, следовательно установка выглядит так:
 
apt-get install siege htop
5.2 htop
 
Интерфейс htop очень прост: Верхняя часть поделена на две зоны: слева отображается загрузка ядер CPU, использование памяти и swap, справа: информация по числу процессов, LoadAvarage (за 1, 5 и 15 минут) и общий uptime системы. В нижней части список процессов с наиболее полезной информацией по ним (использование CPU, памяти и т.д.).
 
При работе с программой удобнее всего включить сортировку процессов по утилизации CPU (наиболее "жадные" сверху) и всё время обращать внимание, на соотношение использования CPU и текущего LoadAvarage.
 
Для примера: если загрузка процессора далека от максимальной, память ещё не заканчивается, но при этом LoadAvarage через чур высок, то, скорее всего, узким местом является обращение к жёсткому диску (а в связке nginx+php+mysql именно последний наиболее активно его использует). Следовательно в этом случае нужно обратить больше внимания настройке mysql.
 
5.3 Siege
 
Для начала краткое описание опций программы, которые мы будем использовать:
 
-с <число> -- число одновременно запускаемых запросов;
-f <файл> -- файл содержащий набор ссылок, по которым будет обращаться программа во время тестирования;
-i -- режим "internet", в этом режиме программ случайно выбирает адреса для запросов, список адресов задаётся параметром -f;
-b -- режим "benchmark", все тесты при этом запускаются без пауз;
-t -- время тестирования.
 
Перевод документации на русский можно найти здесь: http://habrahabr.ru/blogs/webdev/65128/ .
 
В простейшем случае тестирование можно запустить так:
 
siege <url>
При этом в несколько потоков будет обращение к одному единственному <url>. Такой режим хоть и имеет определённый смысл, но сильно уступает варианту, когда программа в произвольном порядке обращается к различным адресам сайта. И здесь возникает вопрос: как получить карту сайта в формате, понимаемом, siege?
 
Почти все CMS (drupal не исключение) имеют встроенную функцию генерации файла sitemap.xml, для того чтобы его получить достаточно воспользоваться командой:
 
wget http://<домен сайта>/sitemap.xml
 
Для преобразования этого файла в формат siege мы воспользуемся одним из рецептов доступных по этой ссылке. А именно создадим файл sitemap2list.sh следующего содержания:
 
#! /bin/sh
sed -r 's/<loc/\n<loc/g; s!</loc>!</loc>\n!g' $1 | sed -r -n '/<loc>.*?<\/loc>/! D; /<loc>.*?<\/loc>/ s!</?loc>!!g; s!\s+!!g; P'
Не забываем установить права на исполнение:
 
chmod 755 sitemap2list.sh
После этого преобразование выполняется следующей командой:
 
./sitemap2list.sh sitemap.xml > usrl.txt
Файл urls.txt получен, теперь можно запускать само тестирование:
 
siege -i -b -f urls.txt
5.4 Подбор числа обработчиков php-fpm
 
При подборе параметров мы воспользовались следующим методом (возможно это даже наше know-how):
 
Устанавливаем для php-fpm в качестве максимального числа обработчиков (параметр pm.max_children) заведомо большое значение, мы использовали 20.
Производим набор тестов следующего вида:
siege -i -b -t 1m -с <num> -f urls.txt
При каждом новом тесте мы будем увеличивать <num> на 1 (т.е. при первом тесте <num> = 1, при втором 2 и т.д.). По достижении определённого значения <num> (у нас это было 8) число обработанных запросов в секунду начнёт уменьшаться, значит нам нужно выбрать значении предыдущего тестирования (для нас это 7) в качестве максимального числа обработчиков.
 
5.5 Пример для MySQLTuner
 
Для стресс-тестирования во время настройки MySQLTuner мы пользовались следующей командой:
 
siege -i -b -t 2m -f urls.txt
6.0 Заключение
 
Однажды Мастер Никеда сказал своим ученикам:
— В мире нет Абсолютной Истины.
Один из учеников спросил:
— А эта истина абсолютна?
— Нет, конечно, — улыбнулся Мастер.
 
Восточная притча
 
Как Вы поняли, данная статья не претендует на "абсолютную истину", она даже не претендует на полноту, более того она не претендует даже на завершённость, единственное на что она может претендовать: быть отправной точкой при настройке своего web-сервера.
 
6.1 Используемая литература:
 
Документация по nginx камрада Сысоева
Статья на хабре, учтите мы нашли несколько ошибок в предлагаемом конфиге
Перевод документации по siege на русский
Скрипт преобразования sitemap.xml в формат siege, так же данный блог содержит много другой полезной информации
Великий Google
 
6.2 Занавес !
 
Здесь авторы благодарят дочитавших за терпение, выключают монитор и уходят пить чай с клубничным вареньем.