Apache being used by php-fpm while running Nginx?

Question

I wonder if anyone could help me with why this RAM is being used. I run a low end box, 512mb RAM with Centos 6.3, Nginx, PHP and MySQL but Apache is showing up when I run a ps aux and it is using a lot of RAM.

apache    1166  0.0  3.7  78620 19500 ?        S    Apr19   0:01 php-fpm: pool w
apache    1167  0.0  3.7  79076 19844 ?        S    Apr19   0:01 php-fpm: pool w
apache    1168  0.0  3.5  78312 18732 ?        S    Apr19   0:01 php-fpm: pool w
apache    1169  0.0  2.6  61744 13656 ?        S    Apr19   0:01 php-fpm: pool w
apache    1170  0.0  4.8  84744 25440 ?        S    Apr19   0:01 php-fpm: pool w
apache    1383  0.0  3.3  77112 17660 ?        S    Apr19   0:01 php-fpm: pool w

The 4th column is the percentage RAM column, which means Apache is using 21.6% of my server's RAM. Why is Apache using all this when I am running Nginx?

I have checked if Appache is running with this:

/etc/init.d/httpd status
httpd is stopped

So Apache isn't running but it is? I'm confused.

I am new to Linux and have managed to set up this VPS to host websites from scratch and without a control panel, but I can't figure out why this RAM is being used. Shouldn't php-fpm be running though Nginx?

If anyone could help that would be great. Google hasn't thrown up much.

Answer 1

This doesn't show that Apache is running.

It shows that php-fpm is running under the apache user account.

That is, of course, what the headings for the columns say:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

When you view your processes with the headings, it then becomes obvious:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
apache    1166  0.0  3.7  78620 19500 ?        S    Apr19   0:01 php-fpm: pool w

Of course, with such a long display as ps aux might generate, the headings may scroll off your terminal. As you use the commands more, you'll eventually learn which columns are which without having to refer to the headings.

Answer 2

Unfortunately, figuring out the actual memory usage of multiple closely related processes is not simple. The RSS column in the output of ps shows the Resident Set Size of each process, which is the amount of physical memory used by the process, but some amount of that memory is actually shared with other processes, therefore just summing RSS values of several processes does not give a correct result (shared memory is counted multiple times). The %MEM column has the same problem, because it is RSS divided by the amount of physical memory on the machine.

More useful metrics for process memory usage in this case would be:

• USS (Unique Set Size) — the number of pages a process has mapped which are mapped only by that process, and are not mapped by any other process.
• PSS (Proportional Set Size) — USS plus a fraction of each shared page proportional to the number of processes which have mapped the page (e.g., if a page is shared by 3 processes, each of these processes is reported to be using 1/3 of such page).

USS and PSS of several processes can be meaningfully summed, unlike RSS. Unfortunately, ps even from recent versions of procps-ng cannot show these values. There is a tool called smem which can show USS, PSS and RSS of processes (and calculate total USS, total PSS, and a meaningless ”total RSS”); or you can grab Pss: values from /proc/*/smaps and sum them using custom scripts.

Note that you need root privileges to read /proc/*/smaps data for any processes except your own.