| To: | Nathan Scott <nathans@xxxxxxxxxx>, Paul Smith <psmith@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] pmchart + Some Archives == Sloooooow |
| From: | Ken McDonell <kenj@xxxxxxxxxxxxxxxx> |
| Date: | Thu, 08 Jan 2015 06:53:02 +1100 |
| Cc: | pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <1906716033.3900927.1420497107290.JavaMail.zimbra@xxxxxxxxxx> |
| References: | <FD870D29-6FC1-4511-B2CE-5F85B4AA105E@xxxxxxxxxx> <1906716033.3900927.1420497107290.JavaMail.zimbra@xxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 |
On 06/01/15 09:31, Nathan Scott wrote: Should be enough info here already - Ken, I think the root cause here is using log-once for discrete metrics like hinv.ncpu and then using time windows which exclude that log-once sample. We end up scanning the window for a value for the discrete metric IIRC... any way we could make libpcp peek outside the time window for this case? (not going to be easy, I suspect) Or any alternate way we could tackle this one? Perhaps put a cap on the scan & returning novalues sooner than a full time window scan would? Analysis looks robust.Proper Fix (tm) is not that difficult. For discrete metrics (we know the semantics) need to extend the search to the beginning of the archive (past the -S time) to try and find the lower (in time) bound ... this would be attempted at most once as per the existing logic. I'm a bit time challenged at the moment, so don't expect a commit too soon. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | pcp updates: build, pmdaroot, Nathan Scott |
|---|---|
| Next by Date: | Re: [pcp] Presenting at FOSDEM and DevConf.cz (and LCA), Nathan Scott |
| Previous by Thread: | Re: [pcp] pmchart + Some Archives == Sloooooow, Nathan Scott |
| Next by Thread: | Re: [pcp] pmchart + Some Archives == Sloooooow, Ken McDonell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |