Are many Log entries affecting performance of RasPI?

(Selter) #1

Hi there,

I’m running openHAB2.4 on RasPI3b with SSD.
I’m wondering if a flood of log entries could affect the performance.

The CPU and memory usage are on average though …

E.g. every minute there are several astro updates

Astro_PositionAzimuth changed from 102.19980629923973 ° to 102.41995791303972 °
Astro_PositionElevation changed from 32.78464782827473 ° to 32.931823959819184 °
astro_sun_a__position_elevation changed from 32.78464782827473 to 32.931823959819184
Astro_PositionShadeLength changed from 1.55 to 1.54
Astro_RadiationDirect changed from 281.566804743729 W/m² to 283.74265926173047 W/m²
Astro_RadiationDiffuse changed from 113.07775683161016 W/m² to 113.21853127093306 W/m²
Astro_RadiationTotal changed from 394.64456157533914 W/m² to 396.9611905326635 W/m²
astro_moon_phaseillumination changed from 91.74420120932855 to 91.74858375338574
astro_moon_distancedate changed from 2019-05-16T09:20:11.976+0200 to 2019-05-16T09:21:11.972+0200
astro_moon_positionelevation changed from -35.89260702816445 to -35.981704128723216
CPU_Uptime changed from 8442.5 to 8443.5

Most of them I don’t need - so should I remove these items?
A side effect would be a cleaner log viewer output :wink:

0 Likes

(Jürgen Baginski) #2

Using the “Interval” you could decrease the amount of log entries for he astro binding! The SystemInfo has a similar feature!

However, if you do not need those items, why did you create/link them in the first place? You might not notice the load amount they are producing, but…

0 Likes

(Selter) #3

Just out of curiosity :wink:

If I set the value to interval=600 (10 minutes) - it doesn’t mean that e.g. astro based rules are affected/delayed?

0 Likes

(Jürgen Baginski) #4

That depends on your use cases. If you are using any of the positional data channel and you do require the correct data every Minute, your are affected. IMHO the events are calculated once a day only, in other words they are running on time.

1 Like

(Rossko57) #5

It’ll be writing to file(s) which is a slow operation in computer terms.

In this case, these are also running across the internal event bus. This will have some impact on all aspects of openHAB.

It’s also possible to deploy persistence without a lot of thought, and each event would generate db writes to disk as well. Likely a bigger but less obvious impact than logging.

2 Likes

(Markus Storm) #6

No. Not in a relevant order of magnitude.

Then why did you put them in ?
I’d remove them for sake of cleaner config.

1 Like

(Guenther Schreiner) #7

If you like to stay with verbose logging, I suggest to place them at least into a separated logfile - not affecting the local sdcard-filesystem i.e. within /tmp with activated tmpfs.

0 Likes

(Selter) #8

My system runs on SSD.
Would you advise it anyway?

0 Likes

(Guenther Schreiner) #9

Personally I had put most of the logging on the PIs onto special (size-limited) tmpfs locations and this decreased the average system load: you’ll win performance - but you might loose history.

0 Likes

(David Graeff) #10

I have redirected logs to systemd’s journald on my raspberry. The reason is that journald stores logs in a compressed binary format and OH logs can be very ehm… verbose. Also turn of the events log, super unnecessary. Install a persistence service if you need event history instead.

I also redirected journald logs to a tmpfs. I access them via Cockpit and a webbrowser.

1 Like

(Rich Koshak) #11

I’ll second most of the advice given here.

  • If you don’t use them remove them. You should endeavor to have a clean and complete config without extra unused stuff hanging around.

  • The amount of resources used by this logging could affect performance, but not enough to be noticeable or IMHO doing anything about. Remember, your time has as much if not more value than the computer’s time. Don’t spend time optimizing something unless that will save you time or money in the relatively short term. The amount of effort necessary to learn and apply optimizations just don’t have a good return on investment, all other things being equal.

  • Logging is there for a reason. It’s there so when something goes wrong you can go back in time and see what was going on around the time that the error occurred. Or it gives you a way to monitor what OH is doing right now which can be useful for testing and debugging. If you don’t use this stuff then turn it off. But realize that when you do run into trouble one of the first things we will ask for are logs.

1 Like