Help please - Apache httpd kills my server after Plesk and PHP update

[mavera2]

In my CentOS 6.3 final server
I was using Plesk 11.5.30 Update #20
Last night at 03:00 it was updated to Update #28.
It updated my PHP version from 5.4.17 to 5.4.23.
And also other updates:
http://download1.parallels.com/Ples...1.5-linux-updates-release-notes.html#11530u28

After the Plesk update httpd (apache) started to kill my server.
In normal operation I was having 25-30 httpd process and it was using total 90-120 MB RAM.

You can check from image that httpd (apache) creates 120-150 processes and takes 400-600 MB RAM.
http://s14.postimg.org/rdqm1kryp/image.jpg

You can see that php-cgi's CPU usage increased from %20-23 to %65-75:
http://s27.postimg.org/jmbkrshyr/image.jpg

I use mod_fcgid and you can see my ```top``` results below:

top - 13:21:06 up 50 min, 1 user, load average: 6.44, 7.23, 7.51
Tasks: 314 total, 5 running, 309 sleeping, 0 stopped, 0 zombie
Cpu(s): 28.1%us, 58.1%sy, 0.0%ni, 2.2%id, 9.4%wa, 0.3%hi, 1.9%si, 0.0%st
Mem: 1020564k total, 949536k used, 71028k free, 45024k buffers
Swap: 2097144k total, 188832k used, 1908312k free, 98512k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND
2526 mysql 20 0 1909m 282m 2952 S 45.4 28.3 8:05.60 64m mysqld
3930 mywebsite 20 0 243m 35m 13m S 1.3 3.6 0:48.20 6076 php-cgi
4167 mywebsite 20 0 235m 29m 13m R 33.5 3.0 0:33.68 3984 php-cgi
4169 mywebsite 20 0 234m 29m 13m S 1.3 3.0 0:25.45 4104 php-cgi
4165 mywebsite 20 0 235m 29m 13m R 28.2 2.9 0:40.39 4372 php-cgi
4257 mywebsite 20 0 229m 28m 13m S 1.3 2.8 0:03.88 0 php-cgi
4208 mywebsite 20 0 232m 28m 13m S 5.6 2.8 0:19.10 2912 php-cgi
4258 mywebsite 20 0 229m 27m 13m R 26.8 2.8 0:20.09 0 php-cgi
4259 mywebsite 20 0 229m 27m 13m R 27.2 2.8 0:19.89 0 php-cgi
2709 root 20 0 835m 4232 804 S 0.0 0.4 0:23.40 3852 newrelic-daemon
4254 apache 20 0 335m 4000 1892 S 0.0 0.4 0:00.01 9m httpd
4291 apache 20 0 335m 3984 2008 S 0.0 0.4 0:00.00 9m httpd
4225 apache 20 0 336m 3960 1776 S 0.0 0.4 0:00.15 9m httpd
4044 apache 20 0 336m 3932 1776 S 0.0 0.4 0:00.14 10m httpd
4249 apache 20 0 335m 3924 1884 S 0.0 0.4 0:00.01 9m httpd
4255 apache 20 0 335m 3924 1884 S 0.0 0.4 0:00.01 9m httpd
4267 apache 20 0 335m 3916 1884 S 0.0 0.4 0:00.04 9m httpd
4265 apache 20 0 335m 3904 1880 S 0.0 0.4 0:00.00 9m httpd
4248 apache 20 0 335m 3888 1868 S 0.0 0.4 0:00.01 9m httpd
4285 apache 20 0 335m 3888 1876 S 0.0 0.4 0:00.00 9m httpd
4080 apache 20 0 336m 3880 1772 S 0.0 0.4 0:00.04 10m httpd
4244 apache 20 0 335m 3880 1876 S 0.0 0.4 0:00.01 9m httpd
4173 apache 20 0 335m 3868 1776 S 0.0 0.4 0:00.23 10m httpd
4278 apache 20 0 335m 3860 1868 S 0.0 0.4 0:00.00 9m httpd
4114 apache 20 0 335m 3856 1768 S 0.0 0.4 0:00.06 10m httpd
3983 apache 20 0 335m 3852 1776 S 0.3 0.4 0:00.34 10m httpd
3980 apache 20 0 335m 3848 1776 S 0.0 0.4 0:00.12 10m httpd
4292 apache 20 0 335m 3848 2036 S 0.0 0.4 0:00.00 9m httpd
4241 apache 20 0 335m 3844 1872 S 0.0 0.4 0:00.05 9m httpd
4237 apache 20 0 335m 3840 1772 S 0.0 0.4 0:00.04 9m httpd
4280 apache 20 0 335m 3840 1824 S 0.0 0.4 0:00.00 9m httpd
4281 apache 20 0 335m 3836 1824 S 0.0 0.4 0:00.00 9m httpd
4282 apache 20 0 335m 3832 1828 S 0.0 0.4 0:00.00 9m httpd
4051 apache 20 0 335m 3828 1772 S 0.0 0.4 0:00.12 10m httpd
4246 apache 20 0 335m 3828 1876 S 0.0 0.4 0:00.03 9m httpd
3989 apache 20 0 335m 3824 1784 S 0.0 0.4 0:00.52 10m httpd
4228 apache 20 0 335m 3820 1768 S 0.0 0.4 0:00.02 9m httpd
4163 apache 20 0 335m 3816 1772 S 0.3 0.4 0:00.25 10m httpd
4229 apache 20 0 335m 3816 1772 S 0.0 0.4 0:00.07 9.9m httpd
4236 apache 20 0 335m 3816 1780 S 0.0 0.4 0:00.06 9m httpd
4086 apache 20 0 335m 3812 1772 S 0.0 0.4 0:00.11 10m httpd
4123 apache 20 0 335m 3808 1772 S 0.0 0.4 0:00.14 10m httpd
4266 apache 20 0 335m 3808 1856 S 0.0 0.4 0:00.00 9m httpd

