Many thanks for all the replies.
>Does anyone know what the effective speed
>performance hit is, when reducing the minfree
>parameter of a file system (using tunefs) to 0%
>from 10%, and then optimizing for space
>rather than time?
>
-----------------------------------------------------------------------
Dear Steve,
I found it to be 30% - I tried to make most out of 4Gb drive and fell
back to 3% - with no noticeable perfomance decrease. Yet the filesystems
on that particular drive are mostly readonly - it is just a big warehouse.
And still - I do full news && 0 level restore every fortnight to
reshuffle minor updates to it.
Trying to do same on frequently && randomly written to filesystem
resulted in VERY noticable decrease - not %, but times for several
aplications, so all working filesystems were left at 10%
General tests (above home-bred applications ) used were iozone && cp -rp of
/usr/openwin and /usr/local from another filesystem and within fs in
question.
iozone showed 30% hit for 0% minfree, no change at 3%
"time cp " showed factor 4 times for 0% minfree and ~2 at 3% from
another fs and 6 & ~4 within fs.
That is not quite clean experiment - at the same time I was also looking at
the effects of the size of the strip : 4gb were made out of 2 stripped 2Gb
drives with strip size 16K vs 1 cyl. So awfull timing probably worst
case from strip = 1 cyl - turned to be disaster for multiple small files.
Yet that was sufficient evidence to keep me from overly saving.
With best regards
Fedor Gnuchev
(hm, or Ted - in this English-typing world...)
mailto:qwe@ht.eimb.rssi.ru
----------------------------------------------------------------------------
-----------
Return-Path: <Garry.Robbins@labatt.com>
Sender: 25741@labatt.com
Date: Mon, 20 May 1996 07:52:25 -0400
From: Garry Robbins <Garry.Robbins@labatt.com>
Organization: Labatt Breweries of Canada
To: Steve Phelps <steve@epic.co.uk>
Subject: Re: FS performance if minfree < 10%
References: <2.2.32.19960520084935.0073d7b0@post.epic.co.uk>
I did some tests about a year ago, plus read the docs.
The "minfree" parameter only comes into play when allocating
files, not when accessing them.
I have some very large database partitions that I specify
minfree=0 wih good results.
I also increase the number of bytes per inode
as high as I can go for these type of file systems.
-----------------------------------------------------------------------------
Return-Path: <kevin@uniq.com.au>
From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
Date: Mon, 20 May 1996 23:06:45 EST
To: Steve Phelps <steve@epic.co.uk>
Subject: Re: FS performance if minfree < 10%
[ Regarding "FS performance if minfree < 10%", steve@epic.co.uk writes on
May 20: ]
> Does anyone know what the effective speed
> performance hit is, when reducing the minfree
> parameter of a file system (using tunefs) to 0%
> from 10%, and then optimizing for space
> rather than time?
If you have a static file system, not much. The penalty comes in
the file system code having to find contiguous fragments for new
allocations. If it has to start juggling lots of blocks around to
do that with a small enough free space, performance degrades quickly.
I'd try it out and see - it may be the case that on larger file systems
you can live with a hit of something in between. Try a binary search
starting at 5% perhaps?
----------------------------------------------------------------------------
-----------
Return-Path: <geert.devos@ping.be>
X-Sender: ping6838@pophost.ping.be
Date: Tue, 21 May 1996 00:10:33 +0200
To: Steve Phelps <steve@epic.co.uk>
From: geert.devos@ping.be (Geert Devos)
Subject: Re: FS performance if minfree < 10%
>Does anyone know what the effective speed
>performance hit is, when reducing the minfree
>parameter of a file system (using tunefs) to 0%
>from 10%, and then optimizing for space
>rather than time?
>
Hi Steve,
Depending on the nature of your drives (5,400 vs 7,200 rpm), SCSI (wide vs
narrow), metadevice or not (and what kind of striping/concatenation) you're
talking about, you should see a 40 to 80% performance degradation once you
start playing with the last 10%.
Some figures :
1. a F&W 9 Gig 5,400 rpm drive from MegaDrive (don't know the actuyal
manufacturer), running on a PowerMac 8500 on Fast&Wide SCSI gives some
6MB/s in the first half of it's capacity.
2. the same drive in the second half, but before the last 10%, slowly slips
to 4.2 MB/s
3. in the last 10%, you get some 2.8 to 3 MB/s
4. 2 Sun 2.1 Gig 5,400 rpm drives, striped with OnLine DiskSuite on Fast
SCSI II (narrow) should give you a overall throughput of 8 to 9 MB/s in the
beginning of your disk if well set up (depends on your stripe size, other
devices on the same controler, H/W you're running on, S/W level, file
tuning tricks performed during "newfs", etc)
5. The last 10% may peek out at some 1.5 to 2 MB/s.
Bare in mind that those figures are _raw_ performance figures, mostly doing
large sequential access. _*VERY*_ different results may be obtained by
using inappropriate parameters when creating/setting up your file
systems/metadevices.
So here are a couple of extra questions :
- What's your system? Is it a desktop/stand-alone machine, or is it a server?
- What's the typical file size that gets accessed? Are we talking small
files (cfr. database records) or large files (cfr. multi-MB graphics
files)?
- What's the memory config? Is there enough RAM to cache average read/write
load, or does the system occasionally resort to swapping out
processes/files/IO to avoid desperate memory conditions?
- What HW are you running on? Is this an MP machine, or a single-CPU?
You may think I'm not very kind to you, but I'm dead serious with the above
questions. This stems from my own experience, and not all was rosy in the
tests I conducted.
I'm willing to give my opinion if you can provide me with more detail, but
remember : it's allways an educated guess.
Looking forward to your response.
Geert
-
-------------------------------------------------------------------------
Steve Phelps
EMG Limited
52 The Old Steine
Brighton, UK.
Voice: +44 1273 728686 extn. 406
Fax: +44 1273 821567
http://www.epic.co.uk/
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:00 CDT