High CPU usage with Admin access and number of cores wrongly reported

Sorry, it looks like I had missed the settings page ??

I found it and raised the realtime script refresh interval to 1500ms and that resolved the high CPU usage issues (it’s back to 1-2% when nothing happens). 1000ms cut the load by half but the iddle time was still at 80%. 1500ms brought the iddle time back to 100%, as when the plugin is disabled.

So I guess it’s just the cosmetic issue of the odd number of cores that remains ??

• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.

Nope, that was only temporary. Even with 5,000ms, the load is still much higher than when the plugin is disabled. I guess I’ll keep it disabled most of the time, and will enable it with the default 200ms when I actually need it.

Hi,
the plugin doesn’t cause any high CPU usage. All it does is run some unix commands to get the data from the server and show that. It doesn’t do anything beside that. Now the refresh rate decides how often the plugin will call the server to get the new data.

The admin panel itself is very resource intensive as too many things are happening there. But the plugin has no code that can use high CPU usage beside request updatation of the data. But as you said you have already increased the interval. So, I don’t see any other thing the plugin can do to increase the CPU load – unless the WP admin itself is increasing the CPU load and it looks like the plugin is doing it.

Hi Sauma,

Thanks for your reply.

I did test with and without the plugin enabled to identify this issue. I have no excessive CPU load if accessing the admin panel when the plugin is disabled.

I look at the server monitor data on Cloudways, it clearly shows that when the user accesses the admin panel, enabling the plugin uses around 25% CPU power and decreases idle CPU time from 100% to 60% with the 200ms default.

Of course I take into account the fact that there is a delay of about 5-8 minutes in the user monitoring data shown to the user on Cloudways, as the graphs are only updated every five minutes even if you refresh them more often (at least that’s the case for the idle time one). So I leave enough time for each state (plugin enabled or disabled) to register and show.

Raising the interval seemed to help initially, and I realised it was only temporary.

I would need to do more testing looking at the logs to see if I can pinpoint what the plugin does that causes this if you’d like me to. By the way, the higher CPU load happens even if you’re not looking at the dashboard, i.e. if there is no need to refresh the server stats information. Would there be any way to get the plugin to only use CPU time when a refresh is actually needed, i.e. when the admin is looking at the dashboard, or are you showing the information elsewhere? You might be showing it at the bottom of each admin page, in which case it would be great if we could have an option to disable this and only show the server stats when looking at the dashboard.

Of course if I’m the only one experiencing this and if you can’t reproduce looking at your server monitoring, then no need to to anything.

Do you have any idea reagarding the misreporting of the 3-core CPU on the server as a 1-core?

Thanks!

• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.

Would there be any way to get the plugin to only use CPU time when a refresh is actually needed, i.e. when the admin is looking at the dashboard, or are you showing the information elsewhere?

– That won’t be possible as there is no wy to know when you are looking at the dashboard I mean in an asynchronous ajax operation. Also yes the data is shown at the wp admin footer as well.

Of course if I’m the only one experiencing this and if you can’t reproduce looking at your server monitoring, then no need to to anything.

– As I said the plugin uses shell_exec command to run unix commands. That’s all it does. So, not sure why shell_exec is taking so much CPU in your case.

Do you have any idea reagarding the misreporting of the 3-core CPU on the server as a 1-core?

– Cause that’s what the server is reporting to the plugin: /proc/cpuinfo.
This is the UNIX command the plugin use to get the core count: https://i.imgur.com/2ybtf2h.jpeg

So, whatever the server says the plugin shows.

Hi Sauma,

Thanks again for your reply.

So I checked with CLoudways and here is their answer:

1) I got it wrong, I don’t have 3-cores currently, only two. I did test 3-cores/8GB initially but there was no performance gain for our needs, so I went bakc to 2-cores/4GB. Doesn’t change the fact that the reporting is wrong in the plugin, but it’s not because of an odd number of cores on the server as I incorrectly guessed ??

2) They checked with htop and produced a screenshot showing that the server had indeed two cores. I can send you the screenshot if you wish.

3) I gave them the information you kindly provided above, as well as the exact command you use, they did more checks and here is their answer:

You may ask your developer to check like this:
?
? cat /proc/cpuinfo | grep processor
?processor : 0
?processor : 1
?
?Basically, He will see 2 processorts starts with 0 and 1

Does this make sense to you?

I’ll need more time to investigate the CPU load, but I’ll get back to you later on this.

• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.

Can you run this command: https://pastebin.com/pH55HbG0
and see what result you get?

If you mean with SSH, the answer I get is 1

Please read my answer above to your question (it’s 1 if you meant running your command though ssh).

I have done more thorough testing regarding the WP Server Stats interval settings.

I’ve done all the testing in a staging site with the default 2022 theme and all plugins disabled.