fcgid configuration:

# vi /etc/httpd/conf.d/fcgid.conf

result:

<IfModule mod_fcgid.c>

<IfModule !mod_fastcgi.c>
AddHandler fcgid-script fcg fcgi fpl
</IfModule>

FcgidIPCDir /var/run/mod_fcgid/sock
FcgidProcessTableFile /var/run/mod_fcgid/fcgid_shm

FcgidIdleTimeout 60
FcgidProcessLifeTime 30
FcgidMaxProcesses 20
FcgidMaxProcessesPerClass 8
FcgidMinProcessesPerClass 0
FcgidConnectTimeout 30
FcgidIOTimeout 60
FcgidInitialEnv RAILS_ENV production
FcgidIdleScanInterval 10

</IfModule>

Inside my error.log I get these errors that say that server can't respond too much users. Which doesn't appeared before the update:

mod_fcgid: can't apply process slot for /var/www/cgi-bin/cgi_wrapper/cgi_wrapper

Any help will greatly be appreciated.

 

[Faris Raouf]

The update and the problem may or may not be related.

If you had not updated Plesk but had experienced the same problem, I would say that the issue is being caused by a site or sites being either attacked deliberately OR just extremely popular OR a bad search engine was trying to index a site or site in an aggressive way.

The first thing I'd do would be to limit MaxClients in /etc/httpd/config/httpd.conf. e.g.

<IfModule prefork.c>
StartServers       2
MinSpareServers    3
MaxSpareServers    4
ServerLimit       54
MaxClients        50
MaxRequestsPerChild  1000
</IfModule>

Indeed, unless you have HUGE amounts of memory, allowing too many apache connections at once can cause your server to run out of memory, especially if you have lots of modules loaded.

Please note that I'm not saying this is definitely the problem or the solution. I'm just offering a possible option to investigate.
The default Apache setting which allows something like 150 or more apache processes is WAY to much for a system without ridiculous amounts of RAM in my opinion. Others may not agree of course.

 

