Конфигурация php-fpm и nginx для оптимальной производительности

Я запускаю сервер nginx с php-fpm.

Я использую "c5d.xlarge"Тип экземпляра ec2 для размещения моего веб-сайта.

c5d.xlarge = 4 виртуальных процессора и 8 ГБ ОЗУ.

Если количество активных подключений превышает 10 КБ на моем ELB, загрузка ЦП превышает 60-70% на всех 15 серверах.

Конфигурация php-fpm:

pm = dynamic
pm.max_children = 65
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests = 600

Конфигурация nginx:

user  www-data;
worker_processes  4;
pid        /var/run/nginx.pid;


events {
    worker_connections  3072;
}


http {
        ##
        # Basic Settings
        ##

        charset utf-8;
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        server_tokens off;
        log_not_found off;
        types_hash_max_size 2048;
        client_max_body_size 16M;
        keepalive_timeout  70;
        client_header_timeout 3000;
        client_body_timeout 3000;
        fastcgi_read_timeout 3000;
        fastcgi_buffers 8 128k;
        fastcgi_buffer_size 128k;

        # MIME
        include /etc/nginx/mime.types;
        default_type application/octet-stream;
   log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /home/ubuntu/apps/log/default/access.log  main buffer=32k;
    error_log   /home/ubuntu/apps/log/default/error.log;


    gzip on;
        gzip_disable "MSIE [1-6]\.";

        # Only allow proxy request with these headers to be gzipped.
        gzip_proxied expired no-cache no-store private auth;

        # Default is 6 (1<n<9), but 2 -- even 1 -- is enough. The higher it is, the
        # more CPU cycles will be wasted.
        gzip_comp_level 7;
        gzip_min_length 20; # Default 20

        gzip_types text/plain text/css application/json application/javascript  application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    include /etc/nginx/conf.d/*.conf;

верхний вывод команды:

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

Если потребуется дополнительная информация, дайте мне знать.

Давайте начнем с php-fpm

pm = dynamic

Модель динамического процесса заставляет кучу рабочих ждать обработки запроса. Между тем, эти рабочие используют циклы ЦП и память. ondemand - лучший выбор для моделей процессов FPM, поскольку он масштабируется по мере необходимости. Прежде чем вы скажете "ну, демону придется fork() новый ребенок », который также является интенсивным, помните, что это не очень дорогая операция с современными ОС и оборудованием.

pm.max_children = 65

Это, скорее всего, совершенно неустойчиво, если только ваш php memory_limit установлен на 100 МБ, что никогда не бывает достаточно для запуска любого процесса PHP. Поймите, что если вы собираетесь масштабировать FPM до 65 рабочих, они все потенциально могут использовать UP для memory_limit. Без ОЗУ для резервного копирования это значение параметра является рецептом блокировки сервера.

pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 20

Я не буду их комментировать, поскольку они достаточно вменяемы.

pm.max_requests = 600

Это значение не имеет смысла в ondemand PM, но я с ним поговорю. Какой смысл убивать воркер после 600 запросов? Если ваше приложение теряет столько памяти, сколько вам нужно, чтобы ее использовать, вам необходимо оценить само приложение.

На nginx

worker_process = 4

Рабочие процессы должны быть установлены на auto позволять nginx найти правильный баланс. Однако, как правило, одного достаточно для большинства случаев использования.

worker_connections  3072;

Это еще одна потенциально опасная настройка. Вы консультировались ulimit -n чтобы узнать, сколько открытых файлов разрешено для каждого процесса? Сколько ядер доступно в вашей системе (grep -c processor /proc/cpuinfo)? Вообще говоря, это значение должно быть $CPU_CORES * ulimit, что в вашем случае, вероятно, 2048, учитывая ваш выбор экземпляра EC2.

client_header_timeout 3000;
client_body_timeout 3000;
fastcgi_read_timeout 3000;

Это еще одна обстановка, в которой вы потенциально можете сгореть! Вы действительно хотите, чтобы соединения потенциально зависали почти на час, пока они ждут истечения времени ожидания? Чрезмерные значения тайм-аута в приложениях могут привести к большой утечке ресурсов на серверах. Значения тайм-аута были разработаны так, чтобы быть выше обычного времени, которое требуется для возникновения определенного события, и не более того. Иначе какой смысл в тайм-ауте? :)