2008 Server Crashes during large file copy via iSCSI 2 posts. Windows 2008 Datacenter server fully patched, running Virtual Server 2005 R2. As well as multiple reboots. So thats an improvement.

I have a strange issue that appears to have started recently. When I copy a large file (Approx 6GB) from my laptop to one of our older fileservers the server runs out of memory after a few seconds. This has only started recently, maybe since patch Tuesday although I can't be sure. This server is a Windows 2000 sp4 machine, its a Dell 2950 with 1GB ram (Note: I am sure this server had more than 1GB!, I can't physically check until the end of the day when I can power it down), 3GHz Xeon proc, 4 x 250Gb 7.5k RPM SATA drives in raid 10 and a 1 Gigabit NIC connected to a 1GB port on an intel managed switch.

(Apparently I can't post images so a link will have to do) As soon as I stop the copy the memory instantly frees up: I've removed the antivirus which made had no impact. I've changed the 'File and Print Sharing for Microsoft Networks' options to balanced. We have another server, Windows 2000 SP4 with 2GB Ram, 2.8Ghz Intel Quad Core, 6 x 300Gb 15k SAS in raid 10. When I copy the same 6GB file here the amount of available memory doesn't change.

Is there anything else I can look at while the server is running? As it's in use and not really affected by small file copies I can't reboot it just yet. Here is a screen shot of some perfmon counters I had open just as the server runs out of memory.

Thanks Gareth. I'm running into the same problem. Trying to do a P2V conversion onto a 64-bit server running Windows Server 2008. Any of the normal file transfer methods for the VMDK file (which is 44GB) cause Windows on the destination server to run out of its 14GB RAM after a few minutes due to the file system caching. Running the P2V conversion or file copy on a 32-bit server doesn't have this problem and memory usage stays reasonable.

Then trying to copy the VMDK file to the destination VMWare server has the same problem. This page describe exactly what I'm seeing: Based on my work this AM ESEUtil seems to be the way to go. It wasn't as fast as I'd expected, but it didn't freak out Windows either. The Windows FTP client uses a Temp file on C: before moving the file to the target destination.

Beware!:-) This is very frustrating. There are known issues with the Network File Copy processes on W2K - if the remote system can't empty the write cache faster than the rate the file data is arriving in over the network then it will steadily consume all physical memory on the server if the file is big enough. Mark Russinovich has some details on the ways this might happen on changes made in Windows Vista's file copy mechanisms. The performance graph you posted looks like this issue and I have seen exactly this sort of behavior in the past where I had a target system with very slow disks and a fast network. However even though your target OS is a bit old the hardware isn't all that weak and a RAID 10 setup with 4x7.2K SATA drives should be good for somewhere between 60 and 120Meg/sec write speed which is significantly higher than the 39Meg/sec Vista is reporting for your copy.

The odd thing here is that if it is a solid, well-configured GigE link then you could hit network transfer rates reaching 70Meg/sec (and maybe a bit higher) for a sustained copy of a large file like this. That said 38Meg/sec isn't abnormal either if there's any other traffic flowing in or out of either the client or server or (as is more likely) that rate is mostly limited by the speed of your local laptop hard drive. Blitz illu pdf download. In any case I would check that your RAID 10 was actually healthy - the symptoms here would make me suspect it wasn't able to write as fast as it should be. Maybe you need to beef up your virtual memory on your system hard drive, where low hard drive space could have caused said problem. Also, from a logical point of view, the server does not actually need to store a file in memory when copying from file system to file system; it just allocates a buffer in memory the file passes through.

Depending on how you copy files, though, some applications will first store the file completely in memory, and then write it to the disk. Try to use a protocol like FTP - if it still happens, you should probably look into some networking problems. The interesting question here would be how the server actually stores the files - as you can see, the I/O load is just way down, which means it's not actually writing the file anywhere, just buffering it in memory.