pcp
[Top] [All Lists]

Re: [pcp] pmcd gives up on slow starting Perl PMDA

To: Martins Innus <minnus@xxxxxxxxxxx>, Nathan Scott <nathans@xxxxxxxxxx>, PCP <pcp@xxxxxxxxxxx>
Subject: Re: [pcp] pmcd gives up on slow starting Perl PMDA
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Tue, 25 Mar 2014 07:00:06 +1100
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53303242.5020605@xxxxxxxxxxx>
References: <532C975F.4020808@xxxxxxxxxxx> <532F56BC.9040500@xxxxxxxxxxxxxxxx> <146115274.4201680.1395623527453.JavaMail.zimbra@xxxxxxxxxx> <53300840.1070009@xxxxxxxxxxxxxxxx> <53303242.5020605@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
On 25/03/14 00:25, Martins Innus wrote:
...
We have proc pmdas that are timing out on heavily loaded systems, my
next task was going to be looking into this.  Should I wait until this
new api/method is fleshed out before doing so?

Waiting would be good ... 8^)>

In the interim, you have a sledge hammer that can be used.

The timeout in pmcd is configurable ... both at pmcd start up (via -t <n>, usually using /etc/pcp/pmcd/pmcd.options) and dynamically (via pmstore pmcd.control.timeout <n>) ... see the -t option in pmcd(1).

The down-side of making this bigger than the default 5 (seconds) is that you'll wait longer for a really dead PMDA to be noticed, and the semantics of the data returned in a pmResult may be a little fuzzy ... if the requested metrics span more than one PMDA they all come back with a single timestamp, but the data may have been collected several seconds apart from the different PMDAs (comparing a fast PMDA to a slow PMDA)

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