[mavera2]

The update and the problem may or may not be related.

If you had not updated Plesk but had experienced the same problem, I would say that the issue is being caused by a site or sites being either attacked deliberately OR just extremely popular OR a bad search engine was trying to index a site or site in an aggressive way.

The first thing I'd do would be to limit MaxClients in /etc/httpd/config/httpd.conf. e.g.

<IfModule prefork.c>
StartServers       2
MinSpareServers    3
MaxSpareServers    4
ServerLimit       54
MaxClients        50
MaxRequestsPerChild  1000
</IfModule>

Indeed, unless you have HUGE amounts of memory, allowing too many apache connections at once can cause your server to run out of memory, especially if you have lots of modules loaded.

Please note that I'm not saying this is definitely the problem or the solution. I'm just offering a possible option to investigate.
The default Apache setting which allows something like 150 or more apache processes is WAY to much for a system without ridiculous amounts of RAM in my opinion. Others may not agree of course.

Faris thank you for help.
Only thing that changed is updating Plesk microupdate. I didn't change a line in my codes. So most probably Plesk update made this behaviour.

Maybe Plesk update deleted some of my configuration settings so new settings made my server killed.

I checked for "httpd.conf" file, it is like this:
<code>
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>

<IfModule worker.c>
StartServers 4
MaxClients 300
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
</code>

1) I use mod_fcgid. So does "ServerLimit" and "MaxClients" affect anything.
As far as I know these settings doesn't change anything when I use mod_fcgid, do I know false ?

2) How can I limit number of httpd (apache) processes when I use mod_fcgid ? with MaxClients or ?

Thank you in advance for your help and interest
Best regards

 

[mavera2]

Also I noted that each "httpd apache" process has 9 MB swap.
Although process runs for only 1 second or 2-3 seconds it swaps 9 mb.

<code>4254 apache 20 0 335m 4000 1892 S 0.0 0.4 0:00.01 9m httpd
4291 apache 20 0 335m 3984 2008 S 0.0 0.4 0:00.00 9m httpd
4225 apache 20 0 336m 3960 1776 S 0.0 0.4 0:00.15 9m httpd
4044 apache 20 0 336m 3932 1776 S 0.0 0.4 0:00.14 10m httpd
4249 apache 20 0 335m 3924 1884 S 0.0 0.4 0:00.01 9m httpd
4255 apache 20 0 335m 3924 1884 S 0.0 0.4 0:00.01 9m httpd
4267 apache 20 0 335m 3916 1884 S 0.0 0.4 0:00.04 9m httpd
4265 apache 20 0 335m 3904 1880 S 0.0 0.4 0:00.00 9m httpd
4248 apache 20 0 335m 3888 1868 S 0.0 0.4 0:00.01 9m httpd
4285 apache 20 0 335m 3888 1876 S 0.0 0.4 0:00.00 9m httpd
4080 apache 20 0 336m 3880 1772 S 0.0 0.4 0:00.04 10m httpd
4244 apache 20 0 335m 3880 1876 S 0.0 0.4 0:00.01 9m httpd
4173 apache 20 0 335m 3868 1776 S 0.0 0.4 0:00.23 10m httpd/code>

 

[mavera2]

Also an interesting thing. I checked
# vi /var/log/httpd/suexec_log
file and I found many records like this:

<code>[2014-01-13 00:04:19]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:04:20]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:04]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:05]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:06]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:07]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:08]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:09]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:31]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:51]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:51]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:05:52]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:06:18]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:06:38]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:07:42]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:09:45]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:09:54]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:09:54]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:09:58]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:09:58]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:09:59]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:10:54]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:10:54]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:10:54]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:13:12]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:13:12]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:13:23]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:13:23]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:19:03]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:19:19]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:20:43]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:20:55]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:20:55]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:21:03]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:21:19]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:21:39]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:23:14]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:24:14]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
[2014-01-13 00:24:22]: uid: (10002/mywebsite) gid: (505/505) cmd: cgi_wrapper
</code>

 

