Nginx worker process грузит процессор

Обновлено: 16.05.2024

Nginx – это быстрый и легкий веб-сервер, альтернатива Apache 2. Конечно же, как и любой сервер, для оптимальной производительности Nginx нуждается в тонкой настройке.

Требования

Для выполнения данного руководства понадобятся:

новый сервер Debian 7
установленный и настроенный Nginx

Директивы worker processes и worker connections

Первые переменные, которые нужно отладить, — worker processes и worker connections.

Директива worker_processes – основа работы Nginx. Она сообщает виртуальному серверу о запущенных рабочих процессах при подключении к правильному IP-адресу или порту. Как правило, на ядро запускается 1 рабочий процесс. Большее количество таких процессов не повредит систему, но может стать причиной простаивания процессов.

Чтобы определить необходимое количество процессов, которое нужно установить в worker_processes, просто посмотрите на количество ядер. Изменив размер сервера, не забудьте проверить количество ядер и соответствующим образом отредактировать значение директивы worker_processes. Чтобы узнать количество ядер, выполните команду grep на cpuinfo:

К примеру, если данная команда вернула значение 1, то это значение нужно внести в worker_processes.

Директива worker_connections сообщает директиве worker_processes, сколько пользователей могут одновременно обслуживаться Nginx. Значение по умолчанию – 768. Однако, учитывая, что каждый браузер обычно открывает, по крайней мере, 2 соединения, этого может быть недостаточно. Именно поэтому нужно настроить worker_connections на полную силу. Чтобы проверить ограничения ядра, используйте команду ulimit:

На небольшом сервере (512 Мб) данное значение ограничивается 1024, чего вполне достаточно для начала.

Теперь нужно обновить конфигурационный файл:

Запомните: количество клиентов, которые могут быть обслужены, можно умножить на количество ядер. В этом случае можно обслуживать1024 клиентов в секунду. В дальнейшем это значение уменьшает директива keepalive_timeout.

Буферы

Размер буфера – следующий невероятно важный аспект, который требует тонкой настройки. Если размер буфера слишком мал, то Nginx придется писать во временный файл, из-за чего диску придется постоянно считывать и записывать. Прежде чем принимать какое-либо решение, нужно учесть некоторые директивы.

client_body_buffer_size: данная директива обрабатывает размер буфера клиента, то есть любые POST-запросы, отправленные на Nginx.

client_header_buffer_size: эта директива подобна предыдущей, только вместо размера буфера она обрабатывает размер заголовка клиента. Для всех целей 1K, как правило, достаточно.

client_max_body_size: максимально допустимый размер запроса клиента. Если максимальный размер превышен, то Nginx выведет ошибку 413 (Request Entity Too Large).

large_client_header_buffers: максимальное количество и размер буферов больших заголовков клиентов.

Время ожидания

Лимит времени ожидания может также резко повысить производительность.

Директивы client_body_timeout и client_header_timeout отвечают за интервал времени, на протяжении которого сервер будет ждать тело запроса или заголовок запроса от клиента. Если ни тело или заголовок не были получены, сервер выдаст ошибку 408 (Request time out).

Директива keepalive_timeout устанавливает лимит времени ожидания Keep-Alive соединения с клиентом. Проще говоря, Nginx закроет соединения с клиентом по истечении этого периода времени.

Директива send_timeout ограничивает время ответа клиенту. Она устанавливается не на всю передачу ответа, а только на две операции чтения; если по истечении этого времени клиент ничего не примет, то Nginx прервет соединение.

Сжатие Gzip

Gzip поможет уменьшить количество передач, выполняемых Nginx. Однако, будьте осторожны: установив слишком большое значение gzip_comp_level, сервер начнет расходовать циклы процессора.

Кэширование статических файлов

Можно также настроить выдачу заголовков Expires для файлов, которые не меняются и обслуживаются регулярно. Эту директиву можно добавить к существующему блоку server Nginx.

Не забудьте добавить необходимые типы файлов в вышеприведенную строку (и удалить ненужные).

