pcp
[Top] [All Lists]

Re: [pcp] multithreading bottleneck: pdubuf.c

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] multithreading bottleneck: pdubuf.c
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Sun, 1 Mar 2015 22:00:17 -0500
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <46379696.17899816.1425264329137.JavaMail.zimbra@xxxxxxxxxx>
References: <20150302015436.GB21203@xxxxxxxxxx> <46379696.17899816.1425264329137.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi -

> > [...] a busy pmwebd shows a ginormous amount of
> > traffic flowing through libpcp/src/pdubuf.c, many hundreds of
> > thousands of requests per second.
> 
> The analysis lacks details as to whether this is a calling issue -
> "hundreds of thousands of requests per second" is an obscene rate
> of calls for any normal PCP application to be making [...]

Sorry for leaving this out: it's a routine use of graphite
interface-triggered batch archive processing: N threads scanning a
segment of one possibly-unique archive each.  They fight over the
PDUbuf list, because there is only one, it is not very efficient, and
it is used a lot (every pmResult being read).

This is not specific to pmwebd/graphite at all.  Count the runtime
hits to __pm{Find,Pin,Unpin}PDUBuf in any pmlog*-processing tool;
parallelizing it can't go much faster due to the same congestion.


- FChE

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