The problem is that memory is currently stored as an uint32, so it overflows at a little over 4TB. Since it is hardcoded, 32- vs. 64-bit doesn't make a difference.
I took a look at the code at one point, but it wasn't as simple as changing it to a uint64, so I took the route of 'fudging' all of the memory values. I ended up dividing the values by 1024, and then adding a hack in the graph so the values are displayed as T instead of M... If you are interested, I can grab my changes on Monday when I am in the office. Chris Slaughter On 9/7/07, Bernard Li <[EMAIL PROTECTED]> wrote: > Hi Jim: > > On 9/7/07, Jim Rowan <[EMAIL PROTECTED]> wrote: > > > We have a cluster with more than 4T of memory. Ganglia (3.0.4) won't > > show that on the graphs, although if you visit the physical view it > > seems to have the correct number. If you restart all the gmonds, the > > summary memory graph looks like a sawtooth; ramping up to 4T and > > dropping suddenly to zero as it wraps around, and ramps up again. > > > > Where is the problem likely to be? > > This bug has already been filed: > > http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=128 > > But no solutions yet... > > Cheers, > > Bernard > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ganglia-general mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ganglia-general > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ganglia-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general
