From: Martin Knoblauch <spamtrap@knobisoft.de>
To: Chris Snook <csnook@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
spam trap <spamtrap@knobisoft.de>
Subject: Re: Strange NFS write performance Linux->Solaris-10/VXFS, maybe VW related
Date: Sat, 29 Dec 2007 03:11:08 -0800 (PST) [thread overview]
Message-ID: <86290.88050.qm@web32604.mail.mud.yahoo.com> (raw)
----- Original Message ----
> From: Chris Snook <csnook@redhat.com>
> To: Martin Knoblauch <spamtrap@knobisoft.de>
> Cc: linux-kernel@vger.kernel.org; linux-nfs@vger.kernel.org
> Sent: Friday, December 28, 2007 7:45:13 PM
> Subject: Re: Strange NFS write performance Linux->Solaris-10/VXFS, maybe VW related
>
> Martin Knoblauch wrote:
> > Hi,
> >
> > currently I am tracking down an "interesting" effect when writing
> 3) It sounds like the bottleneck is the vxfs filesystem. It
> only *appears* on the client side because writes up until dirty_ratio
> get buffered on the client.
> If you can confirm that the server is actually writing stuff to
> disk slower when the client is in writeback mode, then it's possible
> the Linux NFSclient is doing something inefficient in writeback mode.
>
so, is the output of "iostat -d -l1 d111" during two runs. The first run is with 750 MB, the second with 850MB.
// 750MB
$ iostat -d -l 1 md111 2
md111
kps tps serv
22 0 14
0 0 0
0 0 13
29347 468 12
37040 593 17
30938 492 25
30421 491 25
41626 676 16
42913 703 14
39890 647 15
9009 141 7
8963 141 7
5143 81 7
34814 547 10
49323 775 12
28624 451 6
22 1 6
#### finish
0 0 0
0 0 0
Here it seems that the disk is writing for 26-28 seconds with avg. 29 MB/sec. Fine.
// 850MB
$ iostat -d -l 1 md111 2
md111
kps tps serv
0 0 0
11275 180 10
39874 635 14
37403 587 17
24341 392 30
25989 423 26
22464 375 30
21922 361 32
27924 450 26
21507 342 21
9217 153 15
9260 150 15
9544 155 15
9298 150 14
10118 162 11
15505 250 12
27513 448 14
26698 436 15
26144 431 15
25201 412 14
#### 38 seconds in run
0 0 0
0 0 0
579 17 12
0 0 0
0 0 0
0 0 0
0 0 0
518 9 16
485 8 6
9 1 7
514 9 7
0 0 0
0 0 0
541 9 8
532 10 6
0 0 0
0 0 0
650 12 7
0 0 0
242 8 9
1023 18 5
304 5 6
418 8 7
283 5 5
303 5 8
527 10 6
0 0 0
0 0 0
0 0 0
5 1 13
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 11
0 0 0
0 0 0
0 0 0
1 0 15
0 0 0
96 2 15
138 3 10
11057 175 6
17549 280 6
351 8 5
0 0 0
##### 218 seconds in run, finish.
So, for the first 38 seconds everything looks similar to the 750 MB case. For the next about 180 seconds most time nothing happens. Averaging 4.1 MB/sec.
Maybe it is time to capture the traffic. What are the best tcpdump parameters for NFS? I always forget :-(
Cheers
Martin
next reply other threads:[~2007-12-29 11:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-29 11:11 Martin Knoblauch [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-01-14 8:01 Strange NFS write performance Linux->Solaris-10/VXFS, maybe VW related Martin Knoblauch
2007-12-29 9:59 Martin Knoblauch
2007-12-28 15:24 Martin Knoblauch
2007-12-28 18:45 ` Chris Snook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86290.88050.qm@web32604.mail.mud.yahoo.com \
--to=spamtrap@knobisoft.de \
--cc=csnook@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox