pcp
[Top] [All Lists]

Re: [pcp] pmclusterd versus other solutions

To: Jeff Hanson <jhanson@xxxxxxx>
Subject: Re: [pcp] pmclusterd versus other solutions
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 5 Sep 2016 19:57:52 -0400 (EDT)
Cc: Mark Goodwin <mgoodwin@xxxxxxxxxx>, PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <49c5d203-5378-5cbb-7092-7ed23035af56@xxxxxxx>
References: <3b551b84-ff74-5b9c-5854-3bdcba1c1212@xxxxxxx> <CAFmffyUkbMi1g3XScEE-XjEHBmdbd5WvHZ6UpGKN_eZtG6pm=g@xxxxxxxxxxxxxx> <49c5d203-5378-5cbb-7092-7ed23035af56@xxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: 5xh/5Gw/EWDMz71XJeTCDtVxW2JgKA==
Thread-topic: pmclusterd versus other solutions
Hi Jeff,

----- Original Message -----
> > This is the daemon that aggregates indoms for per-cluster-node CPU
> > data on the head node, so
> [...]
> See the emails from 11 August on Debugging sigpipe in pmda.
> 
> But the real problem is that although pmclusterd exposes some 100 metrics or
> so but only 20 of them are actually able to be fetched.
> 

I expect the problem will be due to latency in the polling of remote cluster
nodes, which IIRC is done in a serial fashion (one node after the other IOW)
so one slow-reponding node will affect timeliness of all values?

A design which did the remote fetching in parallel would be better suited,
if so.  You could go with a model where multiple processes fetch then write
metrics using MMV(5) format - see also mmv_stats_init(3) - so a new PMDA may
not be needed at all.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>