Windows Server 2008 R2 grinds to a screeching halt during file copy operations

When my Windows Server 2008 R2 machine is performing any large disk operations (copying 10GB files from one drive to another, copying similar file over network, merging HyperV snapshots, compressing large files), performance of the whole machine slows down terribly, everything becomes unresponsive. This is noticeable in any situation when the disk access is large enough not to fit in the cache.

Are there any settings available for tuning this behaviour? I can accept slower file transfer if this would give me more responsiveness.

System details: Dell Optiflex 960, Core 2 Quad Q9650, 8GB RAM, 2 SATA drives - 320GB (ST3320418AS) and 1TB (ST31000528AS), NCQ active on both, Intel 82564LM-3 Gigabit Ethernet, ATI HD 3450 graphics, Intel ICH10 bridge. We have multiple machines like this, every one is exhibiting the same behaviour. I though this was overkill for a workstation, apparently I was mistaken.

Update: I guess I shouldn't have mentioned the HyperV at all. The above configuration is a standard workstation setup at the company I work for, this is not a server of any kind. I have at most 3 virtual machines working, and usually I'm the only person accessing them. Never the less, the slowdown occurs even when no VMs are running. On a Linux machine I'd simply ionice the copy process and I could forget about it, is there any way to manage IO priorities on Windows?

Solution 1:

Using a server as a desktop... got a fancy video card driver installed? (just a suggestion)

http://blogs.msdn.com/b/virtual_pc_guy/archive/2009/11/16/understanding-high-end-video-performance-issues-with-hyper-v.aspx

Update: On an i7 with SLAT or EPT support, you can do something like this {for VMs only} via RemoteFX. But running Aero on the host may still make performance worse.

Solution 2:

I am inclined to sa that happens if you run a hyper-v server on inapproiate hardware. I had the same on repurposed workstation systems where the IO budget of the ard disc was on the lower end.

Ever since moving to a proper raid conroller on a beefier server I can copy that stuff over at speeds I found incredible before (hundreds of megabytes per second WHILE other things happens). Only problem is when 10 or so vm's are making their monthly at the same time patch orgy.

I would suggest checking: * Average disc response time, normally and during operations * Disc busy percentages.

For more information please post the complete hardware - memory, processor, disc subsystem and layout.

** Update

SATA drives - 320GB and 1TB

You must be freaking joking to run Hyper-V against that.

here are some convigurations I have.

• Small server (16gb RAM, runs a handfull of images): Adaptec 3405, 245mb write back cache battery backed up, 3x 320gb ram disc. This is a low performance thing. Works nice. They also have another 4 discs as file storage 8because i use them as double file servers in a small development setup).
• Standard Server: 64gb RAM, one in use. Runs 20-30 images. And here we go: Adaptec 5805 raid controller, 512mb ram, battery back up, write back cache. 8(!) 10.000RPM Velociraptors, RAID 10.

BOTH (!) have problems when making large file transfers as IO gets taxes, although the larger one is network limited then (1gbit until in 5 hours, then 4) and generall the combo with the controller handles the situation VERY well.

A 2 disc system - and the 1tb obviously is not a performance disc, but one that is made for size - simply is like running a formula 1 race with a fiat panda. On board non buffering low price controller means no IO optimization is possible either. When your file copy hits, the disc budget totally goes into this. THere may be some left for the OS, but anything else.... whow.

By modern standards this is LOOOOOW end server or a decent workstations with a lot of CPU (8gb RAM is higher end workstation). The discs are not server grade. This is not something I would put a hypervisor on except for demonstrations. Hyper-V is like a database - it needs IO. A lot of. Because the hypervisor totally kills "sequential access" and turns it into random, like any database is.

You need to put appropriate IO capbilities into it. As well as enough RAM (if youneed it), then you can run a lot more on them, virtual machine wise - the CPU is otherwise simply totally unused. I hope your VM's are very CPU intensive, otherwise it is wasted.