Журналирование

Nginx вносит в лог каждый поступивший запрос. При использовании аналитики для мониторинга этого поведения, возможно, потребуется отключить эту функцию. Для этого просто измените директиву access_log:

Сохраните и закройте файл, а затем запустите:

Итоги

По большому счёту, правильная настройка сервера требует постоянного мониторинга и отладки. Ни одна из выше установленных переменных не закреплена навечно. Запомните: настройки сервера нужно адаптировать согласно каждому уникальному случаю. В дальнейшем может понадобиться увеличить производительность сервера при помощи балансировки нагрузки и горизонтального масштабирования.

Оптимизация веб сервера nginx позволит вам ускорить ваш сайт, сократив время ответа сервера.

Nginx это отличный веб-сервер, который уже давно зарекомендовал себя, как надежное решение даже для больших проектов. Несмотря на то, что nginx отлично работает из коробки, рекомендую проделать некоторые настройки по оптимизации, которые уменьшат время ответа сервера.

Не забывайте, что после внесения изменений необходимо проверять их корректность командой:

А чтобы применить настройки, необходимо перезапустить nginx:

Сжатие GZIP

Один из самых эффективных методов ускорить ответ от вашего веб-сервера nginx - это включить GZIP сжатие.

gzip включает сжатие.

gzip_proxied перечисляет параметры проксированных запросов, для которых будет разрешено сжатие.

gzip_disable запрещает для перечисленных параметров заголовка User-Agent сжатие. В данном примере для Internet Explorer 6 сжатие применяться не будет, так как данный браузер не умеет принимать сжатые ответы.

Кэширование

Еще один способ увеличить скорость ответа - это включить кэширвоание на стороне клиента.

Оптимизация работы соединений

Настроим несколько основных параметров, которые отвечают за количество обрабатываемых соединений и сроки их поддержания.

worker_processes - Определяет количество рабочих процессов. Обычно, выставляют равному числу ядер, но в новых версиях его лучше устанавливать в auto. По умолчанию 1

worker_connections - Устанавливает максимальное количество соединений одного рабочего процесса, то есть nginx будет обрабатывать worker_processes * worker_connections , остальные запросы ставить в очередь. Следует выбирать значения от 1024 до 4096. По умолчанию 512.

multi_accept - Позволяет принимать максимально возможное количество соединений. Иначе, процесс nginx за один раз будет принимать только одно новое соединение. По умолчанию off.

keepalive_timeout - Отвечает за максимальное время поддержания keepalive-соединения, в случае, если пользователь по нему ничего не запрашивает. Для современных систем, стоит выставить от 30 до 50. В нашем случае 45. По умолчанию 75.

reset_timedout_connection - Если клиент перестал читать страницу, Nginx будет сбрасывать соединение с ним. По умолчанию off.

client_body_timeout - Ждет выставленное количество секунд тело запроса от клиента, после чего сбрасывает соединение. По умолчанию 60.

send_timeout - Если клиент прекратит чтение ответа, Nginx подождет выставленное количество секунд и сбросит соединение. По умолчанию 60.

Оптимизация работы с файлами

sendfile позволяет использовать более совершенный системный вызов, который обеспечивает прямую передачу файла, то есть без системных вызовов read + write.

aio включает использование асинхронного обращения к файлам, что избавит от очередей запросов.

tcp_nopush позволит передавать заголовок ответа и начало файла в одном пакете.

open_file_cache по умолчанию выключена. Задает настройку для кэширования информации о файлах, с которыми работает nginx. По умолчанию выключено.

open_file_cache_valid задает время, через которое веб-сервер будет проверять актуальность данных. По умолчанию 60 секунд.

open_file_cache_min_uses задает минимальное число обращений к файлу, чтобы дескриптор файла оставался открытым в кэше.

open_file_cache_errors включает или выключает кэширование ошибок.

Безопасность

X-XSS-Protection

