Facebook
Twitter
OK, lately I saw a couple of threads on this forum reporting problems with high CPU and/or memory usage. Naturally, this can be caused by a multitude of reasons and usually requires investigation. I decided to post a couple of common reasons and solutions here (this was written with Plesk 11 for Linux in mind, but may be applicable to other versions and products as well, YMMV however).
DISCLAIMER: this information is provided as is and without warranty of any kind (including promise of usefulness or not being harmful). Therefore think first and use at your own risk later.
1) Leap second
A day or so ago a leap second was introduced. This caused some... disturbance on a number of Linux systems. Some kernels just crashed or hung. Other applications started to misbehave, e.g. consume a lot of CPU.
Symptoms: CPU usage of your Java applications or MySQL server (other applications might be susceptible as well) have grown significantly lately.
Solution: is pretty simple. You just need to remove leap second flag from the system. Running this should suffice (you don't need to restart other services after that):
# /etc/init.d/ntpd stop; date -s "`date`"; /etc/init.d/ntpd restart
Alternatively you could just restart the machine. It seems to help too.
Restarting the affected services alone, however, will not fix the problem.
2) PHP sessions cleanup
On some systems (I believe, rpm-based only) in Plesk 10 PHP sessions cleanup was not working properly. This was fixed in Plesk 11 (a proper periodic cleanup task was added). Therefore if you've just upgraded from a lower Plesk version you might notice at times a significant CPU and memory load (provided your sessions directory is clogged up).
Symptoms: 'find' and 'fuser' processes are consuming a lot of CPU time and/or memory.
Solution: is rather straightforward (and relatively painless, if you can afford it). Just purge all your PHP sessions. First you need to find where your sessions are stored. For that find your client php.ini file(s) which are usually in something like /etc/php5/*/php.ini or /etc/php.ini. Than find 'session.save_path' directive there. If you actually have this problem, it most probably will contain either '/var/lib/php/session' or '/var/lib/php5', let's assume this is a value of 'sessionSavePath' shell variable. Then to purge all sessions:
# [ -n "${sessionSavePath}" ] && rm -f ${sessionSavePath}/* || echo "Set sessionSavePath first"
Take care not to remove the directory itself. Also I advice against removing Plesk cleanup task (as somebody else might advice to do), since this will just slow down your server and lead to increased disk space consumption in the long run.
3) sw-collectd data collection interval is too low
In previous Plesk versions sw-collectd data collection interval was not set explicitly. By default it is 10 or 0 (can't remember right now which one), the latter means "collect data as often as you can". This, obviously, usually results in noticeable CPU and other systems' load.
In Plesk 11 (on clean installations, i.e. not upgrades) this interval is set to 300 (5 minutes). However, upgraded installations will have their interval value unchanged. There is a serious reason for that: simply changing interval value in configuration file and restarting sw-collectd may lead to unexpected behavior. E.g. on my test installation just increasing this value led to rrdtool showing only either zero or NaN values.
Symptoms: sw-collectd process consumes a lot of CPU time and/or other resources.
Solution: properly set data collection interval to some reasonably high value. E.g. 300 seconds. I'm not entirely sure (so don't quote me on this), but I doubt setting it to lower value brings any benefits now, since Health monitor module rereads resource usage values at this rate. Note that to safely increase the interval you must drop entire previous statistics.
1. # /etc/init.d/sw-collectd stop
2. Edit file /etc/sw-collectd/collectd.conf to include 'Interval 300' line at top level. Replace '300' with your desired interval in seconds. E.g. (relevant chunk of file, just to give you a context):
# rm -rf /usr/local/psa/var/health/data/localhost/*
4. # /etc/init.d/sw-collectd restart
Also, there is a KB for increasing the interval value here, even two, to be precise. They are both wrong, however.
That's it for now. If I find other common reasons, I'll update the thread.
If you try any of the solutions, please post whether it helped you or not. If not, post exact symptoms. Maybe somebody will be able to help you.
DISCLAIMER: this information is provided as is and without warranty of any kind (including promise of usefulness or not being harmful). Therefore think first and use at your own risk later.
1) Leap second
A day or so ago a leap second was introduced. This caused some... disturbance on a number of Linux systems. Some kernels just crashed or hung. Other applications started to misbehave, e.g. consume a lot of CPU.
Symptoms: CPU usage of your Java applications or MySQL server (other applications might be susceptible as well) have grown significantly lately.
Solution: is pretty simple. You just need to remove leap second flag from the system. Running this should suffice (you don't need to restart other services after that):
# /etc/init.d/ntpd stop; date -s "`date`"; /etc/init.d/ntpd restart
Alternatively you could just restart the machine. It seems to help too.
Restarting the affected services alone, however, will not fix the problem.
2) PHP sessions cleanup
On some systems (I believe, rpm-based only) in Plesk 10 PHP sessions cleanup was not working properly. This was fixed in Plesk 11 (a proper periodic cleanup task was added). Therefore if you've just upgraded from a lower Plesk version you might notice at times a significant CPU and memory load (provided your sessions directory is clogged up).
Symptoms: 'find' and 'fuser' processes are consuming a lot of CPU time and/or memory.
Solution: is rather straightforward (and relatively painless, if you can afford it). Just purge all your PHP sessions. First you need to find where your sessions are stored. For that find your client php.ini file(s) which are usually in something like /etc/php5/*/php.ini or /etc/php.ini. Than find 'session.save_path' directive there. If you actually have this problem, it most probably will contain either '/var/lib/php/session' or '/var/lib/php5', let's assume this is a value of 'sessionSavePath' shell variable. Then to purge all sessions:
# [ -n "${sessionSavePath}" ] && rm -f ${sessionSavePath}/* || echo "Set sessionSavePath first"
Take care not to remove the directory itself. Also I advice against removing Plesk cleanup task (as somebody else might advice to do), since this will just slow down your server and lead to increased disk space consumption in the long run.
3) sw-collectd data collection interval is too low
In previous Plesk versions sw-collectd data collection interval was not set explicitly. By default it is 10 or 0 (can't remember right now which one), the latter means "collect data as often as you can". This, obviously, usually results in noticeable CPU and other systems' load.
In Plesk 11 (on clean installations, i.e. not upgrades) this interval is set to 300 (5 minutes). However, upgraded installations will have their interval value unchanged. There is a serious reason for that: simply changing interval value in configuration file and restarting sw-collectd may lead to unexpected behavior. E.g. on my test installation just increasing this value led to rrdtool showing only either zero or NaN values.
Symptoms: sw-collectd process consumes a lot of CPU time and/or other resources.
Solution: properly set data collection interval to some reasonably high value. E.g. 300 seconds. I'm not entirely sure (so don't quote me on this), but I doubt setting it to lower value brings any benefits now, since Health monitor module rereads resource usage values at this rate. Note that to safely increase the interval you must drop entire previous statistics.
1. # /etc/init.d/sw-collectd stop
2. Edit file /etc/sw-collectd/collectd.conf to include 'Interval 300' line at top level. Replace '300' with your desired interval in seconds. E.g. (relevant chunk of file, just to give you a context):
3. Notice the BaseDir and Hostname directives in the configuration file. From them a path to the statistics storage is assembled. You have to remove any collected data:
# rm -rf /usr/local/psa/var/health/data/localhost/*
4. # /etc/init.d/sw-collectd restart
Also, there is a KB for increasing the interval value here, even two, to be precise. They are both wrong, however.
That's it for now. If I find other common reasons, I'll update the thread.
If you try any of the solutions, please post whether it helped you or not. If not, post exact symptoms. Maybe somebody will be able to help you.
