Re: bdflush/rpciod high CPU utilization, profile does not make sense

Trond Myklebust
2005-04-11T12:35:58Z

må den 11.04.2005 Klokka 09:48 (+0200) skreiv Jakob Oestergaard:

> tcp with timeo=600 causes retransmits (as seen with nfsstat) to drop to
> zero.

Good.

> File Block Num Seq Read Rand Read Seq Write Rand Write
> Dir Size Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
> ------- ------ ------- --- ----------- ----------- ----------- -----------
> . 2000 4096 1 60.50 67.6% 30.12 14.4% 22.54 30.1% 7.075 27.8%
> . 2000 4096 2 59.87 69.0% 34.34 19.0% 24.09 35.2% 7.805 30.0%
> . 2000 4096 4 62.27 69.8% 44.87 29.9% 23.07 34.3% 8.239 30.9%
>
> So, reads start off better, it seems, but writes are still half speed of
> 2.4.25.
>
> I should say that it is common to see a single rpciod thread hogging
> 100% CPU for 20-30 seconds - that looks suspicious to me, other than
> that, I can't really point my finger at anything in this setup.

That certainly shouldn't be the case (and isn't on any of my setups). Is
the behaviour identical same on both the PIII and the Opteron systems?

As for the WRITE rates, could you send me a short tcpdump from the
"sequential write" section of the above test? Just use "tcpdump -s 90000
-w binary.dmp" just for a couple of seconds. I'd like to check the
latencies, and just check that you are indeed sending unstable writes
with not too many commit or getattr calls.

Cheers
Trond
--
Trond Myklebust <trond.myklebust@fys.uio.no>