Why is Apache spawning so many processes?

Question

I have a Wordpress blog with one post. I wanted to self-host for the experience and "fun" of it. I rarely get any viewers at all because I am just setting up. I am on an Amazon EC2-micro Arch-Linux instance using Apache 2.4.23 and MySQL 5.5.52 to run Wordpress. I have 1 GB of RAM.

I did not think that this would be a resource heavy application, but every time I try to run Wordpress, after a couple days the server always crashes. This is due to Apache spawning 100s of processes and not killing them. Shouldn't these go away after a while?

I have spent quite a bit of time now googling the problem. I have set up 2 GB of swap trying to fix it. The processes overflow that too. I have added maxClients 40 to my httpd.conf and that seemed to work for a while, but after about 2 weeks Apache crashed again. I have tried other configurations in httpd.conf but they would cause Apache to crash even quicker. I have a block that currently looks like this (after several tries):

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

Could anyone experienced with this specific problem give me some advice? I'm just trying to host a simple WordPress blog. If it helps, here is my 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"

Edit: Also the fact that these processes are in uninterruptible sleep (IO, Status = D) is problematic!

Answer 1

Shamely, most hosting solutions out there people use, decide to parse php content through Apache with mod_php.

Your PHP installation by default will surely not be thread-safe, this effectively forces Apache to use a non-threading mpm (multi-process module).

Your Apache installation uses prefork (as you can see in the apachectl -V output). This mpm spawns a process per request. So if you are under a bit of load and nowadays knowing how many concurrent requests some browsers send, that list of process is quite usual.

All this make apache crawl and suffer from the load your php scripts cause, making Apache look as it is not performing well, when it is all due to php parsing and unperformant php scripts.

Now, what should you do to avoid this?

Relief Apache from the burden of mod_php, move your php parsing to php-fpm, that will allow you to use Apache HTTPD's "event" mpm, that would even allow you to have 1 process with a thousand threads if you want, and not only that, it is quite more responsive to load spikes and will be as cool and fast as any other http server out there. And most importantly, Apache processes won't be stuck in the hundreds.

You can find some tips on how to configure Apache for this at: Apache Official Wiki PHP entry and mod_proxy_fcgi

Answer 2

It's clear that even 40 is too many Apache processes. You have only 1GB RAM and 2GB swap, and you're using all the RAM and more than half of the swap. The reason your processes are in D status is because your virtual machine is thrashing in and out of swap. It's unlikely to recover on its own; you may as well reboot it.

Decrease the MaxClients number significantly. For a low traffic site on a micro instance, I can't imagine any way you would need it to be higher than 10 (nor for the instance to be able to handle much more). In fact, the settings you have commented out look like a very good starting point, and you should probably restore them.

Once you've recovered, you can start looking at what else on the system might be eating up lots of RAM.

Answer 3

For me the problem was that php memory limit was set to -1 (no limit), after setting it to 128M by editing php.ini, the memory usage dropped