dosprn Posted October 17 Author 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.
Krydos Posted October 17 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 | On 10/17/2024 at 7:03 AM, dosprn said: So it doesn't seem connected directly. Expand 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.
Krydos Posted October 17 Posted October 17 On 10/17/2024 at 7:03 AM, 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. Expand 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.
dosprn Posted October 18 Author 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.
dosprn Posted October 18 Author 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.
wolstech Posted October 19 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.
Krydos Posted October 19 Posted October 19 On 10/18/2024 at 9:39 AM, dosprn said: I suspect that finished PHP processes remain in memory for a very long time. Expand Yep, one of your PHP processes was running for over 22 hours. Thanks for helping us figure out what was wrong.
dosprn Posted October 19 Author Posted October 19 Thank you very much for your support. I'll try to enable my services again and monitor RAM load level. 1
Recommended Posts