The results below are 100% consistent and repeatable as far as the general behaviour is concerned. The actual numbers are averages, they don’t really matter, what matters is the obvious CPU load that the plugin adds to the load reported with the default setting of 200ms, and how much you need to add to make it mostly neutral and actually report the CPU load itself, and not the load added by the plugin itself.

I double checked with the server monitoring, and although there is a strong lag with the server graphs to take into account, there is no doubt that the plugin is reporting the actual CPU Load in real time, so I won’t make a distinction between server monitor and plugin CPU load. Once I established that they always matched, I used the CPU Load reported by the plugin because it’s in real time, except for measuring the baseline.

For the idle time monitoring, I used the server, taking into account the 5-8 min latency between what’s measured and what the graphs report.

I always waited for the reading to stabilise when accessing the dashboard, as it can take 5-10 secs before all the blocks display their data in the production site. It’s much faster on the staging site with no plugin, but it still takes a little while. I didn’t take into account the very occasional larger readings that are probably caused by some internal action.

Here you go:

Baseline with or without Admin Panel access, server monitoring:
WP Server Stats disabled, default 2022 theme, no plugin: CPU Load 0-1% Idle 100%

With Admin Panel Access and WP Server Stats plugin enabled:
WP Server Stat enabled, 200ms (default): CPU Load 10-25% (mostly 16-17%), idle 99-90%
WP Server Stat enabled, 1000ms: CPU Load 1-15% (mostly 10-15%), idle 99-90%
WP Server Stat enabled, 2000ms: CPU Load 1-12%% (mostly 5-10%), idle 99-90%
WP Server Stat enabled, 3000ms: CPU Load 1-6% (mostly 1% or 5%, swaps every reading), idle 100%
WP Server Stat enabled, 3500ms: CPU Load 1-6% (mostly 1%, occasional 5% every 15 secs or so), idle 100%
WP Server Stat enabled, 4000ms: CPU Load 1-6% (mostly 1%, very occasional 5% every 30 secs or so), idle 100%
WP Server Stat enabled, 5000ms: CPU Load 1-6% (mostly 1%, very occasional 5% every 40 secs or so), idle 100%
WP Server Stat enabled, 7500ms: CPU Load 1-6% (mostly 1%, very occasional 5% every 50 secs or so), idle 100%
WP Server Stat enabled, 10000ms: CPU Load 1-3% (mostly 1%, very occasional 3-5% every 60-90 secs or so), idle 100%

So anything from 3000ms gives me my 100% idle time back as per the server monitoring, and at most 6% above the baseline (plugin disabled), though the value reported is often inflated up to 3500ms. Note that the added CPU Load is 16-17% with the default 200ms value (which confirms the 25% I reported when all the other plugins are enabled on the production site).

In the end I settled for 4000ms, which only gives me an inflated reading every 8 readings or so, which I find acceptable as you have to wait 3-5 secs after displaying the dashboard anyway (5-10 secs on the production site) for the readings to stabilise, so I know that once it settles, the CPU Load reported is likely correct for 20-30 secs, and if infladed it won’t be more than 5-6%, instead of 16-17% with the default setting of 200ms.

I would be curious to know if it’s something you can reproduce on your server, and if there is any way to optimise that so that we can get more frequent updates without hammering the server that way.

• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.
• This reply was modified 2 years, 3 months ago by Manni02.

If you mean with SSH, the answer I get is 1

– Yes that’s the command the plugin runs.

I would be curious to know if it’s something you can reproduce on your server, and if there is any way to optimise that so that we can get more frequent updates without hammering the server that way.

– Thanks for the detailed run but honestly looking at the code I don’t see what can be causing that or how it can be resolved. Also that problem is not happening on any server that I am testing. Moreover as I said earlier, all the plugin does is run some unix commands. Nothing more than that.

If you feel that the plugin is adding significant load to your server and you are comfortable looking at the data via SSH, then that is always the best option. Unfortunately, I got no clue of why it is happening.

Hi Saumya,

Thanks, I’m happy to keep the interval at 4000ms, it doesn’t add much load and I get my 100% idle time back, so the plugin is mostly transparent from a performance point of view with that setting.

Regarding the number of cores, where does that leave us?

I don’t understand what the command you’ve asked me to run via ssh does or means.

Currently your plugin returns 1 core, when the number of cores (as confirmed by Cloudways when they ran the hmod command and sent me a screenshot) is 2.

So what do you want me to tell them? I have no idea what their suggestion meant, or what the result to the command you asked me to run means.

Is there a way to fix this and get the plugin to report the correct number of cores?

Or even a way for me to get the info through SSH?

Or do we just drop it?

• This reply was modified 2 years, 3 months ago by Manni02.