locked
WHS insanely slow - even on localhost RRS feed

  • Question

  • When I copy files "locally" i.e. via remote desktop on the machine from localhost to localhost, I get transfer rates of less than 1500 kbps.

    I've seen other posts on this forum refering to chkde.exe, but I can't seem to get it installed. I've installed the Toolkit v1.1, but it doesn't seem to install the .exe?

    I can see that my problem is quite obviously with qsm.exe taking up 99% of my cpu when I copy even a single file. It takes more than 10 minutes (!) to copy 700MB.

    Does anyone have an idea how I can diagnose this problem further? Or how I can install chkde.exe?
    Saturday, July 4, 2009 11:50 PM

Answers

  • I think I managed to solve it myself.. At least make it a lot better. I now get transfers of 15000-23000 kbytes/s. Somehow, I still think they should be higher?

    I followed the advice offered here:
    http://social.microsoft.com/Forums/en-US/whssoftware/thread/6a8793b0-a97f-4453-a409-f2e59fd9d098

    It seems that some of my hard drives had reverted to PIO mode. This might be caused by the portio32 driver I had installed to test something, or by my old 80W PSU, which I found to be just a tad too small. I have now replaced the PSU, which seems to have helped a lot.

    Can anyone please confirm that a too small PSU could force a revert to PIO mode?
    • Marked as answer by Troels Larsen Tuesday, July 7, 2009 8:35 PM
    Tuesday, July 7, 2009 5:24 PM
  • Windows will revert a disk controller in that fashion when it detects a certain number of errors. Each time it detects X errors, it will "demote" the communications mode one level. Eventually it will reach PIO mode. This normally indicates a failing disk.

    I would recommend you review your server's event logs occasionally for the next few weeks for disk errors. But to answer your question, yes, a weak power supply can cause disk errors. Disks consume a certain amount of power when idling, but need more when they seek, and more yet when they spin up. If a disk doesn't get enough power, it may not respond to a request in a timely fashion.

    I'm not on the WHS team, I just post a lot. :)
    • Marked as answer by Troels Larsen Tuesday, July 7, 2009 8:34 PM
    Tuesday, July 7, 2009 5:33 PM
    Moderator

All replies

  • When I copy files "locally" i.e. via remote desktop on the machine from localhost to localhost, I get transfer rates of less than 1500 kbps.

    I've seen other posts on this forum refering to chkde.exe, but I can't seem to get it installed. I've installed the Toolkit v1.1, but it doesn't seem to install the .exe?

    I can see that my problem is quite obviously with qsm.exe taking up 99% of my cpu when I copy even a single file. It takes more than 10 minutes (!) to copy 700MB.

    Does anyone have an idea how I can diagnose this problem further? Or how I can install chkde.exe?

    chkde.exe no longer exists in the v1.1 toolkit as it is not compatible with the bits in Power Pack 1 and Power Pack 2. 

    I would start by checking all the drives in your server for errors using the steps in this FAQ post. 

    Thanks
    Lara Jones [MSFT] | Program Manager
    Community Support and Beta | Windows Home Server Team
    Windows Home Server Team Blog
    Connect Windows Home Server
    Windows Home Server
    Sunday, July 5, 2009 12:19 AM
    Moderator
  • Thanks for the information, I started the batch job from the FAQ shortly after your post and let it sit overnight. This morning, a prompt greeted me (see last line of below), so it had not finished processing my drives. I clicked 'y' and continued. Below is the output so far.

    It is still not finished with my other drives, but I will let you know the results of those as well.

    I should mention that I have two 1TB drives and one 1.5TB drive. Does chkdsk usually take this long? One again, my CPU is almost constantly running at full capacity. Most active processes are:

    taskmgr.exe
    demigrator.exe
    chkdsk.exe
    svchost.exe

    I had initially thought my CPU had clocked down due to heat, but the cpu heatsink is not that hot. I have no idea what the CPU usage is when I'm not connected via remote desktop.




    --- CHKDSK LOG ---

    CHKDSK is verifying files (stage 1 of 5)...
    202480 file records processed.
    File verification completed.
    48 large file records processed.
    0 bad file records processed.
    0 EA records processed.
    64984 reparse records processed.
    CHKDSK is verifying indexes (stage 2 of 5)...
    615131 index entries processed.
    Index verification completed.
    5 unindexed files processed.
    CHKDSK is verifying security descriptors (stage 3 of 5)...
    202480 security descriptors processed.
    Security descriptor verification completed.
    5831 data files processed.
    CHKDSK is verifying Usn Journal...
    33812912 USN bytes processed.
    Usn Journal verification completed.
    CHKDSK is verifying file data (stage 4 of 5)...
    202464 files processed.
    File data verification completed.
    CHKDSK is verifying free space (stage 5 of 5)...
    44430507 free clusters processed.
    Free space verification is complete.

     955779142 KB total disk space.
     777672524 KB in 96425 files.
         53616 KB in 5832 indexes.
             0 KB in bad sectors.
        330974 KB in use by the system.
         65536 KB occupied by the log file.
     177722028 KB available on disk.

          4096 bytes in each allocation unit.
     238944785 total allocation units on disk.
      44430507 allocation units available on disk.

    C:\WINDOWS>chkdsk C: /x /r
    The type of the file system is NTFS.
    Cannot lock current drive.

    Chkdsk cannot run because the volume is in use by another
    process.  Would you like to schedule this volume to be
    checked the next time the system restarts? (Y/N)
    Sunday, July 5, 2009 9:07 PM
  • Thanks for the information, I started the batch job from the FAQ shortly after your post and let it sit overnight. This morning, a prompt greeted me (see last line of below), so it had not finished processing my drives. I clicked 'y' and continued. Below is the output so far.

    It is still not finished with my other drives, but I will let you know the results of those as well.

    I should mention that I have two 1TB drives and one 1.5TB drive. Does chkdsk usually take this long? One again, my CPU is almost constantly running at full capacity. Most active processes are:

    taskmgr.exe
    demigrator.exe
    chkdsk.exe
    svchost.exe

    I had initially thought my CPU had clocked down due to heat, but the cpu heatsink is not that hot. I have no idea what the CPU usage is when I'm not connected via remote desktop.




    --- CHKDSK LOG ---

    CHKDSK is verifying files (stage 1 of 5)...
    202480 file records processed.
    File verification completed.
    48 large file records processed.
    0 bad file records processed.
    0 EA records processed.
    64984 reparse records processed.
    CHKDSK is verifying indexes (stage 2 of 5)...
    615131 index entries processed.
    Index verification completed.
    5 unindexed files processed.
    CHKDSK is verifying security descriptors (stage 3 of 5)...
    202480 security descriptors processed.
    Security descriptor verification completed.
    5831 data files processed.
    CHKDSK is verifying Usn Journal...
    33812912 USN bytes processed.
    Usn Journal verification completed.
    CHKDSK is verifying file data (stage 4 of 5)...
    202464 files processed.
    File data verification completed.
    CHKDSK is verifying free space (stage 5 of 5)...
    44430507 free clusters processed.
    Free space verification is complete.

     955779142 KB total disk space.
     777672524 KB in 96425 files.
         53616 KB in 5832 indexes.
             0 KB in bad sectors.
        330974 KB in use by the system.
         65536 KB occupied by the log file.
     177722028 KB available on disk.

          4096 bytes in each allocation unit.
     238944785 total allocation units on disk.
      44430507 allocation units available on disk.

    C:\WINDOWS>chkdsk C: /x /r
    The type of the file system is NTFS.
    Cannot lock current drive.

    Chkdsk cannot run because the volume is in use by another
    process.  Would you like to schedule this volume to be
    checked the next time the system restarts? (Y/N)

    If chkdsk has to fix any part of your drive(s) it will take longer but yes, it does tend to take some time and it will take longer depending on how large your storage pool is. I have 7TB in mine and it takes about 24 hours to run.

    Once chkdsk has finished,  see if your performance is better. A bad drive can cause perfomance problems.

    Thanks
    Lara Jones [MSFT] | Program Manager
    Community Support and Beta | Windows Home Server Team
    Windows Home Server Team Blog
    Connect Windows Home Server
    Windows Home Server
    Sunday, July 5, 2009 9:13 PM
    Moderator
  • I've finished running chkdsk, but the speed is the same. Less than 1000 kbytes/s localhost -> localhost.

    My CPU is still maxing out, with qsm.exe and System being the main culprits.

    Strange thing is that the entire system seems slower than usual somehow - as if my processor has clocked down or something. When I run CPU-Z, I can see that it hasn't.

    I'm at a complete loss as to what is causing this performance bog. The processes that are taking up my CPU shouldn't stress it, but they are. This seems to have happened very suddenly, so I'm pondering a reinstall.

    One thing worth nothing is that my network is also running slowly at the moment, but unless I'm mistaken, that should not have any effect on localhost->localhost copying?

    Do you think a reinstall of WHS would solve my problem, and if yes - what is the easiest way to keep all the files on my system? I don't really have the storage capacity to back it all up elsewhere.

    Anyone have any ideas?

    My system is a VIA EPIA SN 18000G (1.8GHz processor)
    with three SATAII hard drives (2x1TB and 1x1.5TB)

    EDIT TO ADD:

    I'm really puzzled now.. As soon as I'm not copying anything, CPU usage drops below 2%.
    Tuesday, July 7, 2009 3:43 PM
  • I think I managed to solve it myself.. At least make it a lot better. I now get transfers of 15000-23000 kbytes/s. Somehow, I still think they should be higher?

    I followed the advice offered here:
    http://social.microsoft.com/Forums/en-US/whssoftware/thread/6a8793b0-a97f-4453-a409-f2e59fd9d098

    It seems that some of my hard drives had reverted to PIO mode. This might be caused by the portio32 driver I had installed to test something, or by my old 80W PSU, which I found to be just a tad too small. I have now replaced the PSU, which seems to have helped a lot.

    Can anyone please confirm that a too small PSU could force a revert to PIO mode?
    • Marked as answer by Troels Larsen Tuesday, July 7, 2009 8:35 PM
    Tuesday, July 7, 2009 5:24 PM
  • Windows will revert a disk controller in that fashion when it detects a certain number of errors. Each time it detects X errors, it will "demote" the communications mode one level. Eventually it will reach PIO mode. This normally indicates a failing disk.

    I would recommend you review your server's event logs occasionally for the next few weeks for disk errors. But to answer your question, yes, a weak power supply can cause disk errors. Disks consume a certain amount of power when idling, but need more when they seek, and more yet when they spin up. If a disk doesn't get enough power, it may not respond to a request in a timely fashion.

    I'm not on the WHS team, I just post a lot. :)
    • Marked as answer by Troels Larsen Tuesday, July 7, 2009 8:34 PM
    Tuesday, July 7, 2009 5:33 PM
    Moderator
  • Thanks for the help to the both of you. My PC definitely runs faster now, but I still wonder if 15000-20000 bytes/s is really all I can get from my drives..
    Tuesday, July 7, 2009 8:36 PM
  • Given that you have a lot of overhead (network, I/O controller, Windows Home Server overhead, etc.), yes, 15-20 MB/s is probably about all you'll get from the drives in your server.
    I'm not on the WHS team, I just post a lot. :)
    Tuesday, July 7, 2009 8:59 PM
    Moderator