2013/2/14 Adam Armstrong adama@memetic.org
On Thu, 14 Feb 2013 01:19:20 -0300, Ciro Iriarte cyruspy@gmail.com wrote:
2013/2/14 christopher barry cbarry@rjmetrics.com
Why not RAM? Build a box w/256G or more, and keep them all in tmpfs during operation. (ditch Solaris. It was cool once, but...)
Copy them up into tmpfs on boot, then cron an rsync to disk between polling or even occasionally, depending on pain tolerance.
-C
Hmm, well, I could only steal a machine with 64GB of RAM this time, but
ZFS
- SSD cache + regular spindles sounds cleaner that rsync of 150GB every
2
hours..
Why the SSD cache? Why not just use the SSD.
"SSD disk size" < "rrd directory size" mostly, and I/O to a mid range storage shouldn't hurt either...
Having the filesystem layer dealing with the caching is likely to add even more overhead, you're also relying on the cache to actually cache the things you are accessing.
I can't imagine something with more insight on access pattern than the filesystem... ZFS has a second level "read cache" (L2ARC) and a "write cache" (ZIL, that mostly helps with synchronous writes). I'm not telling that it must make a difference in this case, but I would like to save stats in case I finally add those disks...
Last time I checked, disk svctime was not hi, but system CPU time was, maybe network delay?...
I would first ditch Solaris and see if the performance changes
Right now I don't have spare time to do it all again from scratch, sadly.
How long does it take to run /one/ instance of the poller?
I'll check the logs again in the morning once I get to the office.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Regards,