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.

How to identify process owner / control resource intensive process

Discussion in 'E-mail Discussions' started by rebouy, Jan 5, 2011.

  1. rebouy

    rebouy Member

    Joined:
    Sep 1, 2010
    Messages:
    21
    Likes Received:
    0
    Trophy Points:
    1
    Hi, the server's load has increase this few last days.

    When i go to process manager, this entry is always the first one :
    16827 (Trace) (Kill) 32006 0
    96.2 0.3 /var/cpanel/3rdparty/bin/php -c /usr/local/cpanel/3rdparty/etc/roundcube /usr/local/cpanel/base/3rdparty/roundcube/index.php

    This process by owner 32006 is using 96.2% cpu.
    How can i really identify whats going on here?

    We have other servers besides the one with the problem, and the others doesnt have this issue.

    TNX!
     
  2. cPanelDon

    cPanelDon cPanel Quality Assurance Analyst
    Staff Member

    Joined:
    Nov 5, 2008
    Messages:
    2,557
    Likes Received:
    7
    Trophy Points:
    38
    Location:
    Houston, Texas, U.S.A.
    cPanel Access Level:
    DataCenter Provider
    Twitter:
    Roundcube processes should be relatively short-lived and not run for several hours. Do you see the same process ID displayed for several hours, or does the process ID change upon subsequent status checks when viewing running processes at a later time? For reference, the process ID (PID) is displayed on the left at the start or beginning of the line.

    If you would like to see which users are accessing Roundcube, you may use the following command via root SSH access to search the cPanel access_log:
    Code:
    # egrep "GET (/cpsess[0-9]+)?/3rdparty/roundcube/\?.* HTTP/1.[01]" /usr/local/cpanel/logs/access_log
    Are any "webmaild" processes running? The following commands should list any that may be running along with the IP address of the user connected:
    Code:
    # pgrep -l -f webmaild
    Please let us know your cPanel&WHM version and Roundcube version; these can be obtained using the following command via root SSH access:
    Code:
    # grep -H '' /usr/local/cpanel/version /var/cpanel/roundcube/version
     
  3. rebouy

    rebouy Member

    Joined:
    Sep 1, 2010
    Messages:
    21
    Likes Received:
    0
    Trophy Points:
    1
    It was running for several hours. i just checked and is the same pid as my first post. 16827.

    Yes, there are several webmaild processes running

    /usr/local/cpanel/version:11.28.64-RELEASE_51024
    /var/cpanel/roundcube/version:0.4.2.cp3

    This only happens in 1 of our servers, the rest is fine. Also it started a just few days ago.

    According to the process log, it started on 12-23-2010 and since this day this process is responsible for 10% of the daily cpu load.

    This is a closed server, we havent add any new accounts to it in quite a long time. Normal avg load was around 1.5 - 2.0 at peek hours, now its 2.0 - 4.0 at any give time.
     
  4. rebouy

    rebouy Member

    Joined:
    Sep 1, 2010
    Messages:
    21
    Likes Received:
    0
    Trophy Points:
    1
    Is it ok to just kill the process and restart apache?

    How can we prevent same thing to keep happenin?
     
  5. cPanelDon

    cPanelDon cPanel Quality Assurance Analyst
    Staff Member

    Joined:
    Nov 5, 2008
    Messages:
    2,557
    Likes Received:
    7
    Trophy Points:
    38
    Location:
    Houston, Texas, U.S.A.
    cPanel Access Level:
    DataCenter Provider
    Twitter:
    It is OK to kill the Roundcube process(es); however, please note that restarting Apache is not necessary as Roundcube is not being served from Apache/httpd.

    Was it just one (1) Roundcube process that was running for several days, or are there multiple Roundcube processes that run for several days? If, after killing the Roundcube process(es), the problem recurs again then I would consider submitting a support request.
     
Loading...

Share This Page