On Mon, Dec 14, 2009 at 10:28 AM, Carlo Marcelo Arenas Belon <[email protected]> wrote: >> a) you are only concerned with redundancy and not looking for >> scalability - when I say scalability, I refer to the idea of maybe 3 or >> more gmetads running in parallel collecting data from huge numbers of agents > > what is the bottleneck here?, CPUs for polling or IO?, if IO using memory > would be most likely all you really need (specially considering RAM is really > cheap and RRDs are very small), if CPUs then there might be somethings we > can do to help with that, but vertical scalability is what gmetad has, and > for that usually means going to a bigger box if you hit the limit on the > current one.
Ime cpu isnt' really a problem, the big load is I/O and indeed moving the rrds to a ramdisk is the most common solution with pretty decent results. > >> b) you can afford to have duplicate storage - if your storage >> requirements are huge (retaining a lot of historic data or lot's of data >> at short polling intervals), you may not want to duplicate everything > > if you are planning to store a lot of historic data then you should be > using instead some sort of database, not RRDs and so I think this shouldn't > be an issue unless you explode the RRAs and try to abuse the RRDs as a RDBMs I think there's a middle ground here that'd be interesting to explore, altho that's a different thread, but for kicks this is the gist: the common pattern for rrd storage is hour/day/month/year and I've always found it bogus. In many cases I've needed higher resolution (down to the second) for the last 5-20 minutes, then intervals of an hr to a couple hrs, then a day to three days and then a week to 3 weeks etc etc, which increases your storage requirements, but is imho not an abuse of rrd and still retains the many advantages of rrd over having to maintain a RDBMs. > Carlo > > PS. I like the ideas on this thread, don't get me wrong, just that I agree > with Vladimir that gmetad and RRDtool are probably not the sweet spot > (cost wise) for scalability work even if I also agree that the vertical > scalability of gmetad is suboptimal to say the least. sort of. If you're looking at where your resources go to compute and deal with large amount of data, I agree. If you look at what it costs you or if it's even possible to create a fully scalable and resilient ganglia based monitoring infrastructure, I disagree. -- "Behind every great man there's a great backpack" - B. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
