Назад | Перейти на главную страницу

Почему Apache порождает так много процессов?

У меня есть блог на Wordpress с одним постом. Я хотел самостоятельно провести время и получить от этого «удовольствие». Я редко получаю зрителей, потому что я только настраиваюсь. Я нахожусь в экземпляре Amazon EC2-micro Arch-Linux, использую Apache 2.4.23 и MySQL 5.5.52 для запуска Wordpress. У меня 1 ГБ оперативной памяти.

Я не думал, что это будет ресурсоемкое приложение, но каждый раз, когда я пытаюсь запустить Wordpress, через пару дней сервер всегда вылетает. Это связано с тем, что Apache порождает сотни процессов, а не убивает их. Разве они не должны исчезнуть через некоторое время?

Я потратил довольно много времени на поиск в Google. Я установил 2 ГБ подкачки, пытаясь это исправить. Это тоже переполняет процессы. я добавил maxClients 40 к моему httpd.conf и это, казалось, работало какое-то время, но примерно через 2 недели Apache снова вылетел. Я пробовал другие конфигурации в httpd.conf но они могли вызвать сбой Apache еще быстрее. У меня есть блок, который сейчас выглядит так (после нескольких попыток):

# StartServers 3
# MinSpareServers 2
# MaxSpareServers 5
# ServerLimit 10
 maxClients 40
# MaxRequestsPerChild 100
# KeepAliveTimeout 2

Может ли кто-нибудь, столкнувшийся с этой конкретной проблемой, дать мне совет? Я просто пытаюсь вести простой блог WordPress. Если поможет, вот мой httpd -V

[ec2-user~]$ httpd -V
Server version: Apache/2.4.23 (Amazon)
Server built:   Jul 29 2016 21:42:17
Server's Module Magic Number: 20120211:61
Server loaded:  APR 1.5.1, APR-UTIL 1.4.1
Compiled using: APR 1.5.1, APR-UTIL 1.4.1
Architecture:   64-bit
Server MPM:     prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/var/run/httpd/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Изменить: также проблематично то, что эти процессы находятся в непрерывном сне (IO, Status = D)!

apache-2.4

К сожалению, большинство хостинговых решений, которыми пользуются люди, решают анализировать php-контент через Apache с помощью mod_php.

Ваша установка PHP по умолчанию, безусловно, не будет потокобезопасной, это фактически вынуждает Apache использовать непоточный mpm (многопроцессорный модуль).

Ваша установка Apache использует prefork (как вы можете видеть в выводе apachectl -V). Этот mpm порождает процесс по запросу. Поэтому, если вы немного загружены и в настоящее время знаете, сколько одновременных запросов отправляют некоторые браузеры, этот список процессов вполне обычен.

Все это заставляет apache сканировать и страдать от нагрузки, вызываемой вашими скриптами php, из-за чего Apache выглядит неэффективным, когда все это связано с синтаксическим анализом php и неэффективными скриптами php.

Что делать, чтобы этого избежать?

Освободите Apache от бремени mod_php, переместите парсинг php на php-fpm, что позволит вам использовать mpm «event» Apache HTTPD, что даже позволит вам иметь 1 процесс с тысячей потоков, если хотите, и не только Это означает, что он лучше реагирует на скачки нагрузки и будет таким же крутым и быстрым, как и любой другой http-сервер. И самое главное, процессы Apache не застрянут в сотнях.

Вы можете найти несколько советов о том, как настроить Apache для этого по адресу: Запись PHP в официальной вики-странице Apache и mod_proxy_fcgi

Понятно, что даже 40 процессов Apache слишком много. У вас всего 1 ГБ ОЗУ и 2 ГБ подкачки, и вы используете всю ОЗУ и более половины подкачки. Причина, по которой ваши процессы находятся в статусе D, заключается в том, что ваша виртуальная машина постоянно переключается на свопинг. Самостоятельно вряд ли вылечится; вы также можете перезагрузить его.

Уменьшите MaxClients число значительно. Для сайта с низким трафиком на микроэкземпляре я не могу себе представить, как вам может понадобиться, чтобы он был выше 10 (ни для того, чтобы экземпляр мог обрабатывать гораздо больше). Фактически, закомментированные вами параметры выглядят как очень хорошая отправная точка, и вам, вероятно, следует их восстановить.

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