Сайт становится недоступным из-за очереди прослушивания PHP-FPM, процессор затрагивает 100%

Я изо всех сил пытаюсь решить эту проблему, которая возникает случайным образом каждые несколько часов на моем рабочем сервере, где размещается один блог Wordpress (с приличным трафиком: 2000 пользователей в реальном времени в среднем за день, 5000+ в хорошие дни, просмотры страниц в минуту варьируются от 300 до 700 +).

Я использую Newrelic для контроля производительности, и я заметил необычную вещь:

Каждые несколько часов (случайным образом) статус пула PHP-FPM выглядит примерно так (реальное состояние, принятое вчера)

pool:                 www
process manager:      static
start time:           02/Jan/2017:05:03:16 -0500
start since:          27290
accepted conn:        1107594
listen queue:         777
max listen queue:     794
listen queue len:     40000
idle processes:       0
active processes:     100
total processes:      100
max active processes: 101
max children reached: 0
slow requests:        0

Перезапуск PHP-FPM и nginx решает проблему, но это происходит снова через пару часов. Любая помощь приветствуется. Пожалуйста, направляйте меня.


Настройка сервера:

DigitalOcean 48GB Memory
16 Core Processor
480GB SSD Disk

Настройка пула PHP-FPM:

pm = static
pm.max_children = 100
pm.max_requests = 5000

nginx config:

worker_processes  32;
worker_rlimit_nofile 100000;
events {
    worker_connections  40000;
    use epoll;
    multi_accept on;
}

Я также использую xcache, varnish с W3TC в Wordpress. (также есть Cloudflare)

sysctl.conf:

# Increase size of file handles and inode cache
fs.file-max = 2097152

# Do less swapping
vm.swappiness = 10
vm.dirty_ratio = 60
vm.dirty_background_ratio = 2

### GENERAL NETWORK SECURITY OPTIONS ###

# Number of times SYNACKs for passive TCP connection.
net.ipv4.tcp_synack_retries = 2

# Allowed local port range
net.ipv4.ip_local_port_range = 2000 65535

# Protect Against TCP Time-Wait
net.ipv4.tcp_rfc1337 = 1

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15

# Decrease the time default value for connections to keep alive
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15

### TUNING NETWORK PERFORMANCE ###

# Default Socket Receive Buffer
net.core.rmem_default = 31457280

# Maximum Socket Receive Buffer
net.core.rmem_max = 12582912

# Default Socket Send Buffer
net.core.wmem_default = 31457280

# Maximum Socket Send Buffer
net.core.wmem_max = 12582912

# Increase number of incoming connections
net.core.somaxconn = 40000

# Increase number of incoming connections backlog
net.core.netdev_max_backlog = 65536

# Increase the maximum amount of option memory buffers
net.core.optmem_max = 25165824

# Increase the maximum total buffer-space allocatable
# This is measured in units of pages (4096 bytes)
net.ipv4.tcp_mem = 65536 131072 262144
net.ipv4.udp_mem = 65536 131072 262144

# Increase the read-buffer space allocatable
net.ipv4.tcp_rmem= 10240 87380 12582912
net.ipv4.udp_rmem_min = 16384

# Increase the write-buffer-space allocatable
net.ipv4.tcp_wmem= 10240 87380 12582912
net.ipv4.udp_wmem_min = 16384

# Increase the tcp-time-wait buckets pool size to prevent simple DOS attacks
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

Ответ 1

Попробуйте остановить ваш агент NewRelic и подождите несколько часов, чтобы узнать, устраняет ли это проблему. Если это так, попробуйте обновить его до последней версии. Если он возвращается после его обновления, обратитесь в службу поддержки NewRelic.

Отметьте max_execution_time и request_terminate_timeout в php.ini.

Проверьте значения proxy_connect_timeout, proxy_send_timeout, proxy_read_timeout и send_timeout в конфигурации Nginx.

Я бы рекомендовал проверить ваши настройки TCP/IP, чтобы увидеть, что они поддерживают, и настройки тайм-аута, возможно, потребуется уменьшить. Я видел, что некоторые дистрибутивы приходят с минутой или более по умолчанию.

Вы также должны убедиться, что трафик от слушателя является действительным трафиком. Посмотрите, можете ли вы выставить образцы в файл и подтвердить, что трафик является законным. Многие автоматизированные процессы ищут экземпляры Wordpress на interwebz. Эти боты могут вызывать всевозможные проблемы, так как они могут взломать ваш сайт.

Ответ 2

Вы проверяете свой access.log или domain.com.access.log в /var/log/nginx/? Глядя на это, у вас будет больше информации о том, почему PHP-FPM потребляет ваш процессор.

Я думаю, что ваш сайт находится на грубой основе для wp-login.php, которые потребляют много CPU.