Hi Bernard,
Thanks for the reply, the servers' time are synced with NTP, so probably NTP
wouldn't be the problem.
Rick, in my environment, I have only one gmetad collecting data all from
gmond, so the problem is not the case you described, thanks :)
Jesse, your point might be helpful, because this error starts since last
week, it was ok before that.
Let me see if reducing the server load could solve this problem, thanks!
Thanks again :)
regards,
Mason Hsiung
2011/4/9 Rick Cobb <rick_c...@ieee.org>
> You can also get this behavior by having two gmetad data sources where
> the gmond.conf's have the same cluster name.
>
> E.g., if you have data source A and data source B, but the hosts in
> those data sources think they're in cluster 'Uck', you'll get this
> every time you try to update summaries, because the filename
> organization is based on the cluster names, not the data sources.
> You'll also only see one cluster in the web view.
>
> In that case, gmetad really is creating bogus summary info rrdupdates,
> since it's acting like there's only one cluster (the file name and all
> the presentation logic is based on the cluster name reported by
> gmond), but there are two threads trying to summarize data (and
> they're not agreeing, either, but that's just another symptom of this
> misconfiguration).
>
> Note that it only takes two hosts having this wrong -- as long as
> they're the ones aggregating the data and being sampled by gmetad --
> to cause the problem.
>
> I've done this intentionally (because of multicast routing problems),
> but it was a complete cluster Uck :/
>
> Don't do it --
> -- ReC
>
> On Fri, Apr 8, 2011 at 11:19 AM, Jesse Becker <haw...@gmail.com> wrote:
> > I've seen this on my servers, and I know that the clocks are all
> > correct for them. That said, it's usually transient. It may also be
> > caused by server load as well. For example, if the host running
> > gmetad is very busy, it may not get around to running several updates
> > for a while, then try to do them "all at once." (at least, that's my
> > theory, I don't have proof though).
> >
> > On Fri, Apr 8, 2011 at 14:12, Bernard Li <bern...@vanhpc.org> wrote:
> >> Hi Mason:
> >>
> >> Are all your servers' time synced via ntpd? Sounds more like there is
> >> time mismatch between your servers to me.
> >>
> >> Cheers,
> >>
> >> Bernard
> >>
> >> On Fri, Apr 8, 2011 at 11:07 AM, Mason Hsiung <yangwing...@gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>> I'm using ganglia 3.1.7 and currently encountering RRD_update error.
> >>> --
> >>> Apr 8 18:03:43 my_host /usr/sbin/gmetad[9553]: RRD_update
> >>> (/var/lib/ganglia/rrds/ABC/__SummaryInfo__/xxxxxx.rrd):
> >>> /var/lib/ganglia/rrds/ABC/__SummaryInfo__/xxxxxx.rrd: illegal attempt
> >>> to update using time 1302285820 when last update time is 1302285821
> >>> (minimum one second step)
> >>> --
> >>> So I google for a while, then I found there is a guy who did a little
> >>> modification in the source code to solve this error.
> >>>
> >>> Add "break;" statement into "process_xml.c", It looks like below.
> >>> --
> >>> static void
> >>> end (void *data, const char *el)
> >>> {
> >>> struct xml_tag *xt;
> >>> int rc;
> >>>
> >>> if(! (xt = in_xml_list((char*) el, strlen(el))) )
> >>> return;
> >>>
> >>> switch ( xt->tag )
> >>> {
> >>> case GRID_TAG:
> >>> rc = endElement_GRID(data, el);
> >>> break; <-- this one
> >>> /* No break. */
> >>>
> >>> case CLUSTER_TAG:
> >>> rc = endElement_CLUSTER(data, el);
> >>> break;
> >>>
> >>> default:
> >>> break;
> >>> }
> >>> return;
> >>> }
> >>> --
> >>>
> >>> I would like to know, is "/* No break */" a warning message that tells
> >>> us *don't put break here* or just a comment to remind someone "hey you
> >>> forgot to put break here"?
> >>>
> >>> I would like to try this, if someone could tell me this is a correct
> >>> change and won't be any impact to the functionalities.
> >>>
> >>> Thanks a lot :)
> >>>
> >>> regards,
> >>> Mason Hsiung
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Xperia(TM) PLAY
> >>> It's a major breakthrough. An authentic gaming
> >>> smartphone on the nation's most reliable network.
> >>> And it wants your games.
> >>> http://p.sf.net/sfu/verizon-sfdev
> >>> _______________________________________________
> >>> Ganglia-general mailing list
> >>> Ganglia-general@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/ganglia-general
> >>>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Xperia(TM) PLAY
> >> It's a major breakthrough. An authentic gaming
> >> smartphone on the nation's most reliable network.
> >> And it wants your games.
> >> http://p.sf.net/sfu/verizon-sfdev
> >> _______________________________________________
> >> Ganglia-general mailing list
> >> Ganglia-general@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/ganglia-general
> >>
> >
> >
> >
> > --
> > Jesse Becker
> >
> >
> ------------------------------------------------------------------------------
> > Xperia(TM) PLAY
> > It's a major breakthrough. An authentic gaming
> > smartphone on the nation's most reliable network.
> > And it wants your games.
> > http://p.sf.net/sfu/verizon-sfdev
> > _______________________________________________
> > Ganglia-general mailing list
> > Ganglia-general@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ganglia-general
> >
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Ganglia-general mailing list
> Ganglia-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
