The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Server Load

Discussion in 'Workarounds and Optimization' started by Zion Ahead, Apr 21, 2010.

  1. Zion Ahead

    Zion Ahead Well-Known Member

    Joined:
    Nov 10, 2006
    Messages:
    347
    Likes Received:
    0
    Trophy Points:
    16
    My Server Specs:
    - Centos 4.8 32 bit
    - Cpanel / WHM
    - suPHP enabled on PHP 5.3x
    - MySQL 5x

    I need someone to please show me various ways to trace what is causing server load spikes.

    Sometimes I see so many "nobody" users running httpd processes, but I dont' know how to determine what user(s) it might be, even though suPHP is enabled.

    I'm aware of "top" and "top -c" and mysqladmin -i2 processlist status for example.

    If I do ps auxaux I get so many processes from various system and customer users.
     
  2. rackaid

    rackaid Active Member

    Joined:
    Jan 18, 2003
    Messages:
    42
    Likes Received:
    1
    Trophy Points:
    8
    Location:
    Jacksonville, FL
    cPanel Access Level:
    DataCenter Provider
    If there is a script actively running, you may be able to do:

    lsof -p pid#

    Where pid# is the process id. This will return a list of files that the thread has opened.

    Also, you haven't change the start/max server variables in Apache have you?

    I see many people raise these in an effort to fix performance issues but you rarely need more than the default settings unless your server is very busy (>100K's hits per day).
     
  3. brianoz

    brianoz Well-Known Member

    Joined:
    Mar 13, 2004
    Messages:
    1,146
    Likes Received:
    6
    Trophy Points:
    38
    Location:
    Melbourne, Australia
    cPanel Access Level:
    Root Administrator
    Try "ps -efH" instead of "ps aux". It sorts processes in a hierarchy, which makes it clearer what started what.
     
  4. madaboutlinux

    madaboutlinux Well-Known Member

    Joined:
    Jan 24, 2005
    Messages:
    1,052
    Likes Received:
    2
    Trophy Points:
    38
    Location:
    Earth

    You can also check the websites under which those httpd processes are running from

     
  5. Zion Ahead

    Zion Ahead Well-Known Member

    Joined:
    Nov 10, 2006
    Messages:
    347
    Likes Received:
    0
    Trophy Points:
    16
    See attached
     

    Attached Files:

  6. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    I don't need to see anything with what you just said ....

    PHP v5.3 series is non-backwards compatible to previous PHP versions and release trees and currently at this moment is completely incompatible with the vast majority of scripts and programs out there.

    Some application authors have released rewritten update releases of their respective applications to support PHP 5.3 but currently right now at this moment those still remain in a very small minority.

    Running PHP v5.3 in a production environment for anything other than script development as mentioned earlier is NOT recommended and will indeed cause you loading issues, errors, and script execution problems all over the place.

    In time, the scripts and programs out there will eventually be rewritten to support PHP 5.3 and upcoming PHP 6.x but we are not there yet ....

    The very first thing I would look at doing is changing your PHP version from PHP 5.3.x to PHP 5.2.13 as that is actually the newest release only came out a month or so ago and the most compatible with most of the scripts out there currently. Hold off going to 5.3 until there is a lot more industry wide support for it among scripts and programs.

    Your second issue to complicate matters is likely "permission" related ---

    General average users as a whole do not understand the differences between DSO, SuPHP, FCGI, and so on and don't realize that they cannot set or use any of the "777" or "666" permissions that script authors so often blindly write in their installation instructions assuming that the end user is going to be DSO based when that too is a minority these days.

    If a file or folder is set to 777 under SuPHP, aside from potential error 500 conditions and script errors, this will also cause drastic performance slowdowns server wide. I am not going to go into in depth detail as for the technical reasons why that is but it is related to what I just said.

    Other than getting on a more compatible PHP version to the scripts your user's might be trying to install and run on their accounts, I would also sweep the server for "777" permissions and reset those and that too will also help to take care of a lot of your loading issues.

    Now with those two items out of the way, if you are still having problems and loading issues after that then come talk to me and I'll help you deal with those but let's address the more basic and obvious issues first.
     
  7. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    Since the discussion was talking about "Linux commands" up to the point you mentioned "Apache Status", I suppose it might be useful to some to not that you can see WHM's "Apache Status" output from the shell ...

    Code:
    # httpd fullstatus
    
    (A lot of people don't know about 'fullstatus' so a good opportunity there to point that little tidbit out ;) )
     
Loading...

Share This Page