Hi Martin,

I'm using unicast reporting in hierarchies, so the largest cluster info
held by a gmond doesn't exceed 2TB. The gmetads performing aggregation
display this problem.

After looking at the code, it seems that gmetad indeed stores the
aggregated information in an unsigned integer (32 bit on an x86_64 Linux).


Cheers,

Alex



Martin Knoblauch wrote:

>Hi Alex,
>
> do the gmond's themselves report the correct size for each host?
>
> Where do you get the problem? In "gmetad", or in the webfrontend?
>Those are separate pieces of software.
>
>Cheers
>Martin
>
>--- Alex Balk <[EMAIL PROTECTED]> wrote:
>
>  
>
>>Hi all,
>>
>>
>>I'm running Ganglia on a grid with thousands of hosts, each with at
>>least 4GB RAM installed.
>>
>>Since aggregating the total amount of RAM exceeds 4294967296 (the max
>>value of uint32), I'm getting incorrect data on the total memory in
>>the
>>grid.
>>
>>
>>I've peeked at gmond and gmetad code and adding a uint64 doesn't seem
>>trivial.
>>
>>I've also searched the Net for anyone that's possibly encountered
>>this
>>before and came up only with this:
>>
>>
>>
>>    
>>
>http://sourceforge.net/mailarchive/forum.php?forum_id=9584&max_rows=25&style=nested&viewmonth=200312
>  
>
>>It mentions that Ganglia 3.x should solve the problem. I'm running
>>3.0.2, but still experiencing it. I've also failed to find any method
>>for changing collection of memory metrics from KB to MB, other than
>>modifying the source code, which I'd rather avoid so as to keep as
>>close
>>to the original tree as possible.
>>
>>
>>My questions are:
>>
>>1. Is there really a solution in Ganglia 3.x and if so, what is it?
>>
>>2. If not, are you aware of anyone who's implemented such a solution
>>or
>>documented the work needed, so I may carry on from there?
>>
>>
>>Note that the gmetad collectors are running on a SuSE x86_64 machine
>>and
>>were compiled with 64bit libs. Ganglia is deployed in a hierarchy and
>>reporting is done via unicast. In essence, this isolates the problem
>>to
>>the gmetads only, as the gmonds report on groups with less than 4TB
>>RAM
>>(but it may definitely surface there someday as well).
>>
>>
>>Thanks,
>>
>>Alex
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc. Do you grep through
>>log files
>>for problems?  Stop!  Download the new AJAX search engine that makes
>>searching your log files as easy as surfing the  web.  DOWNLOAD
>>SPLUNK!
>>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>>_______________________________________________
>>Ganglia-general mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/ganglia-general
>>
>>
>>    
>>
>
>
>------------------------------------------------------
>Martin Knoblauch
>email: k n o b i AT knobisoft DOT de
>www:   http://www.knobisoft.de
>  
>

Reply via email to