dosprn Posted October 17 Author Share Posted October 17 Thanks for the recommendation. I would like to add that when contacting the server, in addition to checking the version, the current software status is also stored, which is very useful both for future user support requests and for calculating my statistics. If I get rid of this functionality, it will make support more difficult. I also want to note that the total number of these requests never exceeds 3,000 per day, which does not seem to be a significant overload. Interestingly, from the graph, after I completely disabled access to the service domains, the CPU load dropped to 0 instantly, but the RAM stayed at 100% for another 3 hours and only then dropped to 0. So it doesn't seem connected directly. Link to comment Share on other sites More sharing options...
Krydos Posted October 17 Share Posted October 17 If you're talking about this section of the graph There were 3124 PHP processes recorded during that time period. Here are a few of them | alexgoldberg | 0.00 | 34524 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:52:17 | | alexgoldberg | 0.00 | 34004 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/version.dosprn.com/etc/php.ini | 2024-10-16 17:52:54 | | alexgoldberg | 0.00 | 34524 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:52:55 | | alexgoldberg | 0.00 | 34004 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/version.dosprn.com/etc/php.ini | 2024-10-16 17:53:34 | | alexgoldberg | 0.00 | 34524 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:53:35 | | alexgoldberg | 0.00 | 34004 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/version.dosprn.com/etc/php.ini | 2024-10-16 17:54:09 | | alexgoldberg | 0.00 | 34524 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:54:22 | | alexgoldberg | 0.00 | 30804 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/version.dosprn.com/etc/php.ini | 2024-10-16 17:55:13 | | alexgoldberg | 0.00 | 31324 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:55:14 | | alexgoldberg | 0.00 | 30804 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/version.dosprn.com/etc/php.ini | 2024-10-16 17:56:11 | | alexgoldberg | 0.00 | 31324 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:56:13 | | alexgoldberg | 0.00 | 30804 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/version.dosprn.com/etc/php.ini | 2024-10-16 17:56:48 | | alexgoldberg | 0.00 | 31324 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:56:49 | | alexgoldberg | 0.00 | 30804 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/version.dosprn.com/etc/php.ini | 2024-10-16 17:57:16 | | alexgoldberg | 0.00 | 31324 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:57:18 | | alexgoldberg | 0.00 | 22612 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/version.dosprn.com/etc/php.ini | 2024-10-16 17:57:49 | | alexgoldberg | 0.00 | 22876 | /opt/plesk/php/8.0/bin/php-cgi -c /home/system/check.dosprn.com/etc/php.ini | 2024-10-16 17:57:50 | 10 hours ago, dosprn said: So it doesn't seem connected directly. We don't just make up these numbers randomly. The CPU in the second column is indeed 0, but the processes were still running and taking up memory. Are you sure your processes exit correctly? If they lock up and never exit you would see something like this. Link to comment Share on other sites More sharing options...
Krydos Posted October 17 Share Posted October 17 11 hours ago, dosprn said: Interestingly, from the graph, after I completely disabled access to the service domains, the CPU load dropped to 0 instantly, but the RAM stayed at 100% for another 3 hours and only then dropped to 0. So it doesn't seem connected directly. Maybe the confusion here is what you mean by "completely disabled access to the service domains". If you do something like this <?php echo "Go away!"; It's still going to load the PHP script and use some memory, but since the script is so simple it will use very little CPU. If you do something like this in .htaccess Deny from all Then the PHP script won't even load at all and there will truly be zero load. Link to comment Share on other sites More sharing options...
dosprn Posted October 18 Author Share Posted October 18 Thank you. I disabled access with a Deny from all Now I suspect that finished PHP processes remain in memory for a very long time. Otherwise, I can't explain how the RAM continues to hold when CPU=0 for 3 hours. Link to comment Share on other sites More sharing options...
dosprn Posted October 18 Author Share Posted October 18 Today, the problem is reoccurring. I noticed that the RAM overload reached 100% and disabled access to all scripts using "Deny from all". Left access only to static html. After that, the CPU load dropped to 0. But the RAM remains loaded at 80% for 7 hours. Link to comment Share on other sites More sharing options...
wolstech Posted October 19 Share Posted October 19 This should be resolved. The load monitoring wasn't broken, but the server wasn't cleaning up PHP processes properly. They were hanging and being left stuck in memory, causing them to pile up and waste memory. The load monitor itself was fine, and was accurately reflecting the memory wasted by the stuck processes. Your account's issue was what finally helped us identify the problem. Please let us know if this continues now that the issue with the server is resolved. Link to comment Share on other sites More sharing options...
Krydos Posted October 19 Share Posted October 19 18 hours ago, dosprn said: I suspect that finished PHP processes remain in memory for a very long time. Yep, one of your PHP processes was running for over 22 hours. Thanks for helping us figure out what was wrong. Link to comment Share on other sites More sharing options...
dosprn Posted October 19 Author Share Posted October 19 Thank you very much for your support. I'll try to enable my services again and monitor RAM load level. 1 Link to comment Share on other sites More sharing options...
Recommended Posts