Заголовок X-XSS-Protection может предотвратить некоторые XSS-атаки.

Вы можете реализовать защиту XSS, используя три варианта в зависимости от конкретной потребности.

X-XSS-Protection: 0; Это полностью отключит фильтр
X-XSS-Protection: 1; Это включает фильтр, но очищает только потенциально вредоносные скрипты
X-XSS-Protection: 1; mode = block; Это включает фильтр и полностью блокирует страницу.

X-Frame-Options

Заголовок X-Frame-Options позволяет снизить уязвимость вашего сайта для clickjacking-атак. Этот заголовок служит инструкцией для браузера не загружать вашу страницу в frame/iframe. Не все браузеры поддерживают этот вариант.

Настроить X-Frame-Options можно тремя способами:

DENY : это полностью отключит функции iframe.
SAMEORIGIN : iframe может использоваться только кем-то из того же источника.
ALLOW-FROM : Это позволит размещать страницы в окнах iframe только с определенных URL-адресов.

X-Permitted-Cross-Domain-Policies

Доступно несколько вариантов настройки:

none - никакая политика не допускается
master-only - разрешить только главную политику
all - все позволено
by-content-only - Разрешить только определенный тип контента. Пример - XML
by-ftp-only - применимо только для FTP-сервера

Strict-Transport-Security

X-Content-Type-Options

Рейтинг наиболее опасных к использованию возможностей браузера возглавляет возможность Internet Explorer «угадывать» тип файла, игнорируя его MIME-тип.

При передаче от сервера к браузеру все файлы имеют тот или иной тип, который прямо указывает на суть содержимого файла. Однако, Internet Explorer имеет встроенный механизм, который позволяет по-содержимому файла переопределить его тип.

Таким образом, обычные текстовые файлы могут быть интерпретированы как JavaScript со всеми вытекающими последствиями. Например, если у вас на сайте запрещена загрузка текстовых файлов с расширениями .js пользователями, то они могут загрузить в виде картинок текстовый файл, содержащий JavaScript-код, который может быть исполнен браузером.

Подводя итог

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

Требования

Для выполнения данного руководства понадобятся:

Директивы worker processes и worker connections

grep processor /proc/cpuinfo | wc -l

К примеру, если данная команда вернула значение 1, то это значение нужно внести в worker_processes.

На небольшом сервере (512 Мб) данное значение ограничивается 1024, чего вполне достаточно для начала.

Теперь нужно обновить конфигурационный файл:

sudo nano /etc/nginx/nginx.conf
worker_processes 1;
worker_connections 1024;

Буферы

large_client_header_buffers: максимальное количество и размер буферов больших заголовков клиентов.

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 2 1k;

Время ожидания

Лимит времени ожидания может также резко повысить производительность.

client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;

Сжатие Gzip

gzip on;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/x-javascript text/xml text/css application/xml;

Кэширование статических файлов

* .(jpg|jpeg|png|gif|ico|css|js)$ expires 365d;
>

Не забудьте добавить необходимые типы файлов в вышеприведенную строку (и удалить ненужные).

Журналирование

Сохраните и закройте файл, а затем запустите:

sudo service nginx restart

Итоги

От переводчика:
Речь пойдет о тонкостях настройки связки Nginx + PHP-FPM в виде небольшого сборника советов. Перевод вольный. Ориентированно на пользователей Linux.

Советы по настройке и оптимизации Nginx

Обычно файлы конфигурации Nginx хранятся в /etc/nginx .

Один из удобных способов организации файлов конфигурации в стиле Debian/Ubuntu Apache:

Файлы виртуальных хостов разделены на две директории. Директория sites-available может содержать любые файлы: тестовые, старые конфиги, копии конфигов и прочие. А директория sites-enabled содержит только реально работающие конфигурации, в действительности являющиеся только символическими ссылками на файлы в директории sites-available .

Не забудьте добавить следующие строки в файл nginx.conf :

Настройки по умолчанию хороши, но их стоит немного оптимизировать: max_clients = worker_processes * worker_connections .

