• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:
    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

High Apache memory usage PP 11.5

P

PriyanA

Regular Pleskian
Hi,

Recently i start receiving below email from "Health Monitoring".

I had the same websites(only 5) for 6 months on this server without this problem.

Other than PP Micro-updates(Currently Update #28), I remember updating MySQL(Currently 5.1.71-1.el6) via Parallels Installer.

Anyone please help me figure out what is going on?

----------------------------------email---------------------------------------------------------

Server health parameter "Services > Apache memory usage" changed its status from "green" to "yellow".

top - 22:20:26 up 3 days, 20:37, 0 users, load average: 0.07, 0.77, 0.90
Tasks: 118 total, 2 running, 115 sleeping, 0 stopped, 1 zombie
Cpu(s): 9.5%us, 4.1%sy, 0.1%ni, 86.1%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1016472k total, 721064k used, 295408k free, 122624k buffers
Swap: 1015800k total, 190708k used, 825092k free, 207004k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26298 webhi857 20 0 226m 44m 9252 R 82.8 4.4 0:03.84 php-cgi
1256 mysql 20 0 695m 50m 5236 S 17.3 5.1 137:40.49 mysqld
1 root 20 0 19228 1000 836 S 0.0 0.1 0:00.53 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 20 0 0 0 0 S 0.0 0.0 0:00.61 ksoftirqd/0
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
6 root RT 0 0 0 0 S 0.0 0.0 0:00.79 watchdog/0
7 root 20 0 0 0 0 S 0.0 0.0 0:24.08 events/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cgroup
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 netns
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 async/mgr
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pm
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 xenwatch
14 root 20 0 0 0 0 S 0.0 0.0 0:02.28 xenbus
15 root 20 0 0 0 0 S 0.0 0.0 0:01.89 sync_supers
16 root 20 0 0 0 0 S 0.0 0.0 0:01.98 bdi-default
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/0
18 root 20 0 0 0 0 S 0.0 0.0 0:14.74 kblockd/0
19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ata/0
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ata_aux
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksuspend_usbd
22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khubd
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kseriod
24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 md/0
25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 md_misc/0
26 root 20 0 0 0 0 S 0.0 0.0 0:00.12 khungtaskd
27 root 20 0 0 0 0 S 0.0 0.0 0:05.78 kswapd0
28 root 25 5 0 0 0 S 0.0 0.0 0:00.00 ksmd
29 root 20 0 0 0 0 S 0.0 0.0 0:00.00 aio/0
30 root 20 0 0 0 0 S 0.0 0.0 0:00.00 crypto/0
35 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthrotld/0
37 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khvcd
38 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kpsmoused
39 root 20 0 0 0 0 S 0.0 0.0 0:00.00 usbhid_resumer
69 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kstriped
202 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdmflush
204 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdmflush
221 root 20 0 0 0 0 S 0.0 0.0 0:35.95 jbd2/dm-0-8
222 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ext4-dio-unwrit
298 root 16 -4 11200 340 244 S 0.0 0.0 0:00.07 udevd
536 root 20 0 0 0 0 S 0.0 0.0 0:00.00 jbd2/xvda1-8
537 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ext4-dio-unwrit
585 root 20 0 0 0 0 S 0.0 0.0 0:00.04 kauditd
603 root 20 0 0 0 0 S 0.0 0.0 0:19.36 flush-253:0
822 root 16 -4 27636 660 540 S 0.0 0.1 0:00.54 auditd
847 root 20 0 243m 1264 824 S 0.0 0.1 0:00.48 rsyslogd
868 root 20 0 11564 1356 1004 S 0.0 0.1 0:08.95 xe-daemon
997 root 20 0 45316 452 204 S 0.0 0.0 0:00.00 sw-cp-serverd
999 sw-cp-se 20 0 46068 2252 1336 S 0.0 0.2 0:00.48 sw-cp-serverd
1010 root 20 0 66532 580 472 S 0.0 0.1 0:00.10 sshd
1018 root 20 0 22132 824 720 S 0.0 0.1 0:00.10 xinetd
1027 root 20 0 4064 452 392 S 0.0 0.0 0:00.00 courierlogger
1028 root 20 0 30248 960 932 S 0.0 0.1 0:00.06 authdaemond
1036 root 20 0 4064 296 292 S 0.0 0.0 0:00.00 courierlogger
1037 root 20 0 11900 744 740 S 0.0 0.1 0:00.01 couriertcpd
1042 root 20 0 32352 1656 1308 S 0.0 0.2 0:00.09 authdaemond
1043 root 20 0 32352 1656 1308 S 0.0 0.2 0:00.04 authdaemond
1044 root 20 0 32352 1636 1292 S 0.0 0.2 0:00.06 authdaemond
1045 root 20 0 32352 1656 1308 S 0.0 0.2 0:00.07 authdaemond
1046 root 20 0 32352 1636 1292 S 0.0 0.2 0:00.07 authdaemond
1050 root 20 0 4064 296 292 S 0.0 0.0 0:00.00 courierlogger
1051 root 20 0 11900 744 740 S 0.0 0.1 0:00.00 couriertcpd
1058 root 20 0 4064 476 400 S 0.0 0.0 0:00.07 courierlogger
1059 root 20 0 11900 848 776 S 0.0 0.1 0:00.09 couriertcpd
1067 root 20 0 4064 296 292 S 0.0 0.0 0:00.00 courierlogger
1068 root 20 0 11900 744 740 S 0.0 0.1 0:00.00 couriertcpd
1079 postfix 20 0 392m 1580 1076 S 0.0 0.2 0:09.42 psa-pc-remote
1094 root 20 0 48408 884 304 S 0.0 0.1 0:00.01 nginx
1096 nginx 20 0 48412 4080 1840 S 0.0 0.4 1:04.49 nginx
1116 root 20 0 333m 756 668 S 0.0 0.1 0:00.13 sw-engine-fpm
1151 root 20 0 11300 1004 1000 S 0.0 0.1 0:00.03 mysqld_safe
1329 named 20 0 233m 2696 1400 S 0.0 0.3 0:00.74 named
1447 root 20 0 58208 2100 1988 S 0.0 0.2 1:27.99 master
1450 postfix 20 0 58488 2388 2124 S 0.0 0.2 0:49.51 qmgr
1523 root 20 0 343m 20m 8000 S 0.0 2.1 0:27.32 httpd
1909 drweb 20 0 220m 68m 324 S 0.0 6.9 0:02.92 drwebd.real
1925 root 20 0 341m 24m 3140 S 0.0 2.5 0:46.87 sw-engine
1934 root 20 0 524m 3072 884 S 0.0 0.3 3:25.34 sw-collectd
1962 root 20 0 114m 1324 712 S 0.0 0.1 0:04.08 crond
1977 root 20 0 4060 572 488 S 0.0 0.1 0:00.00 mingetty
1978 root 20 0 4072 612 528 S 0.0 0.1 0:00.00 agetty
1980 root 20 0 4060 568 488 S 0.0 0.1 0:00.00 mingetty
1982 root 20 0 4060 568 488 S 0.0 0.1 0:00.00 mingetty
1985 root 20 0 4060 572 488 S 0.0 0.1 0:00.00 mingetty
1987 root 18 -2 12384 2104 388 S 0.0 0.2 0:00.00 udevd
1989 root 20 0 4060 572 488 S 0.0 0.1 0:00.00 mingetty
1990 root 18 -2 12384 2104 384 S 0.0 0.2 0:00.00 udevd
1992 root 20 0 4060 572 488 S 0.0 0.1 0:00.00 mingetty
2670 postfix 20 0 58288 2732 2016 S 0.0 0.3 0:00.16 tlsmgr
2899 apache 20 0 344m 15m 2448 S 0.0 1.6 0:01.74 httpd
4677 apache 20 0 343m 15m 2860 S 0.0 1.6 0:00.62 httpd
4698 apache 20 0 343m 15m 2844 S 0.0 1.6 0:00.63 httpd
4705 apache 20 0 344m 16m 2892 S 0.0 1.6 0:00.61 httpd
7183 root 10 -10 22520 5780 2864 S 0.0 0.6 0:06.85 atop
7250 drweb 20 0 220m 68m 208 S 0.0 6.9 0:03.57 drwebd.real
21800 postfix 20 0 58288 2724 2016 S 0.0 0.3 0:00.01 pickup
24904 apache 20 0 343m 14m 2016 S 0.0 1.5 0:00.02 httpd
24909 apache 20 0 343m 14m 2016 S 0.0 1.5 0:00.02 httpd
24923 apache 20 0 343m 15m 2028 S 0.0 1.5 0:00.02 httpd
24925 apache 20 0 343m 15m 2016 S 0.0 1.5 0:00.02 httpd
25303 apache 20 0 343m 14m 2012 S 0.0 1.5 0:00.01 httpd
25317 apache 20 0 343m 14m 2016 S 0.0 1.5 0:00.01 httpd
25319 apache 20 0 343m 15m 2012 S 0.0 1.5 0:00.01 httpd
25322 apache 20 0 343m 15m 2020 S 0.0 1.5 0:00.00 httpd
25328 apache 20 0 343m 14m 2016 S 0.0 1.5 0:00.01 httpd
25330 apache 20 0 343m 15m 2056 S 0.0 1.5 0:00.01 httpd
25336 apache 20 0 343m 14m 2012 S 0.0 1.5 0:00.01 httpd
25343 apache 20 0 343m 14m 2016 S 0.0 1.5 0:00.00 httpd
25345 apache 20 0 343m 14m 2016 S 0.0 1.5 0:00.01 httpd
25372 apache 20 0 343m 14m 2016 S 0.0 1.5 0:00.00 httpd
25373 apache 20 0 343m 14m 2028 S 0.0 1.5 0:00.01 httpd
26292 fti8576x 20 0 0 0 0 Z 0.0 0.0 0:01.96 php-cgi <defunct>
26356 root 20 0 4068 524 448 S 0.0 0.1 0:00.00 sleep
26360 root 20 0 15020 1180 884 R 0.0 0.1 0:00.01 top
29357 apache 20 0 240m 10m 612 S 0.0 1.0 0:37.33 httpd
31515 apache 20 0 343m 15m 2616 S 0.0 1.6 0:00.67 httpd
 
Last edited:
Thank you so much BrewsterL. Yes! I'm having the similar issue. These websites have been on this server for awhile now. Never had a such issue.

Igore, Any answer? Where to look?

Without any reason Apache memory goes up more than 20% , then its come back down to 3.5% in less than 5mins.
 
I'm having this issue too. Ever since I've upgraded from Plesk 9.5.4 to Plesk 11.5.30 my httpd processes are each over 640M (390M resident). I've reduced how many run (max servers), but still they easily chew up 8GB of ram in minutes. See below, no free memory... It chews up 100% of ram within a few minutes.

top - 23:27:53 up 22 days, 2:45, 3 users, load average: 0.58, 0.43, 0.57
Tasks: 282 total, 1 running, 266 sleeping, 2 stopped, 13 zombie
Cpu(s): 13.9%us, 8.3%sy, 0.0%ni, 77.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8043700k total, 8043700k used, 0k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13748 apache 15 0 640m 386m 6924 S 23.0 4.9 0:10.25 /usr/sbin/httpd
13656 apache 16 0 641m 386m 4864 S 22.7 4.9 0:05.94 /usr/sbin/httpd
13608 apache 15 0 640m 387m 6388 S 22.3 4.9 0:12.44 /usr/sbin/httpd
13751 apache 16 0 639m 386m 7072 S 8.2 4.9 0:18.83 /usr/sbin/httpd
1632 mysql 15 0 357m 182m 7736 S 4.9 2.3 451:14.42 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-er
13610 apache 15 0 631m 378m 7388 S 4.3 4.8 0:11.00 /usr/sbin/httpd
22505 root 18 0 2704 1188 812 R 1.3 0.0 0:00.16 top


You say yours drops back down. Mine never does. I'm always pegged at 100% until I restart apache.
 
Last edited:
Hi Galaxy,

Have your php version change since the update?

If it has, try to install the php version you have been using b4 and try.

Some older php script use high apache, when using on new version.

You can have multiple php version in plesk 11.5
 
Just to confirm that:

my out of the box 11.5 has a typical apache at virt 450m res 38m - PHP version 5.4.25
My 8.6 PLESK has typical apache at virt 72m res 30m - PHP version 5.3.13

I haven't compared the 2 apache configurations yet and as the poster above says, we now have much more control over Apache/PHP configurations on a subdomain by subdomain basis, including selective use of nginx and Fast-CGI and php-fpm.
 
Last edited:
DRY411S said:
Just to confirm that:

my out of the box 11.5 has a typical apache at virt 450m res 38m - PHP version 5.4.25
My 8.6 PLESK has typical apache at virt 72m res 30m - PHP version 5.3.13

I haven't compared the 2 apache configurations yet and as the poster above says, we now have much more control over Apache/PHP configurations on a subdomain by subdomain basis, including selective use of nginx and Fast-CGI and php-fpm.
Click to expand...

Same script?
 
DRY411S said:
Just to confirm that:

my out of the box 11.5 has a typical apache at virt 450m res 38m - PHP version 5.4.25
My 8.6 PLESK has typical apache at virt 72m res 30m - PHP version 5.3.13

I haven't compared the 2 apache configurations yet and as the poster above says, we now have much more control over Apache/PHP configurations on a subdomain by subdomain basis, including selective use of nginx and Fast-CGI and php-fpm.
Click to expand...

Also If you are running Magento by any chance, apply the php 5.4 patch.
 
Hi,

No Magento. Same PHP.

I see all the memory is in heap looking at /proc/<pid>/smaps.
I did an strace on its startup to find out why all this memory is being allocated.
On initial glance, I see there's *lots* more config files that get opened and read in. Many of the config files are read in multiple times, too.

So I've noticed that since the upgrade, instead of one http config file for horde and one for atmail, there's now one for *every* domain. I then kept getting complaints from users that their webmail no longer worked, so you have to manually go and turn them all back on. A pain when there's hundreds of domains. I don't get the logic either, as every customer wants webmail on their domain. This just adds to the memory usage of the server.

So back to the strace output. I've found that most of the config files are opened and read in multiple times. Each time allocating more memory.
The "updated" config file structure is what I believe has caused the overblown memory consumption and wasn't thought out (or at least tested) properly.
Here's a quick summary:

/etc/httpd/conf.d - each of the files here are opened and read in once
/etc/httpd/conf/plesk.conf.d/forwarding/<domain>_httpd.conf - each of the files in here are opened and read in twice for each domain
/etc/httpd/conf/plesk.conf.d/ip_default/<domain>.conf - each are opened/read once
/etc/httpd/conf/plesk.conf.d/vhosts/<domain>.conf - each are opened/read twice
/etc/httpd/conf/plesk.conf.d/webmails/atmail/<domain>_webmail.conf - for each domain/subdomain, each file is opened/read 368 times !
/etc/httpd/conf/plesk.conf.d/webmails/horde/<domain>_webmail.conf - for each domain/subdomain, each file is opened/read 321 times !
/var/www/vhosts/system/<domain>/conf/vhost.conf - opened/read twice
/var/www/vhosts/system/<domain>/conf/vhost_ssl.conf - opened/read twice

So I really think it all stems from the architecture of the webmail handling. I believe the setup used in Plesk 9.5.4 was sufficient and worked well.
I just can't understand why they're opening and reading in all the webmail configs *per-domain* over 300 times each.
And I see memory allocations during all of those reads.

Igor, if you're reading this, can we get the Parallels engineers to look at this and fix it?
The old architecture had just one file for each webmail client filled with the IP addresses of the clients that used that webmail client. I see nothing wrong with that. I don't know of any customer that doesn't want/need a webmail client, and doesn't need any custom configuration. I know that horde looks at the URL/IP address that was requested and makes assumptions about the domain from that. No custom config file required here per-domain.

Within 2-3 minutes of apache startup, my memory utilization goes to 100%. And it never gets returned until apache is restarted.

Igor, PM me if you would like a copy of my strace output to pass on to any engineers.
 
From a phpinfo() perspective, there are more included .ini files and more php modules being loaded by default in 11.5 than in 8.6, and the master PHP 'directives' like memory_limit, post_max_size, upload_max_filesize are all significantly larger than 8.6.

I'm not tech savvy enough to assess how much impact this has on actual memory occupancy though.
 
There's not much of a difference between what I had in 9.5.4 vs. 11.5.30 for PHP.
And the memory problem does not appear to come from libraries being mmapped.

The problem is in heap allocations (I see over 607 meg allocated on the heap, 373M of it RSS).
The PHP memory limit is 128M (which is what I had back on Plesk 9.5.4).
So it has nothing to do with PHP.
 
Guys, I think that these problems are very difficult to investigate in scope of forum discussion. There's a lot we can discuss, but these problems require a detailed investigation directly on the server. There may be a huge number of reasons for this problem. Everyone can have their own, unique reasons. So I would advise you contact support.
 
OK, sure enough... I fixed the problem.
I've reduced the apache footprint from 640M (386M resident) down to 95M (about 45M resident).
All I did was scrap the webmail config file implementation and use the old one from Plesk 9.5.4.
I commented out the includes of
It appears the *new* way of doing it which includes all the configs in zz010_psa_httpd.conf:

#Include '/etc/httpd/conf/plesk.conf.d/horde.conf'
#Include '/etc/httpd/conf/plesk.conf.d/atmail.conf'

and put back the old style config in conf.d for horde & atmail where there's only a single VirtualHost for SSL and non-SSL and include all the server aliases:

Include "/etc/httpd/conf/plesk.conf.d/webmails/atmail/*.conf"

or

Include "/etc/httpd/conf/plesk.conf.d/webmails/horde/*.conf"

once in each.

I just need to make sure zz010_psa_httpd.conf doesn't get overwritten. I've changed its permissions to 0444.
I'm a happy camper now. I have over 5GB free memory now. It was always 0 since the plesk upgrade to 11.5.30 (all consumed by apache).

Igor, I recommend filing a bug with the developers to re-architect how webmail configs are processed.
 
I managed to lower the Apache memory usage simply disabling Horde (which I don't use).
When I have disabled it, memory has lowered from 22.5% to 8%.
 
You must log in or register to reply here.

Similar threads

Q
Resolved problem with ram server
Replies
8
Views
2K
Qusay
Q
Vik P
Issue Higher memory usage - Memory Maxing out | Need Help ASAP
Replies
2
Views
4K
iHuman
I
J
Issue Plesk Runs Multiple Instances of a Single WordPress Installation?
Replies
3
Views
1K
Bitpalast
Bitpalast
F
Resolved Hard Drive - Status Red??
Replies
2
Views
1K
Filipe Silva
F
Cristian Rodriguez
Resolved To many Apache process eating memory
Replies
6
Views
25K
Cristian Rodriguez
Cristian Rodriguez
Back
Top