[Faris Raouf]

I am VERY sketchy on how these things work. Very sketchy!! But......rightly or wrongly, I always thought that as Apache must still deal with the incoming requests in order to pass them, or whatever the term is, to the running cgi processes, the maxclients and other setting would still apply. If that's the case, 256 is a huge number.

But maybe I'm totally wrong about this. I really don't know much about it.

Ignoring all that, your apache processes do seem to be using huge amounts of memory all of a sudden, and that's the biggest problem, isn't it? I don't know how to debug this. Does mod_status give you any clues? And have you tried apachetop (though all that does is look at logfiles really, so I don't know how useful it might be since there are multiple logfiles on a Plesk system)?

 

[mavera2]

I am VERY sketchy on how these things work. Very sketchy!! But......rightly or wrongly, I always thought that as Apache must still deal with the incoming requests in order to pass them, or whatever the term is, to the running cgi processes, the maxclients and other setting would still apply. If tha
t's the case, 256 is a huge number.

But maybe I'm totally wrong about this. I really don't know much about it.

Ignoring all that, your apache processes do seem to be using huge amounts of memory all of a sudden, and that's the biggest problem, isn't it? I don't know how to debug this. Does mod_status give you any clues? And have you tried apachetop (though all that does is look at logfiles really, so I don't know how useful it might be since there are multiple logfiles on a Plesk system)?

I lowered "MaxClients" value to "50".
But even that case each "http" process swaps 9-10 mb each.
So 50*10=500 mb swapping.

The problem is very high Disk input output.
I think the cause for IO is swapping.
Because disk swaps, server tries to write RAM to disk and read RAM from disk.
So huge IO wait times occur.

 

[BrewsterL]

I'm having a very similar problem with Apache after the update to 11.5.30 Update #28 (on CentOS 5.4). I see a couple of other forum threads with the same problem so this must be a bug in update #28 ( I jumped a couple minor versions as I try and wait for new releases to be stable before updating).

In my case httpd is growing in memory usage for reasons I can't figure out, at a rate of around 200 MByte/hour (but maybe tied to httpd activity). Eventually the server runs out of swap and starts killing things off (with oom_killer) , but at that point a reboot is needed because as fast as oom_killer kills off things httd grabs it back.

I don't find any dead http processes though ...instead each http process grows over time (notice swap space freeing up and the http process memory going way down on a http restart):

# free
total used free shared buffers cached
Mem: 993188 984908 8280 0 748 123872
-/+ buffers/cache: 860288 132900
Swap: 3919840 1446648 2473192
# /etc/init.d/httpd restart
Stopping httpd: [ OK ]
Starting httpd: [Sun Jan 12 20:21:58 2014] [ OK ]
# free
total used free shared buffers cached
Mem: 993188 257580 735608 0 744 134276
-/+ buffers/cache: 122560 870628
Swap: 3919840 241524 3678316

#-------------------------(some time later repeat the restart)
# ps axfu | grep apache
root 20017 0.0 0.6 319844 6784 ? Ss 15:15 0:00 /usr/sbin/httpd
apache 20025 0.0 0.1 226212 1928 ? S 15:15 0:00 \_ /usr/sbin/httpd
apache 20026 0.3 0.9 411528 9488 ? S 15:15 1:21 \_ /usr/sbin/httpd
apache 20027 0.3 5.7 460344 57524 ? S 15:15 1:20 \_ /usr/sbin/httpd
apache 20028 0.3 4.3 411532 42876 ? S 15:15 1:19 \_ /usr/sbin/httpd
apache 20029 0.5 7.5 452640 74768 ? S 15:15 1:52 \_ /usr/sbin/httpd
apache 20030 0.3 7.0 451008 69648 ? S 15:15 1:20 \_ /usr/sbin/httpd
apache 20031 0.4 4.0 411268 40644 ? S 15:15 1:42 \_ /usr/sbin/httpd
apache 20032 0.3 4.1 411356 41300 ? S 15:15 1:09 \_ /usr/sbin/httpd
apache 20033 0.2 7.6 453128 76420 ? S 15:15 0:51 \_ /usr/sbin/httpd
apache 20147 0.3 7.6 452616 75816 ? S 15:39 1:15 \_ /usr/sbin/httpd
apache 20148 0.3 2.4 456852 24516 ? S 15:39 1:12 \_ /usr/sbin/httpd
apache 20149 0.3 3.7 451696 36972 ? S 15:39 1:12 \_ /usr/sbin/httpd
apache 21047 0.3 5.7 455656 56820 ? S 17:15 0:45 \_ /usr/sbin/httpd
apache 21049 0.3 9.4 488840 94284 ? S 17:16 0:52 \_ /usr/sbin/httpd
apache 21053 0.5 4.1 411340 41336 ? S 17:16 1:11 \_ /usr/sbin/httpd
apache 21177 0.3 6.1 489484 60796 ? S 17:22 0:51 \_ /usr/sbin/httpd

# ./httpd restart
Stopping httpd: [ OK ]
Starting httpd: [Mon Jan 13 21:13:10 2014] [ OK ]
# ps axfu | grep apache

apache 25109 0.0 0.7 226212 7688 ? S 21:13 0:00 \_ /usr/sbin/httpd
apache 25110 0.0 1.3 320472 13128 ? S 21:13 0:00 \_ /usr/sbin/httpd
apache 25111 0.0 1.3 320472 13076 ? S 21:13 0:00 \_ /usr/sbin/httpd
apache 25112 0.0 1.3 320472 13128 ? S 21:13 0:00 \_ /usr/sbin/httpd
apache 25113 0.0 1.2 320472 12476 ? S 21:13 0:00 \_ /usr/sbin/httpd
apache 25114 0.0 1.2 320472 12472 ? S 21:13 0:00 \_ /usr/sbin/httpd
apache 25115 0.0 1.2 320472 12472 ? S 21:13 0:00 \_ /usr/sbin/httpd
apache 25116 0.0 1.2 320472 12472 ? S 21:13 0:00 \_ /usr/sbin/httpd
apache 25117 0.0 1.2 320472 12472 ? S 21:13 0:00 \_ /usr/sbin/httpd


The only thing I came up with for now is to restart http every 6 hours or so - that's keeping the server up but I'm hoping Parallels can come up with an answer as to why this update broke apache. I have not noticed any other problems.

 

[BrewsterL]

while writing the previous post http went wild...in case it helps, here's what pops up on the console:

httpd invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0