Базовые настройки Nginx могут обрабатывать сотни одновременных соединений:

Обычно 1000 одновременных соединений на один сервер это хорошо, но порою другие части, например жесткий диск могут оказаться медленными и это приведет к тому, что Nginx будет заблокирован на операции ввода-вывода (I/O). Чтобы избежать блокировки используйте, например, следующие настройки: одни worker_process на ядро процессора :

Worker Processes

Чтобы определить сколько ядер имеет ваш процессор, введите:

В данном случае у меня четыре ядра, поэтому окончательный парамерт worker_processes устанавливаем как 4:

Worker Connections

Лично я придерживаюсь 1024 соединений на один воркер, потому что у меня нет никаких оснований для повышения этого значения. Но если например 4096 соединений в секунду не хватает, то можно попробовать удвоить 2048 соединений на процесс.

Окончательные настройки выглядят седующим образом:

Кэш браузера сохранит ресурсы и пропускную способность вашего сервера. Это несложная настройка Nginx позволит выключить ведение логов ( access log и not found log ), и установить срок истечения заголовка в 360 дней.

* \ . ( jpg | jpeg | gif | png | css | js | ico | xml ) $

Если вы хотите более сложный заголовки или другие типы файлов, то вы можете настроить их отдельно.

Вы можете использовать по умолчанию стек tcp/ip или соединение через Unix-сокет. Также необходимо установить PHP-FPM слушать точно такой же ip:port или Unix-сокет. Вот очень простой пример конфигурации (вариант с Unix-сокетом закоментирован):

fastcgi_param SCRIPT _ FILENAME $ document_root $ fastcgi_script_name ;

Это дает возможность запуска PHP-FPM другим сервером.

Это очень распространено, когда корень сервера или другие публичные каталоги имеют скрытые файлы, которые начинаются с точки (.) И, как правило, они не предназначены для пользователей сайта. Публичный каталог может содержать файлы системы контроля версий: .git , .svn ; файлы IDE: .idea ; .htaccess файлы. Настройки запещают доступ к скрытым файлам и отключают ведение логов:

Советы по настройке и оптимизации PHP-FPM

Обычно конфигурации PHP-FPM расположенны в файле /etc/php-fpm.conf и в каталоге /etc/php-fpm.d/ . Весь пулл конфигов расопложен в дикертории /etc/php-fpm.d/ . Чтобы это работало, вы должны добавить следующую строку в php-fpm.conf :

Настройки emergency_restart_threshold , emergency_restart_interval и process_control_timeout по умолчанию выключены, но я считаю что их стоит влючить, например, со следующими значениями:

Что это значит? Если 10 дочерних процессов PHP-FPM завершатся с помощью SIGSEGV или SIGBUS в течении 1 минуты, то PHP-FPM перезагрузится автоматически. А также дочерним процессам установлен лимит времени реакции в 10 секунд на сигнал от мастера.

В PHP-FPM возможно использовать отденьные пулы для каждого сайта и точно распределять ресурсы, а также использовать разных пользователей и разные группы для каждого пула. Приведем примеры конфигураци трех различнх сайтов (или фактически три части одного сайта):

/etc/php-fpm.d/site.conf
/etc/php-fpm.d/blog.conf
/etc/php-fpm.d/forums.conf

Примеры конфигурации каждого пула:
/etc/php-fpm.d/site.conf

/etc/php-fpm.d/blog.conf

/etc/php-fpm.d/forums.conf

slowlog = / var / log / php - fpm / slowlog - forums . log

Это просто примеры как настроить несколько различных пулов.

Приемлемым значнием pm.max_children будет 9. Это значние основанно на среднем значении и возможно далее его необходимо будет изменить, когда вы заметите длительное время использования памяти процессом. После быстрого тестирования несложно выбрать значния pm.start_servers value , pm.min_spare_servers и pm.max_spare_servers .

Окончательная конфигурация нашего примера может выглядеть следующим образом:

Читайте также: