locked
Extremely slow backups RRS feed

  • Question

  • I have 2 clients on my server.  One, a Vista Home Premium system, takes on the order of 5-8 minutes to do an incremental backup.  The other, an XP Pro system, takes over 50 minutes to do an incremental.  The XP system has an AMD XP2000+ processor and 768MB of memory so it's not a slouch.   There should not be that much data that is changing - mostly email.  The initial backup took just under 6hours but that was when it backed up a drive I didn't want backed up (and is apparently bad) and I've since removed it.  I can't tell from the logs how big the actual backup image is.

     

    Any guesses as what can be causing this significant of a slowdown?  While the backup is running, the system is grinding to an unusable state whereas my Vista desktop is barely seeing the load (although it's a faster CPU).

     

    Any ideas would be greatly appreciated.

     

    Thanks,

        .../Ed

     

    p.s. I should add this is on a wired network with all 3 systems (both clients and the server) at 100mbps full duplex.

     

     

    Tuesday, September 11, 2007 3:21 AM

Answers

  • I beat this into submission last night.  I appeared to have suffered from the DMA to PIO slowdown.  Although I made a few changes (and a few at the same time, which I know makes the conclusions harder), I believe that this was the root cause.  I uninstalled the driver for the primary IDE channel, rebooted, and when it came back up, all was well.

     

    Initially, the CPU was almost 100% kernel time.  Things like a basic chkdsk would peg the CPU.  Now, the CPU is the 10-20% range (or less) and the chkdsk is I/O-bound.  My incremental backup before my changes took about 55 minutes.  After the changes, it took 6 minutes.

     

    It seems like I've got a brand new system and I'm a happy camper now! 

     

    Thanks to everybody for their suggestions.  I never did get around to trying to the new NIC (didn't need to but I had ready just in case).

     

       .../Ed

    Friday, September 21, 2007 11:39 AM

All replies

  • Hi,

     

    Normally, if one client within the same network, and it have slow issue and in this case, slow backup, I will guess either the client hard disk problem, or the network drivers need to be update, and sometimes, it defernet issue with the hardware as memory RAM problem.

     

    Can `you try this on the client with slow backup time:

    Start - Run - cmd - chkdsk /R /F

     

    My best.

    Tuesday, September 11, 2007 3:50 AM
  • I didn't have a chance to do the chkdsk last night but did do some simple drag n drop testing.  When I drop a folder full of photographs I see that the CPU is running at 70-90% and the network at 15-20%.  When WHS was doing a backup the network only runs at <1% with the CPU flat out.  I've checked the Windows event logs and they're clean.  I just updated my network drivers  (it's an RTL 8139) but that didn't make it any better (nor worse) - I was running the stock Windows drivers but upgraded to the ones directly from Realtek.

     

    I don't know why the CPU needs to be pegged copying data across the network - that just doesn't sound right to me and I manage a large NetBackup environment at work that has a lot of Windows clients and I don't see this type of load on any of them (and the Windows admins haven't reported anything like this).

     

    Tonight it's chkdsk time...

     

    Thanks,

       .../Ed

    Wednesday, September 12, 2007 11:39 AM
  • Ed, consumer hardware often offloads a lot of processing tasks form the HBA to BIOS or driver software (i.e. the CPU). Most cheap SATA and IDE cards do this, for example, and all "motherboard RAID" solutions do as well. When you are copying files to WHS over your network, WHS is busy trying to organize and migrate those files off the primary disk to secondary disks (accessing 2 or 3 disks at a time, usually), so you see a spike of CPU usage. It's not the network drivers that are at fault in this case.

    If you can get your primary and secondary disks onto different HBAs, you may see CPU usage drop somewhat, or at least write performance may improve. Smile I'm pretty certain you'll see lower CPU usage if you can get all of your secondary disks connected to an HBA with an onboard processor.
    Wednesday, September 12, 2007 2:57 PM
    Moderator
  • Hi Ken,

    I really do not see it as "server" issue, it more than "client" issue, I could be wrong, but the fact that:

    1 - Client_1 within the same network, backup/move files within the server, and the time was ok.
    2 - Client_2 within the same network, backup/move files in slow matters, and the cpu rise, then that either problem within the hardware (mostly drives issue), or failing hardware, like hard disk or ram.

    Or simply, the client with problem could simply doing many task at the same time, as backgorund one.

    Or simply, I need more coffee reread the topic again Smile

    My best.
    Wednesday, September 12, 2007 4:44 PM
  • Evening,

    Could it be a Network Card problem, I know your drivers are up to date, but there appears to be numerous cases where one NIC has problems working with others. Is there a chance of substituting another card as a test?

     

    Colin

    Wednesday, September 12, 2007 6:32 PM
  •  Ed Wilts wrote:

    ..  I just updated my network drivers  (it's an RTL 8139) but that didn't make it any better (nor worse) - I was running the stock Windows drivers but upgraded to the ones directly from Realtek


       .../Ed



    Hi,

    Is the NIC a chipset in the motherboard on stand alone NIC card?

    If it a card, good suggestion been made above this post if you have the option to replace the card with another and do the test.

    If it chipset in the motherbard, did you tried the mobo brand maker drivers?

    Fianlly, if it possible to change the cat cable for the slow client with another cable and test?

    My best.
    Wednesday, September 12, 2007 11:31 PM
  • The NIC is onboard on both the client and the server - the client is a Compaq Presario 6000Z with an onboard RTL8139 NIC.  I've borrowed a good server NIC from the office and I'll try that this weekend - that will eliminate or prove both the NIC/driver as culprits.

     

    I don't have another handy network cable to test unless I want to move the client but I'll consider that if I need to.  I'll do some iperf testing if replacing the NIC doesn't help.

     

    Thanks again,

       .../Ed

    Friday, September 14, 2007 3:10 AM
  • Just beware, you may not find the server (from clients) after the NIC has been changed. You may have to run discovery.exe to get the connector software to find the server and do backups.

    Cruise
    Friday, September 14, 2007 5:21 PM
  • I beat this into submission last night.  I appeared to have suffered from the DMA to PIO slowdown.  Although I made a few changes (and a few at the same time, which I know makes the conclusions harder), I believe that this was the root cause.  I uninstalled the driver for the primary IDE channel, rebooted, and when it came back up, all was well.

     

    Initially, the CPU was almost 100% kernel time.  Things like a basic chkdsk would peg the CPU.  Now, the CPU is the 10-20% range (or less) and the chkdsk is I/O-bound.  My incremental backup before my changes took about 55 minutes.  After the changes, it took 6 minutes.

     

    It seems like I've got a brand new system and I'm a happy camper now! 

     

    Thanks to everybody for their suggestions.  I never did get around to trying to the new NIC (didn't need to but I had ready just in case).

     

       .../Ed

    Friday, September 21, 2007 11:39 AM
  • I have had this problem and been wondering what it was for days until I read this post, tried uninstalling the driver for the primary IDE channel but was still the same when it came to transfering data to the server. (stuck at 35% and was slower than a snail, after 9 hrs was only up to 60%).

     

    OK lets change the NIC card as suggested this was not built on board (MX98715AEC) to a Realtek RTL8169/8110, BINGO it now works a treat on backing up this machine.

     

    Many thanks to everybody for there suggestions.

    Tuesday, January 1, 2008 12:13 PM
  • Setting the client NIC to Auto Negotiate sped up things quite a bit.
    Tuesday, January 1, 2008 2:04 PM