Hi Matteo, thanks for the reply, my responses below:
Are you still running PHP sessions based on files or e.g. memcached?
- We have a dedicated memached server that we implemented when we built out our gluster farm but we are not using it for sessions. Still files sessions.
Did you notice an high pressure on RAM? What is the memory setting in your PHP_FPM conf and by means of what directive, php_admin_value vs php_value?
- I don't see any spike in memory at the time of the crashes. Just CPU. I'll have to check the conf file for the value...
Is the recent change in usage due to more traffic or e.g. having deployed new plug-ins?
Any other change that happened in the mean time before the increase of such errors?
- We tried running unoconv in September after upgrading to 3.2 in May but there were so many php errors coming through after that and based on forum discussions it seemed as though a lot of others were also having issues with it so we decided not to proceed with it at this time.
- We went full HTTPS in June of this year and installed Content Security Policy to be able to monitor ssl violations but have since disabled it.
- Our actual usage has gone up slightly (number of users and courses on the system) but nothing dramatic.
- Our current linux admin seems to think the php crashes started happening just over a year ago which would have been right after we upgraded from 2.9 to 3.0
- We though it might have something to do with this bug that is still occurring on our current version 3.2x
P.S.: probably time to plan an update of both OS and PHP versions, including accessing PHP via mod_fastcgi w/ some more RAM too
- I should get our linux admin to comment on this. As far as I am aware he updates software regularly. We are currently running php 5.6