All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Heflin" <rheflin@atipa.com>
To: "'Dan Stromberg'" <strombrg@dcs.nac.uci.edu>
Cc: "'M. Todd Smith'" <todd@sohovfx.com>, <nfs@lists.sourceforge.net>
Subject: RE: NFS tuning - high performance throughput.
Date: Wed, 15 Jun 2005 14:52:10 -0500	[thread overview]
Message-ID: <EXCHG2003QtpfTYSl1q000005f2@EXCHG2003.microtech-ks.com> (raw)
In-Reply-To: <1118862823.22484.13.camel@seki.nac.uci.edu>


The mount/remount (unless you time how long it takes to unmount),
will potentially still skew the write test, and the writes
will still be happening for quite a while after the dd completes.
 
                        Roger 

> -----Original Message-----
> From: Dan Stromberg [mailto:strombrg@dcs.nac.uci.edu] 
> Sent: Wednesday, June 15, 2005 2:14 PM
> To: Roger Heflin
> Cc: 'M. Todd Smith'; nfs@lists.sourceforge.net; 
> strombrg@dcs.nac.uci.edu
> Subject: RE: [NFS] NFS tuning - high performance throughput.
> 
> 
> A bigger dd test should work - if you use about 3x your 
> physical memory, you'll probably be fine doing it that way.
> 
> Another way that may work better in -some- cases, is to 
> umount the filesystem and re-mount it - except for warm 
> restartable filesystems.
> 
> On Wed, 2005-06-15 at 10:28 -0500, Roger Heflin wrote:
> > Make the dd test bigger, with 2x the memory size, 50% will be from 
> > cache and almost instanteous, with 4x the memory size, 25% will be 
> > from cache, bigger runs will get closer to actual reality, on the 
> > tests I do I run things 8x, but if you run 2x, 4x, 8x memory you 
> > should get a decent graph to give you an idea of what the 
> actual value 
> > is.
> > 
> >                Roger
> > 		   Atipa Technologies. 
> > 
> > > -----Original Message-----
> > > From: nfs-admin@lists.sourceforge.net 
> > > [mailto:nfs-admin@lists.sourceforge.net] On Behalf Of M. 
> Todd Smith
> > > Sent: Wednesday, June 15, 2005 9:47 AM
> > > To: nfs@lists.sourceforge.net
> > > Subject: Re: [NFS] NFS tuning - high performance throughput.
> > > 
> > > Roger Heflin wrote:
> > > 
> > > >Are you using the same dd test on the local machine test?  
> > > If so cache
> > > >will be a major factor.
> > > >
> > > >Also, raid5 stripe size, bigger is almost always better, 
> I would do 
> > > >some testing with different strip sizes and see how it 
> affects the 
> > > >speed, I have never seen less than 32k be faster than 32k.
> > > >
> > > >Are you using md for the raid5 setup or something else 
> that has not 
> > > >been mentioned?
> > > >
> > > >                     Roger
> > > >  
> > > >
> > > Roger,
> > > 
> > > I was told by a consultant we hired to help us with this that 5Gb 
> > > test files should be large enough to blow out the caches.
> > >  Looking back I realize that must have been when we only 
> had 2Gb RAM 
> > > in the machine ..
> > > is there a better test I can use to check local rw 
> performance, as 
> > > well is there a formula or recommended way to calculate how big a 
> > > file you should rw to properly check local rw?
> > > 
> > > I'll have to ask our soft eng who worked with the 
> consultant as to 
> > > why that particular stripe size was used.  I believe we are using 
> > > md, we attempted to use LVM but ran into some problems 
> and had some 
> > > file inconsistencies that were unacceptable so had to back out of 
> > > it.
> > > 
> > > Cheers
> > > Todd
> > > 
> > > --
> > > Systems Administrator
> > > ----------------------------------
> > > Soho VFX - Visual Effects Studio
> > > 99 Atlantic Avenue, Suite 303
> > > Toronto, Ontario, M6K 3J8
> > > (416) 516-7863
> > > http://www.sohovfx.com
> > > ----------------------------------
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration 
> > > Strategies from IBM. Find simple to follow Roadmaps, 
> straightforward 
> > > articles, informative Webcasts and more! Get everything 
> you need to 
> > > get up to speed, fast.
> > > http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > > _______________________________________________
> > > NFS maillist  -  NFS@lists.sourceforge.net 
> > > https://lists.sourceforge.net/lists/listinfo/nfs
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration 
> Strategies 
> > from IBM. Find simple to follow Roadmaps, straightforward articles, 
> > informative Webcasts and more! Get everything you need to get up to 
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > NFS maillist  -  NFS@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/nfs
> > 
> 



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-06-15 19:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050610031144.4B9CA12F8C@sc8-sf-spam2.sourceforge.net>
2005-06-14 20:17 ` NFS tuning - high performance throughput M. Todd Smith
2005-06-14 20:41   ` Bill Rugolsky Jr.
2005-06-14 22:49     ` M. Todd Smith
2005-06-15 13:03       ` Roger Heflin
2005-06-15 14:47         ` M. Todd Smith
2005-06-15 15:28           ` Roger Heflin
2005-06-15 19:13             ` Dan Stromberg
2005-06-15 19:52               ` Roger Heflin [this message]
2005-06-15 20:11                 ` Dan Stromberg
2005-06-15 20:31                   ` Roger Heflin
2005-06-15 20:33                   ` Chris Penney
2005-06-15 17:47       ` Bill Rugolsky Jr.
2005-06-15 20:33         ` M. Todd Smith
2005-06-15 22:43           ` Bill Rugolsky Jr.
2005-06-15 22:47         ` Greg Banks
2005-06-14 20:50   ` Bill Rugolsky Jr.
2005-06-14 21:04   ` Chris Penney
2005-06-14 21:06     ` Chris Penney
2005-06-14 21:11   ` Roger Heflin
     [not found] <482A3FA0050D21419C269D13989C611308539C89@lavender-fe.eng.netapp.com>
2005-06-14 20:38 ` M. Todd Smith
2005-06-15  1:56   ` Dan Stromberg
2005-06-14 20:40 Lever, Charles

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=EXCHG2003QtpfTYSl1q000005f2@EXCHG2003.microtech-ks.com \
    --to=rheflin@atipa.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=strombrg@dcs.nac.uci.edu \
    --cc=todd@sohovfx.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.