Re: Disk partitions?
From: SuperGumby [SBS MVP] (not_at_your.nellie)
Date: 09/08/04
- Next message: Richard Wagstaff: "OT Powerquest V2i Protector"
- Previous message: BobStone: "Re: Move SBS 2003 to new hardware"
- In reply to: NickC: "Re: Disk partitions?"
- Next in thread: NickC: "Re: Disk partitions?"
- Reply: NickC: "Re: Disk partitions?"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 8 Sep 2004 22:05:11 +1000
defraggin exchange is a complex issue, you have fragmentation of the
database and file level fragmentation to consider.
Then the differnet types of fragmentation will be impacted by your HDD
subsystem and other activity.
Let's dutifully fully defragment our system. Fortunately, the system I'm
introducing is running a pair of SCSI drives in hardware mirror, so when we
consider the physical performance of the drives we know that it's going to
be impacted by RAID but we have a pretty simple partition layout.
(hope this makes sense)
|---partition1 OS---||---part2 DATA---||---part3 \clientapps---||---part4
Exch DB---|
if we assume the system is running and people are accessing the Exchange
then the heads of the drive are travelling furiously from the outermost
cylinders of the drive, to run the OS, to the innermost cylinders to access
Exch data, continuously traversing half of your HDD doing nothing. WHO CARES
how fragmented the files on this system are? Drive fragmentation impacts
performance because the heads must move to physical areas of the disc to
collect data,,, BUT we DON'T CARE, we've implemented a drive configuration
which results in constant head movement over the whole drive, yeah, file
level fragmentation will result in greater need to move to different areas
of the drive and will slow us down further but we made a mistake in the
first place.
swap parts 3 + 4.
|---partition1 OS---||---part2 DATA---||---part3 Exch DB---||---part4
\clientapps---|
Now, the average time to reposition the heads is lower. The OS and Exch
partitions are physically closer together. \clientapps is not being accessed
regularly so the heads seldom have to travel that far. We're possibly at a
point where our head movement is 75% of our original scenario, assuming
similar levels of fragmentation we have a 25%-33% improvement just by
thinking things out.
SO, let's get rid of another partition.
|---partition1 OS---||---part2 DATA including Exch DB---||---part3
\clientapps---|
We have a reasonable expectation that our users access DATA as well as
email. We don't really get an improvement from our physical layout but our
most accessed partition now has the combined free space of parts 2+3 above.
NTFS likes free space. Any file system likes free space, both during normal
operation and at defrag time.
Now let's defrag the sucker, stop Exchange and do a file level defrag which
includes the Exch DB. part2 now has:
|docs, xls, ppts, Exch, more docs, more xls, our 5GB .mdb and then lots of
free space|
Our users access docs, xls, ppts, Exch and mdb constantly. The drive heads
are furiously flying over this partition, hopefully in an optimised manner,
but get this, the drive is 'command queueing' and doing the best job it can,
then someone actually posts an item. Our drive looks like:
|docs, xls, ppts, Exch, more docs, more xls, our 5GB .mdb, the item someone
posted in Exch and then lots of free space|, bugger, our Exch DB is again
fragmented. Why is it fragmented? Because we use the sucker.
hmmm, rambling again
NTFS suffers performance issues due to file level fragmentation MUCH LESS
than FAT.
If the free space on a drive is below 30% NTFS suffers, by 20% it suffers
dramatically, at 10% free space NTFS almost dies. Increasing the percentage
of free space on an NTFS partiton is a good idea.
Exch does periodical maintenance which includes 'online defragmentation'
(rearranges pages in the database to improve performance).
There is a tool to do 'offline defragmentation' of the Exch DB files. I use
it so rarely I have to say I _think_ it's eseutil.
It's a good idea to occassionally do an Exch offline defrag after an online
defrag.
If Exch isn't running the Exch DB's are just normal files, you can defrag
them using the normal Windows defrag. (I almost didn't type this, I got
bitten several months ago defraggin m' own Exch, learnt all sorts of thing
about Exch I really would prefer NOT to know). If Exch is running the normal
Win defrag utility should recognise the files as being in use and not
attempt to move them.
Is there any advantage in defragging any NTFS partition? Well, that depends
on usage. I regularly tell my nephew to defrag his system, he installs every
bit of rubbish he can pick up on the net, tries games and gets bored,
removes them, tries another. Not only his DATA but the OS and Application
areas regularly fragment. Should this strategy apply to a production SBS
server? Probably not. You occassionally apply a service pack and this
_probably_ results in fragmented files, hopefully not heavily fragmented
files because there's a decent amount of freespace on your OS partition.
Similar for your Application install area, occassional SPs. The Exch DB
_will_ fragment, no matter what.
"NickC" <me@somewhere.com> wrote in message
news:eFnIxPYlEHA.3896@tk2msftngp13.phx.gbl...
> "Kevin Weilbacher [SBS-MVP]" <kweilbacMVP@gte.net> wrote in message
> news:OjuDS9nkEHA.1048@tk2msftngp13.phx.gbl...
>> SG - I thought that some have recommend separating Exchange out, since it
> is
>> not recommended to defrag a partition that also contains the Exchange
>> database.
>>
>> --
>> Kevin Weilbacher [SBS-MVP]
>> "The days pass by so quickly now, the nights are seldom long"
>
> So question is is there any advantage in not defraging an Exchange
> partition?
>
> Nick
>
>
- Next message: Richard Wagstaff: "OT Powerquest V2i Protector"
- Previous message: BobStone: "Re: Move SBS 2003 to new hardware"
- In reply to: NickC: "Re: Disk partitions?"
- Next in thread: NickC: "Re: Disk partitions?"
- Reply: NickC: "Re: Disk partitions?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
