我有一个系统,文件将从一个网络共享复制到另一个网络共享。文件本身不是很大,但要复制的文件数量为 20000。启动复制操作的 .NET 服务应用程序将在多台机器上运行,但源文件夹和目标文件夹是相同的。这个过程似乎慢得令人无法接受:
我们假设这是因为高网络 I/O 和磁盘 I/O。
隔离瓶颈的故障排除步骤应该是什么?就软件设计或硬件容量而言,有哪些解决方案可以加快流程。
我有一个系统,文件将从一个网络共享复制到另一个网络共享。文件本身不是很大,但要复制的文件数量为 20000。启动复制操作的 .NET 服务应用程序将在多台机器上运行,但源文件夹和目标文件夹是相同的。这个过程似乎慢得令人无法接受:
我们假设这是因为高网络 I/O 和磁盘 I/O。
隔离瓶颈的故障排除步骤应该是什么?就软件设计或硬件容量而言,有哪些解决方案可以加快流程。
首先,确定是磁盘还是网络。从您正在写入的磁盘开始。我编写了一个快速应用程序来启动几个线程并将随机数据写入几个固定大小的不同文件。测量需要多长时间。测量写入 1 个大文件,许多小文件。如果是磁盘,则很可能是由于许多单独的写入操作和慢速 RPM 驱动器造成的。或者您可能正在写入配置不当的磁盘阵列。
其次,检查您的网络。您的路由器性能不佳还是工作过度?确保您的所有机器和路由器就速度和协商达成一致。路由器上的 100Mbit-FullDuplex 和服务器上的 100Mbit-AutoNegotiate不是一回事。(对我们来说就是这种情况,并且帮助很大)
正如 Ben评论的那样,压缩文件并传输一个大文件会有所帮助。我遇到了这个问题,实际上我对文件进行了 TAR。它甚至比没有压缩的压缩还要快。我将SharpZipLib用于 zip 和 tar。
您还可以尝试在单独的线程中缓冲您的读取和写入。对我们来说, System.File.Copy在网络上甚至都不可靠。手动缓冲我们的文件传输显示了一些改进,但不足以证明复杂性是合理的。
处理大量小文件总是比处理一个大文件中的相同数量的数据慢,因为所有额外的处理分配表、检查文件名引用等。当您在请求中添加网络延迟时,情况会更糟。
并不总是有用,但即使在千兆 LAN 上使用 Windows 文件共享压缩文件(不压缩压缩以使其快速)并在目的地再次提取可能会快得多
不过,Hometoasts 的答案很好,我投了一个赞成票,因为它涵盖了磁盘和网络 IO 瓶颈的可能性。我真的只提供了一种解决方法而不是答案。
很高兴我能够帮助一些实用且容易做的事情。:)