dosprn Posted Thursday at 07:03 AM Author Share Posted Thursday at 07:03 AM 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. Quote Link to comment Share on other sites More sharing options...
Krydos Posted Thursday at 04:47 PM Share Posted Thursday at 04:47 PM 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. Quote Link to comment Share on other sites More sharing options...
Krydos Posted Thursday at 06:30 PM Share Posted Thursday at 06:30 PM 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. Quote Link to comment Share on other sites More sharing options...
dosprn Posted Friday at 09:39 AM Author Share Posted Friday at 09:39 AM 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. Quote Link to comment Share on other sites More sharing options...
dosprn Posted Friday at 08:41 PM Author Share Posted Friday at 08:41 PM 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. Quote Link to comment Share on other sites More sharing options...
wolstech Posted Saturday at 02:44 AM Share Posted Saturday at 02:44 AM 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. Quote Link to comment Share on other sites More sharing options...
Krydos Posted Saturday at 03:51 AM Share Posted Saturday at 03:51 AM 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. Quote Link to comment Share on other sites More sharing options...
dosprn Posted Saturday at 09:59 AM Author Share Posted Saturday at 09:59 AM Thank you very much for your support. I'll try to enable my services again and monitor RAM load level. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.