BigBirdy

Active Member
Jun 10, 2007
28
0
151
I have a hosting solution which is running ,WHM 11.2.0, cPanel 11.6.0-R15076 on CentOS 4.3. Recently I rebuilt apache with PHP 5.2.3, suexec and php suexec and all seems to be running fine and I can see php process spawned under any given account username when their domains are accessed. However these php processes show around 70-90% CPU use and site performance is definately sluggish. Are there some tweaks I can do to improve performance or should I consider running FastCGI? Is this something relatively simple to setup?

I already run the Zend optimizer, have given PHP 64mb as a limit etc.
 

bmcpanel

Well-Known Member
Jun 1, 2002
544
0
316
I have a hosting solution which is running ,WHM 11.2.0, cPanel 11.6.0-R15076 on CentOS 4.3. Recently I rebuilt apache with PHP 5.2.3, suexec and php suexec and all seems to be running fine and I can see php process spawned under any given account username when their domains are accessed. However these php processes show around 70-90% CPU use and site performance is definately sluggish. Are there some tweaks I can do to improve performance or should I consider running FastCGI? Is this something relatively simple to setup?

I already run the Zend optimizer, have given PHP 64mb as a limit etc.
What version of php were you running before? Were your running php as a module or cgi-binary before you upgraded to 5.2.3? Were you running php-suexec before you upgraded to 5.2.3?

Is every php process running at 70%-90% or is it only some?

If the latter, the possibly it is the php script itself that is doing a lot and causing high cpu usage. I say this because most of my php processes are low cpu usage, but an occasional php script will show up that uses a lot of cpu usage? There are ways to tweak php.ini for performance. I don't know how much of a difference it makes performance wise, but you might give it a try.

Below is but one example of a setting in php.ini that can affect performance depending on how you set it. There are others. Read you php.ini very closely and then tweak it as you wish.

; This directive tells PHP whether to declare the argv&argc variables (that
; would contain the GET information). If you don't use these variables, you
; should turn it off for increased performance.
register_argc_argv = Off
 

BigBirdy

Active Member
Jun 10, 2007
28
0
151
What version of php were you running before? Were your running php as a module or cgi-binary before you upgraded to 5.2.3? Were you running php-suexec before you upgraded to 5.2.3?

Is every php process running at 70%-90% or is it only some?

If the latter, the possibly it is the php script itself that is doing a lot and causing high cpu usage. I say this because most of my php processes are low cpu usage, but an occasional php script will show up that uses a lot of cpu usage? There are ways to tweak php.ini for performance. I don't know how much of a difference it makes performance wise, but you might give it a try.

Below is but one example of a setting in php.ini that can affect performance depending on how you set it. There are others. Read you php.ini very closely and then tweak it as you wish.

; This directive tells PHP whether to declare the argv&argc variables (that
; would contain the GET information). If you don't use these variables, you
; should turn it off for increased performance.
register_argc_argv = Off
I was running php 5.2.1 before but was running as a module and with suexec and php suexec however for some reason hosted sites did not have write access as the account owners to their own web roots and permissions/owner had to be set as nobody. After numerous attempts to get my hosting/vps provider to fix this problem, they went and rebuilt apache (I still dont have all details of what they did), and then things seemed to work fine as far as permissions and php suexec goes, and then apache was running as a CGI, which is what I want I think?

When I watch top and hit any hosted site, a php process owned by the account holder for that domain is launched and nearly pegs the cpu.
 

bmcpanel

Well-Known Member
Jun 1, 2002
544
0
316
I was running php 5.2.1 before but was running as a module and with suexec and php suexec however for some reason hosted sites did not have write access as the account owners to their own web roots and permissions/owner had to be set as nobody. After numerous attempts to get my hosting/vps provider to fix this problem, they went and rebuilt apache (I still dont have all details of what they did), and then things seemed to work fine as far as permissions and php suexec goes, and then apache was running as a CGI, which is what I want I think?

When I watch top and hit any hosted site, a php process owned by the account holder for that domain is launched and nearly pegs the cpu.
Check out the script that is pegging the cpu. It may be a poorly designed script or a script that is executing for a long time, (probably doing some time of remote access to a different site or accessing and parsing a lot of mysql data).

I have been running php as a cgi-binary for nearly two years and I have noticed very little difference in server load since then. The only problems I have noticed have been with individual scripts that connect to mysql and have a lot of action in them that raises server load. It is rare and I suspect these same scripts would have been a problem under php as a module.

You may also wish to look into mod_cgid for apache. Speeds up php running as cgi if you are running Apache 2.x.x

http://httpd.apache.org/docs/2.0/mod/mod_cgid.html
 
Last edited:

BigBirdy

Active Member
Jun 10, 2007
28
0
151
Check out the script that is pegging the cpu. It may be a poorly designed script or a script that is executing for a long time, (probably doing some time of remote access to a different site or accessing and parsing a lot of mysql data).

I have been running php as a cgi-binary for nearly two years and I have noticed very little difference in server load since then. The only problems I have noticed have been with individual scripts that connect to mysql and have a lot of action in them that raises server load. It is rare and I suspect these same scripts would have been a problem under php as a module.

You may also wish to look into mod_cgid for apache. Speeds up php running as cgi if you are running Apache 2.x.x

http://httpd.apache.org/docs/2.0/mod/mod_cgid.html
Could you suggest a way in which to determine/identify which php scripts may be loading the server? Most sites are typical Joomla sites
 

BigBirdy

Active Member
Jun 10, 2007
28
0
151
Problem discovered. Well after nearly a week of searching, debugging and fiddling the source of the problem was discovered. It appears that one of the apache/php rebuilds ran out of memory and somehow corrupted the php.ini file which I didnt notice. I was a bit suspicious since the file was around the same size as the previous version, yet only showed around half the original content. I guess the php process had trouble parsing this corrupted file and so was hanging. Restoring the php.ini file immediately fixed the problem. Whew!! was a frustrating week but so glad it was a simple problem to fix.

btw: Although this machine is running apache 1.x I will look into that module for apache 2x on my other machines for speeding up php as cgi.

Thanks for the help/suggestions
 

bmcpanel

Well-Known Member
Jun 1, 2002
544
0
316
Problem discovered. Well after nearly a week of searching, debugging and fiddling the source of the problem was discovered. It appears that one of the apache/php rebuilds ran out of memory and somehow corrupted the php.ini file which I didnt notice. I was a bit suspicious since the file was around the same size as the previous version, yet only showed around half the original content. I guess the php process had trouble parsing this corrupted file and so was hanging. Restoring the php.ini file immediately fixed the problem. Whew!! was a frustrating week but so glad it was a simple problem to fix.

btw: Although this machine is running apache 1.x I will look into that module for apache 2x on my other machines for speeding up php as cgi.

Thanks for the help/suggestions
Glad to hear you identified the problem. corrupt php.ini? Good detective work.