Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- В этом мануале мы попробуем настроить связку 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 Занавес !
- Здесь авторы благодарят дочитавших за терпение, выключают монитор и уходят пить чай с клубничным вареньем.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement