我有一个似乎最近已经开始的奇怪的问题。
当我从我的笔记本电脑拷贝一个大文件（大约6GB）到我们旧的文件服务器之一时，服务器在几秒钟之后耗尽内存。
这只是最近才开始，也许是因为补丁星期二，虽然我不能确定。
这个服务器是Windows 2000 sp4机器，它是一个戴尔2950，内存为1GB（注意：我确信这个服务器已经超过了1GB！），直到一天结束的时候我才能断电。 3GHz至强处理器，4个250Gb 7.5k RPM SATA驱动器（在RAID 10中）和1个千兆网卡（NIC），连接到英特尔pipe理型交换机上的1GB端口。
（显然我不能发布图像，所以链接将不得不这样做）
内存使用情况图+复制期间的信息
只要我停止复制内存立即释放：
内存使用情况图+信息复制停止后
我已经删除了没有影响的杀毒软件。 我已将“Microsoftnetworking的文件和打印共享”选项更改为平衡。
我们有另外一台服务器，Windows 2000 SP4，带有2GB RAM，2.8Ghz Intel Quad Core，6个300GB 15k SAS RAID 10。
当我在这里复制相同的6GB文件时，可用内存的数量不会改变。
服务器运行时还有什么可以看的吗？ 由于它正在使用，并没有真正受到小文件副本的影响，我不能重新启动它。
以下是我在服务器内存不足时打开的一些perfmon计数器的屏幕截图。
在复制期间的Perfmon计数器
谢谢
加雷思
我遇到了同样的问题。
尝试在运行Windows Server 2008的64位服务器上执行P2V转换。VMDK文件（44 GB）的任何常规文件传输方法都会导致目标服务器上的Windows在几分钟后耗尽其14 GB RAM由于文件系统caching。
在32位服务器上运行P2V转换或文件复制不存在此问题，并且内存使用保持合理。
然后尝试将VMDK文件复制到目标VMWare服务器具有相同的问题。
这个页面描述了我所看到的：
http://blogs.technet.com/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx
根据我的工作，这个AM ESEUtil似乎是要走的路。 它没有我想象的那么快，但是它也没有吓倒Windows。
Windows FTP客户端在将文件移动到目标目标之前使用C：\上的Temp文件。 谨防！ 🙂
这是非常令人沮丧的。
我知道这有点痛苦，但你有没有尝试第三方文件复制工具？ Windows往往对文件副本有时是愚蠢的/缓慢的。 Lifehacker做了这些工具的前五名单，尝试其中的一个，看看你是否仍然有同样的问题。
http://lifehacker.com/5280976/five-best-alternative-file-copiers
另外，像towo说，检查你的虚拟内存设置。 最好的做法是你的页面文件应该是你的内存x1.5（即1 GB的mem = 1024 MB; 1024 * 1.5 = 1536 MB的页面文件）
W2K上的networking文件复制过程存在已知的问题 – 如果远程系统不能以比文件数据通过networking更快的速率清空写入caching，那么它将稳定地占用服务器上的所有物理内存，文件足够大。 Mark Russinovich详细介绍了这篇文章中有关Windows Vista文件复制机制所做更改的方式。 你发布的性能图看起来像这个问题，我已经看到了这种行为，在过去，我有一个非常慢的磁盘和快速的networking目标系统。
但是，即使您的目标操作系统有点旧，但硬件并不是那么薄弱，使用4×7.2K SATA驱动器的RAID 10设置应该适合60至120Meg / sec的写入速度，这比39Meg /秒Vista正在报告您的副本。 这里奇怪的是，如果它是一个可靠的，configuration良好的GigE链接，那么你可以达到70Mg / sec（也许更高一点）的networking传输速率，这样一个大型文件的持续拷贝。 也就是说，如果有任何其他stream量stream入或stream出客户端或服务器，或者（更可能）该速率大部分受到本地笔记本电脑硬盘驱动器速度的限制，则每秒38M字节不会exception。
无论如何，我会检查你的RAID 10是否确实是健康的 – 这里的症状会让我怀疑它不能写得太快。
我刚刚在服务器本身上运行一个副本，本地磁盘到本地磁盘，并没有问题。 可用内存量不会改变。
我想这是更多的networking相关的问题。 我会检查网卡驱动程序
更新：司机是几岁。 我会在今天晚上更新他们。 仍然不知道为什么这会影响服务器突然之后所有这一次虽然！
也许你需要在你的系统硬盘上增加你的虚拟内存，因为硬盘空间太小会造成这个问题。
另外，从逻辑的angular度来看，从文件系统复制到文件系统时，服务器实际上并不需要在内存中存储文件; 它只是在文件通过的内存中分配一个缓冲区。 但是，根据复制文件的方式，某些应用程序将首先将文件完全存储在内存中，然后将其写入磁盘。
尝试使用像FTP协议 – 如果它仍然发生，你应该看看一些networking问题。
这里有趣的问题是服务器如何实际存储文件 – 正如你所看到的，I / O负载正在下降，这意味着它实际上并不是在任何地方写文件，只是将其caching在内存中。
这是复制操作只是通过正常的networking共享（即通过Windows资源pipe理器或类似的复制）？ 我在Win2K下遇到了这样的一个bug，但是如果我没有记错的话，这个bug已经被修复了。
如果通过另一种方法复制，则该应用程序/服务可能试图将该文件保存在RAM中，直到完全拥有，在这种情况下，您需要升级或replace该应用程序/服务。
你使用Server 2003 64位？ 有一些信息解决此问题在Server 2003上的x64在这里 – > http://www.techspot.com/blog/224/slow-system-performance-when-copying-large-files-in-xp-x64-服务器2003-64 /
似乎在2003 / XP x64实际上发生了不less。 事实上，我刚刚意识到我的一台服务器已经有一段时间了，而且我还没有时间来解决这个问题。