This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm that you accept these cookies being set.

Exactly what does CPU/IO measure, and how can you lower it?
#1
Hi!

I have a two-fold question...

My setup: Wiser for KNX (HW 3) with firmware 3.0.0. Memory = 18%, Disk = 36%, KNX/TP load <2%. Appx 3500 objects (group addresses).
I do NOT use any of Touch 3, Cloud Connector, KNX IoT 3rd party API or any other app except "System load" and "Processes".
Instead I have created custom visualizations using .lp-files exclusively (I love the .lp format!).

Q1) Exactly what does the "CPU/IO" field in the bottom of the screen in Wiser for KNX / Configurator measure?
Is it a combination of CPU (processor) load and input/output (read/write) to the micro-sd/RAM memory?

I have spent the last couple of days trying to hunt down the source of recurring spikes when the value of CPU/IO jumps up from its idling level at about 0.02 to roughly 0.5 or sometimes even >1.0. It can stay at >0.3 for over 15-30 minutes and there seems to be no apparent pattern to when this happens (I have made a 5-minute Trend to monitor the first of the three CPU/IO values).
After installing the "sysload.ipk" found in another thread in this forum, it seems the total CPU load can be very low during these spikes - about 1-3% (including System) while at the same time the "CPU/IO" can hover around 0.3-0.5 for several minutes.

-------------------

Q2) What are the most likely candidates to look for when trying to lower the CPU/IO?

For example, how efficient would it be to enforce these changes?

A) using grp.checkupdate() rather than grp.update()
B) avoid scheduling scripts to run at the exact same time
C) refactoring large user libraries, and break large files down into many smaller files
D) avoid 5-minute trends
E) avoid using more than ??? trends in total (any upper limit?)

-----------------------

Bottom line: should I take actions to troubleshoot when the CPU/IO goes >0.7 (the recommended limit in the manual) if it does so occasionally 4-5 times a day for 1-30 minutes at the time?

Sincerely,
Robert K
Reply
#2
Occasional load average spikes are nothing to worry about. If you constantly have load over 0.7 then something can probably be optimized.
SD card writes do not happen often to preserve the card's lifespan. The usual sync interval is 30 minutes.

A) using grp.checkupdate() rather than grp.update()
This can be helpful for many updates and when KNX/IP Routing is used. But this mostly applies to grp.write() because KNX/TP bus can be easily overloaded.

B) avoid scheduling scripts to run at the exact same time
Only if scripts are doing some heavy computations.

C) refactoring large user libraries, and break large files down into many smaller files
Does not affect the system load much.

D) avoid 5-minute trends
Does not affect the system load much.

E) avoid using more than ??? trends in total (any upper limit?)
The more trends you have the more calculations have to be done on the data. This happens once every minute.
Reply


Forum Jump: