Re: Slow copy to SBS 2003



On Jul 15, 1:48 am, "SuperGumby [SBS MVP]" <n...@xxxxxxxxxxx> wrote:
you changed several factors, seemingly at the same time.

If you have a battery on the controller enable 'Write Back', if you do not
have a battery enable 'Write Back (enforced)' but realise that in a power
outage this may lead to drive corruption, not a big deal if the server
itself is on an UPS with comms capable of triggering tidy shutdown (the RAID
cache is written to disk on shutdown).

'Read Ahead' is another kettle of fish altogether. Read Ahead (on PERC, and
most others) works at the sector level of the HDD's. Asked to read sector
12345 the controller will also read 12346, 12347, and 12348. If the next
read request asks for these sectors they are already in cache, so the heads
don't have to move to pick them up. However, on SBS, trying to be all things
to all people at the same time it is _unlikely_ that sequential reads will
occur, you're filling the cache with information which never gets used. _IF_
the controller has file rather than sector based read ahead you are more
likely, on SBS, to realise an improvement.

"MM" <nosend...@xxxxxxxxxxx> wrote in message

news:1184454361.223458.240220@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On Jul 14, 6:26 pm, "SuperGumby [SBS MVP]" <n...@xxxxxxxxxxx> wrote:
you sure on that?

'Write Back' writes to cache and signifies completion on write to cache,
'Write Through' writes to cache and does not signify completion till
written
to disk, Write Back should be quicker.

I think the default varies whether the controller includes battery. If
battery is included 'Write Back' is default. If no battery most of the
PERCs
will not accept 'Write Back', you must use 'Write Back (enforced)' (or
similar). If no battery 'Write Back' behaves as 'Write Through'.

"MM" <nosend...@xxxxxxxxxxx> wrote in message

news:1184451159.943512.179010@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On Jul 14, 10:28 am, "Lanwench [MVP - Exchange]"
<lanwe...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
KasperCO <kaspe...@xxxxxxxxx> wrote:
On 13 Jul., 16:59, "Lanwench [MVP - Exchange]"
<lanwe...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Inline -

KasperCO <kaspe...@xxxxxxxxx> wrote:
Hi,

I'm experiencing a problem on a small SBS 2003 network.

While copying FROM the server is normal speed - this is not the
case
when copying TO the server. Just copying a few megabytes can take
minutes.

What antivirus are you running on the server/clients?

At the moment the server does not have any antivirus (Exchange-
services are disabled). The workstations uses preinstalled McAfee.

Disable the workstation AV and test....
After that, time to look at your networking hardware. If you're using
an
10/100 autosensing switch, try locking down all the NICs at 100/full,
rather
than letting them try to negotiate the settings themselves.

Your IP config looks fine.

Great!

BR,
/KasperCO- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Does the Server have RAID5? On our new Dell 2950 it was painfullyslow
writing files to RAID5 drive. Changing RAID5 cache to Write Thru (it
is Write Back by default on new Dells) increased speed by 10x. Be sure
you have battery back-up on server.

MM- Hide quoted text -

- Show quoted text -

Not 100% sure, I am not an expert but the change worked for me.I had
horrific sql perfomrance and everything was very slow after moving to
a new dell 2950 that was 10x the horsepower of our old box. After some
research I found that Dell Riad Cards (on the 2950 and some others)
default to Write Back cache and no Read Cache I turned on adaptive
read ahead cache and write through cache. I also reviewed and updated
settings described in the following MS KB

You may experience network-related problems after you install Windows
Server
2003 SP2 or the Scalable Networking Pack on a Windows Small Business
Server
2003-based computer that has an advanced network adapter
http://support.microsoft.com/kb/936594/en-us

After these chnages speed was unreal! In the raid card help file I
read (possibly misunderstood) that Write Back send a complete signal
when the write is complete while write through does not send a signal
when done. Based on the immedite perfomance fix I stopped looking. I'd
be happy to be be corrected if I can get even moew perfomrance with a
simple change again in the cache.

MM- Hide quoted text -

- Show quoted text -

Supergumby,

Thanks for your post... I must apologize to all as I had my terms
reversed. I rebooted the server this AM to check and I in fact set it
to "Write Back" NOT "Write Through" as I stated.

The Read cache is set to "Adaptive" it only reads ahead if two
consecutive sectors are read.

I'm sorry that I provided bad info, I'll be sure and confirm details
before I post,

MM

.



Relevant Pages

  • Re: 7.0-Release and 3ware 9550SXU w/BBU - horrible write performance
    ... I've got a new server with a 3ware 9550SXU with the ... According to 3dm2 the cache is on. ... did its battery test. ... Reading intelligently...done ...
    (freebsd-performance)
  • Re: Slow copy to SBS 2003
    ... If you have a battery on the controller enable 'Write Back', ... cache is written to disk on shutdown). ... when copying TO the server. ...
    (microsoft.public.windows.server.sbs)
  • Re: 7.0-Release and 3ware 9550SXU w/BBU - horrible write performance
    ... According to 3dm2 the cache is on. ... all of this seems to be due to the Battery unit. ... with the server powered off the ... I had to move the BBU and disconnected it for a few ...
    (freebsd-performance)
  • Re: Disable write caching
    ... and they all call-out specifically using battery backed caches. ... >> If you run an unprotected write-back cache against the log drive, ... >> When a write operation to the log disk is complete, ...
    (microsoft.public.windows.server.clustering)
  • Re: [dm-devel] Re: [PATCH] Implement barrier support for single device DM devices
    ... Using working barriers is important for normal users when you really ... write cache that will survive power outages... ... And second, "surprisingly", battery-backed RAID write caches tends to fail ... such a battery is enough to keep the data ...
    (Linux-Kernel)