Call Trace:
[<ffffffff800c65e9>] out_of_memory+0x8e/0x2f3
[<ffffffff8000f487>] __alloc_pages+0x245/0x2ce
[<ffffffff80012dc7>] __do_page_cache_readahead+0x96/0x179
[<ffffffff800137
psa-pc-remote invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0

Call Trace:
[<ffffffff800c65e9>] out_of_memory+0x8e/0x2f3
[<ffffffff8000f487>] __alloc_pages+0x245/0x2ce
[<ffffffff80012dc7>] __do_page_cache_readahead+0x96/0x179
[<ffffffff80013729>] filemap_nopage+0x14c/0x360
[<ffffffff8000898c>] __handle_mm_fault+0x1fa/0xf99
[<ffffffff80066b55>] do_page_fault+0x4cb/0x830
[<ffffffff80062ff8>] thread_return+0x62/0xfe
[<ffffffff8005dde9>] error_exit+0x0/0x84

Node 0 DMA per-cpu:
cpu 0 hot: high 0, batch 1 used:0
cpu 0 cold: high 0, batch 1 used:0
cpu 1 hot: high 0, batch 1 used:0
cpu 1 cold: high 0, batch 1 used:0
Node 0 DMA32 per-cpu:
cpu 0 hot: high 186, batch 31 used:33
cpu 0 cold: high 62, batch 15 used:48
cpu 1 hot: high 186, batch 31 used:90
cpu 1 cold: high 62, batch 15 used:37
Node 0 Normal per-cpu: empty
Node 0 HighMem per-cpu: empty
Free pages: 5888kB (0kB HighMem)
Active:131135 inactive:81545 dirty:0 writeback:0 unstable:0 free:1472 slab:7066 mapped-file:142 mapped-anon:213553 pagetables:20491
Node 0 DMA free:2008kB min:40kB low:48kB high:60kB active:0kB inactive:0kB present:10552kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 961 961 961
Node 0 DMA32 free:3880kB min:3944kB low:4928kB high:5916kB active:524796kB inactive:325796kB present:984816kB pages_scanned:3207585 all_unreclaimable? yes
lowmem_reserve[]: 0 0 0 0
Node 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 4*4kB 3*8kB 3*16kB 2*32kB 3*64kB 1*128kB 2*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 2008kB
Node 0 DMA32: 16*4kB 1*8kB 22*16kB 0*32kB 2*64kB 2*128kB 0*256kB 2*512kB 0*1024kB 1*2048kB 0*4096kB = 3880kB
Node 0 Normal: empty
Node 0 HighMem: empty
202 pagecache pages
Swap cache: add 53040389, delete 53040372, find 28112290/33281733, race 771+3411
Free swap = 0kB
Total swap = 3919840kB
Out of memory: Killed process 30196 (httpd).

 

[PriyanA]

I'm having a similar issue...

Please read my post. Any advice?

http://forum.parallels.com/showthread.php?296595-High-Apache-memory-usage-PP-11-5

OS CentOS 6.4 (Final)
Panel version 11.5.30 Update #28, last updated at Dec 28, 2013 06:27 AM



I remember Updating MySQL via Parallels Installer>Update Components(While ago)



One Website has this in error log, Also this is a very low traffic website.

"mod_fcgid: can't apply process slot for /var/www/cgi-bin/cgi_wrapper/cgi_wrapper"

This websites have been on this server for while now. i remember having 3.5% - 5% Apache Memory Usage before.

 

[BrewsterL]

@PriyanA

This one is beyond my abilities/time available - maybe it's wishful thinking that since this affects what probably is a lot of users/their bug that Parallels will come up with an answer...

my workaround hack was to add the following via crontab -e for root
15 3,9,12,15,18,21 * * * /etc/init.d/httpd restart

(initially I did this every 6 hours but that was not frequent enough on my server. Monitor your memory usage to get an idea how long you can go between restarts).

I also tried this but I don't know if it's helping as I haven't seen it kick in yet:
http://blog.dynamichosting.biz/2011/08/25/limiting-apache-httpd-memory-usage-per-process/

 

[PriyanA]

@BrewsterL

Thank you for your suggetion.

Please let me know if you find how to fix this problem.

 

[dicko_md]

I too have this issue. CPU at about 60% constantly.

I rebooted the server at about 2am this morning after doing a fsck to make sure everything was OK and it went below 10% like my other server is (this server was configured at same time as the one I am having issues with). At about 4am (according to the health monitor) it shot up to about 60% again and its been there all day.

I have not changed anything and this has been going on for over a week now and I think you are right, it will be the php upgrade.

Is there anyway of going back to the old version ?

http://forum.parallels.com/showthread.php?299095-CPU-High-wait&highlight=high+wait+io

Thanks

Martyn

 

[PriyanA]

Hi Dicko,

you can have multiple PHP versions on PP11.5

http://download1.parallels.com/Ples...inistrator-guide/index.htm?fileName=72042.htm

 

[ChananZ]

Hi,

Anyone succeeded in solving this issue? I'm having the exact same problem with Plesk 11.5. High CPU usage and MySQL CPU usage.
Any help would be most appreciated.