On 2018/09/04 16:11, Landry Breuil wrote: > On Tue, Sep 04, 2018 at 03:27:29PM +0200, Solene Rapenne wrote: > > Stuart Henderson <s...@spacehopper.org> wrote: > > > On 2018/09/04 14:22, Solene Rapenne wrote: > > > > About munin I'm trying to get a diff accepted upstream to fix cpu > > > > plugin and > > > > talk about this with kirby@. The cpu plugin uses sysctl kern.cp_time. > > > > While > > > > it's not related, I prefer to announce it here so people don't waste > > > > time > > > > fixing it again by looking at the thread :) > > > > > > Ah nice. When I worked on the initial munin port with mk I had intended > > > to try to get upstream to take the openbsd plugins separately (rather > > > than the current "copy similar OS and patch" approach), but I got fed up > > > with rrdtool performance on OpenBSD and stopped using munin before I got > > > round to it.. (and then I started using librenms and got fed up with > > > rrdtool performance once again ;) > > > > Using rrdcached the performances are really good. But that certainly depend > > on > > the number of systems. It may not scale well with more than 50 systems, > > this is > > also highly dependent on the number of plugins on each systems (as 1 value > > = 1 > > rrd file). > > Seconded, rrdcached really helps a lot until you have waaayyy too many rrds, > and then switch to a real tsdb
While other time-series DBs may perform better than rrdtool, the amount of spin (kernel lock contention) seen with this relatively simple software suggests it might be a worthwhile starting point to investigate what's going on kernel-side. > (hint: influxdb is in ports) (as is prometheus. no graphite, though ;)
