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!

^^^ Another misguiding and iliterate comment. The question is. Why Apache with mod_php forcing Apache to use prefork? The answer is, he clicked a button somewhere and he got that, but that does not mean Apache does not perform well, that just means the whole set up is not meant to be performant, just easy to install. — Daniel Ferradal, Dec 29 '16 at 10:06

Daniel Ferradal · Answer 1 · 2016-12-29T10:21:45.333

8

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

edited Dec 29 '16 at 10:21

answered Dec 29 '16 at 10:01

Daniel Ferradal

2,560

This only shifts the memory usage to php-fpm and doesn't necessarily solve the underlying problems. While it's a good idea to use php-fpm anyway (and probably to get rid of Apache) you shouldn't expect this to be the end of it. – Michael Hampton Dec 29 '16 at 19:44
1

If you read his question "Why is Apache spawning so many processes?" The op believes Apache is the source of the problem. Apache can/should proxy to php-fpm, no need to get rid of it. But the point of my whole answer is that most probably he is looking at the wrong place, and he should start debugging the backend application instead. Moving php to its own daemon will help him determine where the problem lies, as he doesn't seem to realize and will can make Apache for static content not get affected by the problems generated by the php scripts. – Daniel Ferradal Dec 30 '16 at 08:53
will using php-fam use less of my limited memory? That's the biggest issue. – Mike Flynn Dec 30 '16 at 13:37
1

@MikeFlynn no, it will help you notice clearly where your problem lies. What you should do is review the scripts, review the error log from php scripts you are running and see why they are getting stuck like that. But php-fpm versatility will limit the number of workers it can spawn, as well as kill idle workers after x time, all this without affecting Apache server. This is also why it is ideal to separate php for php-fpm and static content for Apache among the other things previously mentioned. – Daniel Ferradal Jan 01 '17 at 09:00

score 5 · Answer 2 · answered Dec 29 '16 at 04:17

5

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.

answered Dec 29 '16 at 04:17

Michael Hampton

247,473

1

I correct my previous comment. Please see, he is using prefork and mod_php, so big chances are it's all due to php scripts misbehaving, causing all this. The problem is not in httpd. – Daniel Ferradal Dec 29 '16 at 10:26
because the IO in your server doesn't works. – c4f4t0r Dec 29 '16 at 10:28
1

FWIW this fixed the problem immediately in my particular situation – eouw0o83hf Mar 03 '19 at 03:24

score 0 · Answer 3 · answered May 18 '23 at 18:54

0

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

answered May 18 '23 at 18:54

Asaf M

101

Why is Apache spawning so many processes?

3 Answers3