• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

High load after plesk 11 update find and fuser

Webroy

Regular Pleskian
After the update of plesk 10 to plesk 11 i see a lot of find and fuser in top.

Is this process hanging in plesk 11 ?

/etc/cron.hourly/plesk-php-cleanuper: find /var/lib/php/session -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/plesk-9.0/maxlifetime) ! -execdir fuser -s {} \; -delete 2> /dev/null

fuser -s ./sess_vhl5jka546prfj7vj1l9s0lsn3

and a lot of find in /var/lib/php/session.

This happend directly after the update from 10.4 to 11.
 
For starters, try

rm -fdr /var/lib/php/session/*

and then

chmod -R 1777 /var/lib/php/session
 
getting this error while executing rm

-bash: /bin/rm: Argument list too long
 
-bash: /bin/rm: Argument list too long

This could help: http://www.simplehelp.net/2009/02/18/linux-tip-overcoming-the-binrm-argument-list-too-long-error/

However, personally whenever I get that error most times its as a result of SeLinux being enabled due to restricted file permissions on the server you can't execute that command...

Solution could be

setenforce 0

and if the above fails, then try disabling SELinux permanently by:

vim /etc/selinux/config
SELINUX=enforcing
 
I've seen this problem on a busy server. Symptoms:

* old files in /var/lib/php/session aren't removed despite this script
* high latency on file operations due to the growing 'session' directory size
* hourly high load average due to many fuser processes

The reason: find 'execdir' appears to have a bug where it doesn't release file handles. It quickly runs into the default maximum of 1024 and the find process quits. So it deletes some files, but not all. In the case I saw, it was deleting them more slowly than they were accumulating.

The solutions... in /etc/cron.hourly/plesk-php-cleanuper, either:

* raise the limit on open files with e.g. "ulimit -n 102400", before the find command. OR

* change "-execdir" to "-exec", which doesn't have this bug (if you have untrusted users on your machine be aware of the security implication of -exec... read the manpage). OR

* remove the section "! -execdir fuser -s {} \;" entirely. It's just checking whether any process has the file open at the moment. This won't - and shouldn't - prevent it from being deleted, and subsequent accesses by httpd will just find that the session has been deleted. perfect. So the complete line would be:
[ -x /usr/lib64/plesk-9.0/maxlifetime ] && [ -d /var/lib/php/session ] && find /var/lib/php/session -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib64/plesk-9.0/maxlifetime) -delete

Be aware that after you make any of these changes, then the first time this script runs and works on a large directory (e.g. 1million+ files), you could bring your server to its knees for some time as it chews over all those delete operations. I wrote a one-off script to remove them gradually in the background before installing the corrected version of plesk-php-cleanuper.
 
I have one stupid question, since i don't have folder /var/lib/php/session, i have /var/lib/php5/sess_XX (XX - name of files), I guest that is same thing right, or?
 
I have one stupid question, since i don't have folder /var/lib/php/session, i have /var/lib/php5/sess_XX (XX - name of files), I guest that is same thing right, or?

Sure, they are also session files, but the script we were talking about from plesk 11 ("plesk-php-cleanuper") is not going to touch them.
 
Back
Top