19:31:46 #startmeeting 19:31:46 Meeting started Tue Nov 18 19:31:46 2014 UTC. The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:31:46 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:31:49 hi all 19:32:18 #topic 2.1 19:33:19 graph-sql is now mostly able to handle simple plugins, that don't have any cdef. 19:36:37 the biggest time taker is rrd graphing. 19:37:30 ... which is very sane ;-) 19:40:14 rrd is rather I/O intensive, though 19:40:31 could this be solved with a DBMS of sorts? 19:41:45 we're using a VM with storage on a raid-1+0 shelf and it's eating some 200iops constantly (as measured from linux) 19:44:12 royk: no this is solved via rrdcached 19:44:14 are you using rrdcached? it helps. http://oss.oetiker.ch/rrdtool/doc/rrdcached.en.html 19:45:16 http://guide.munin-monitoring.org/en/latest/master/rrdcached.html 19:45:18 TheSnide: imo that's a workaround, not a solution 19:45:43 using a rdms is much worse usually. 19:45:49 for timeseries. 19:46:29 does rrd use sync writes? looks like it does... 19:47:59 nope. is uqes posix advises to preload 19:48:05 but sync, no. 19:48:32 it uses flush, when you want to graph something 19:49:38 nah, rrdcached is the best thibg here. but is difficult to install 19:50:21 note that rrd offers a libdbi interface, if you *really* want to use.rdms. 19:51:11 has anyone tried to use a postgresql db for this thing? 19:51:18 munin tried hard to avoid fsync(). 19:52:30 or any other (R)DBMSes? 19:52:41 and no. but i'm highly interested by eventual results. 19:53:10 http://oss.oetiker.ch/rrdtool/doc/rrdgraph_libdbi.en.html is the api. beware that it is quite eye-bleeding. 19:53:11 would an object database be better, such as mongodb? 19:53:36 munin cares about its data. so no mongodb ;-) 19:53:46 * RoyK is not objecting, just asking 19:54:16 what's wrong with mongodb? 19:54:18 was joking. i'd like to try elasticsearch 19:54:33 but for now, i'm focussing on rrd. 19:56:08 royk, it is the php/mysql of nosql. i don't know much about it, but is mich more dev oriented than ops, i'm hearing. 19:56:42 anyway, i don't want to reimplement all the cdef, vdef, ... part of rrd. 19:57:15 I don't touch mysql unless I have to (which I obviously have to during my dayjob) 19:57:46 regrettably 19:58:37 but I may do some testing on postgresql 19:58:55 it's far better on transaction-based databases (and most stuff) than mysql 20:00:26 I guess if munin was rewritten to use a transaction-based model, summing up all data from all sources into a single transaction with postgresql, it could be rather neat and efficient 20:01:56 it does with metadata. 20:02:08 with timz series, not for now. 20:02:37 well, the time series are the main I/O hog 20:04:08 ok. that's all for me. 20:04:44 #endmeeting