| 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) |
| Previous by Date: | Re: [pcp] bug in python pmGetArchiveEnd(), Jonathan Lim |
|---|---|
| Next by Date: | pcp updates: qa, long options, python fix, Nathan Scott |
| Previous by Thread: | Re: [pcp] pmcd gives up on slow starting Perl PMDA, Martins Innus |
| Next by Thread: | Re: [pcp] pmcd gives up on slow starting Perl PMDA, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |