|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60274 cpu steady on httpd processes never clears
Submitted: 2011-11-11 21:21 UTC Modified: 2012-10-26 05:21 UTC
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: jwprice at georgiasouthern dot edu Assigned: sixd (profile)
Status: No Feedback Package: OCI8 related
PHP Version: 5.3.8 OS: Solaris 10
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: jwprice at georgiasouthern dot edu
New email:
PHP Version: OS:


 [2011-11-11 21:21 UTC] jwprice at georgiasouthern dot edu
During a busy time over 600 httpd processes on the webserver and oracle database 
cpu load over 88. The cpu load on each httpd process climbs to 3 and 4 % over 
loading our server forcing cpuloads of > 200 on the webserver. After load on the 
database clears usually in about 15 min, the httpd process never clear their cpu 
usage even after a week of no activity. The cpu load on the httpd processes 
usally ranges from .4 to 0%. The cpu load problem on the webserver is definitely 
related to slowness on the oracle database side, but what concerns me is the 
apache server never clears itself. I suspect there is some issue with the oci 

I'm reporting this before upgrading to the latest version because i don't see 
any fixes related. We are using php version 5.3.4. Configure script below. 


cd ${Home}/${PHPStdName}${PHPVer}
./configure \
            --prefix=${Home}/local \
            --with-apxs2=${Home}/server/bin/apxs \
            --with-gettext \
            --enable-ftp \
            --with-openssl=/usr/local/ssl \
            --with-mysql=${MysqlHome} \
            --with-pear=${HOME}/pear \
            --enable-cli \
            --disable-cgi \
            --with-curl \
            --with-mcrypt=/usr/local \
            --with-zlib \
            --with-zlib-dir=/usr/local \
            --with-jpeg-dir=/usr/local \
            --with-png-dir=/usr/local \
            --with-xpm-dir=/usr/local \
            --with-freetype-dir=/usr/local \
            --enable-gd-native-ttf \
            --with-ttf=/usr/local \
            --with-gd \
            --with-ldap=/usr/local \
            --with-oci8=${OracleClientHome} \

Test script:
We use 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-02-28 18:39 UTC]
This bug just came to my attention and I've now changed the package from 
"Performance" to "OCI8".

How are you measuring CPU load? How is Apache configured and what is the system 
configuration? Are httpd process spinning?  Are they being cycled? 600 processes 
seems a large number for a single commodity machine. One old rule of thumb was 
to set maxclients to 25 for a 1Gb, 2-core machine.  Look at reducing maxclients 
and using persistent OCI8 connections.  If possible, use Oracle 11g DRCP 

I'd recommend upgrading the Oracle client by using the free Oracle Instant 
Client.  Use the latest version that can still connect back to your DB.
The current PHP OCI8 hasn't had any particularly relevant changes since 5.3.4.

Make sure the code uses binds, prefetches, etc. effectively.  Check the 
performance tips in
 [2012-02-28 18:39 UTC]
-Status: Open +Status: Feedback -Package: Performance problem +Package: OCI8 related -Assigned To: +Assigned To: sixd
 [2012-02-28 19:46 UTC] jwprice at georgiasouthern dot edu
-Status: Feedback +Status: Assigned
 [2012-02-28 19:46 UTC] jwprice at georgiasouthern dot edu
cpu load was measured with uptime and prstat. Note this is a 4 core 16 thread 
16Gb SunFire T2000. Load is normally between 3 and 5, between 350 and 550 
process. During the busy time load was > 200 and stayed there even after the 
load on the database was gone. I would say that the httpd processes were 
spinning at 3 to 4% of cpu each normally this is a lot lower .1%. They are not 
being cycled. We are using an older version of the oracle client we will 
definitely try to update it. We have since updated to apache 2.2.21 and php-
5.3.8. We will have another high load Mar 5th.  We've stayed away from 
persistent connections because it caused a high load on the database. We will 
look into the performance tips you mentioned.

Apache was configured and compiled with the following:
./configure --enable-modules=most \
            --prefix=${Home}/server \
            --enable-mods-shared=most \
            --enable-proxy \
            --enable-proxy-http \
 [2012-02-29 00:09 UTC]
Are the httpd processes not being cycled by choice?  What are the MaxClients and 
MaxRequestsPerChild values? (Are you using the prefork MPM?).

What are the php.ini oci8.* values?

Is the DB on a different host?

oci_pconnect will cause DB host memory contention unless you restrict MaXClients 
and/or have Oracle 11g and use its DRCP.
 [2012-02-29 00:10 UTC]
-Status: Assigned +Status: Feedback
 [2012-02-29 13:42 UTC] jwprice at georgiasouthern dot edu
-Status: Feedback +Status: Assigned
 [2012-02-29 13:42 UTC] jwprice at georgiasouthern dot edu
What do you mean by httpd process cycled? Do you be restarted every so often?
I was not aware there were and php.ini oci settings so we're using whatever the 
defaults are. The database is on a separate machine.

These settings have been set for a couple of years now. We changed MaxClients to 
1200 an it solved couple of problems we were having and worked for one fall registration. We only started having a problem when we upgraded php and apache 
from php 5.2.11 and apache 2.0.63

<IfModule prefork.c>
ServerLimit        1200
StartServers         5
MinSpareServers      5
MaxSpareServers     10
MaxClients         1200
MaxRequestsPerChild  5000
 [2012-02-29 23:56 UTC]
The MaxRequestsPerChild setting will cause the httpd processes to restart after 
a number of HTTP requests.

Your MaxClients looks inherently high; but only your application tuning can 
determine the best value. It effectively means you could have up to 1200 
connections open to the DB, which will cause problems in the DB tier.

I suggest:
- Do the PHP & Oracle client upgrade previously discussed.
- Bring the OS patch level up to date.
- Review the application for inefficiencies - fixing these should help
reduce load in each tier.
- Check for application errors and for Oracle trace files.  using Oracle Instant 
Client 11g will create better client side trace files.
- Monitor if anything unexpected is causing load during "idle" times.  
- Check that the number of httpd processes decreases when there is no load.
- Use truss, pstack etc to identify what any high CPU httpd process are doing
 [2012-02-29 23:56 UTC]
-Status: Assigned +Status: Feedback
 [2012-10-26 05:21 UTC]
-Status: Feedback +Status: No Feedback
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 12:01:29 2024 UTC