首先快速浏览一下环境：
在Windows服务器上运行的NetBackup（6.5.4，如果您在意的话）使用LTO3驱动器。
备份目标在Sun硬件上用作Solaris 9服务器，Veritas Volume Manger。
现在在Xiotech SAN上，使用LVM重新构build为RHEL5盒来pipe理卷。 有大量的卷。
数据的性质和盒子运行的应用程序（Optix）是这样的，它用来写入一个卷，直到它达到一定的大小，然后该卷被永远locking更多。 因此，我们有\ u01 \ u02 \ u03 … \ u50。 一段时间（仍然在solaris版本上），我们扩展并打开了这些卷，以便在任何特定的日子里任何或全部可能改变。 备份吞吐量平均每秒40MB。
在新的Linux版本中，我们正在平均接近8MB /秒。 鉴于这里有2.1TB的数据，这是非常不可接受的，即使是运行4个stream，也需要48个小时才能完成。 服务器上的I / O挂钩。 我非常确定这不是SAN，因为使用相同级别的存储和类似的服务器硬件的其他客户端正在备份，但可以容忍20MB /秒。
我正在寻求提高吞吐量的想法 。 位于隔壁办公室的Solaris员工在Linux上指责LVM。 没有人会认为这是备份环境，因为它在其他地方依然performance出色。 现在很慢的盒子的pipe理员说：“我不知道这不是我，用户说没关系。 这可能是真的，因为它是一个文件pipe理系统，他们正在读写小文件。
疑难解答想法 有没有人看到LVM垃圾备份或其他I / O性能？ 特别是在大量的文件数量很多（可能是1000万个）的情况下呢？
编辑更正单位。
编辑添加：
网卡处于1000 / Full（从OS和Switch都检查）
文件系统是EXT3。
更多的新信息….
性能打击似乎在运行LVM和EXT3的几个盒子上发生。 基本上我们今年夏天build立的所有新的RHEL5盒子。
您是否已经使用sar或iostat来监控备份期间的磁盘性能，以了解Linux对磁盘性能的看法？
如何使用某种基准testing工具来testing系统上文件的原始读取性能？ 我只是想出了这个，所以这可能是一个可怕的方式来做到这一点，这实际上只是顺序阅读，但是：
sudo dd if=/u1/some_large_file of=/dev/null 基本上，如果您使用基准testing实用程序来复制所有小文件的读取，那么您可以非常轻松地从磁盘读取数据。
以下不再相关：
如果以20 kb / s表示kilobits，除非我搞乱了这个，因为现在太早了，你的数字没有加起来。 你说你有20兆字节/秒的2.1兆兆字节：
即使只有1 TeraByte：
1 TB = 8589934592 bits 8589934592 / 20 (bits a second) = 429496730 seconds 429496730 / 60 (seconds) = 7158278 minutes 7158278 minutes / 60 = 119,304 Hours 119,304 / 24 = 4971 (Days)
或者如果你的意思是千字节：
1 terabyte = 1073741824 kilobytes 1073741824 / 20 kB/s = 53687091 seconds 53687091 seconds = 621 days
我搞砸了这些计算？ （如果我是:-)，将不得不删除我的post）
这个问题certificate是一个NetBackup客户端版本问题，而不是Linux / LVM问题。 当箱子被重build作为一个Linux箱子时，6.5客户端被安装了。 今天为了回应另一个问题，我们将客户端版本升级到6.5.4。 我又回到了以25-27mb / sec的速度将数据从盒子里拿出来。
如何才能忘记NetBackup的头号规则，或者可能是任何备份软件，如果您遇到问题我不知道，请确保您的客户端和服务器版本匹配 。 也许我需要一个纹身。
你在LVM卷上使用什么文件系统？
以及这1000万个小文件是如何存储的 – 全部在一个目录（或less量的目录）中，还是分布在许多目录和子目录中？ （“许多”是一个任意大的数字）
我问的原因是，有一些文件系统有严重的性能问题，当你有成千上万的文件。 这是你减速的一个可能的原因。
例如，ext2或ext3没有启用dir_indexfunction（IIRC，dir_index在ext3上已经有几年的默认值了，但它并没有完全消除这个问题）。
您可以使用tune2fs查询和/或设置ext3的dir_indexfunction。 例如查询：
＃tune2fs -l / dev / sda1 | grepfunction 文件系统function：ext_attr resize_inode dir_index文件typessparse_super
如果你没有在列表中看到dir_index，那么你需要像这样打开它：
并设置：
＃tune2fs -O dir_index / dev / sda1 tune2fs 1.41.8（2009年7月11日）
（是的，tune2fs只在这里通过打印版本号来响应…不会告诉你操作是成功还是失败，不好，但是如果失败，可能会打印一个错误）
最后：如果这确实是问题，并且启用dir_index不起作用，那么您可能需要考虑使用不同的文件系统。 XFS是一个很好的通用文件系统，而AFAIK ext4没有这个问题。 要么是replacefs的合理select（虽然ext4是相当新的，即使很多人使用它没有问题，我不知道我会信任它在生产服务器上）
LVM本身不应该影响这一点。 据我所知，在每个元数据操作中都没有引用LVM位，这是延迟进入的地方。 它在内核的另一层。 LVM会影响mount / unmount，而不会影响文件的打开/closures。
克雷格指出，更大的可能性是大型目录损害性能。 Linux有点臭名昭着，因为没有很好地处理大目录问题。 VxFS可以快速处理多达100K个文件/目录，其中ext2 / ext3 / reiserfs通常在此之前开始减速。 这是迁移目标文件系统select不当的一个方面，可能会严重影响您的备份性能。
这就是说，如果这是你的问题，那么进出这些目录的普通旧访问也应该受到损害。 打开一个文件的时间可能是80ms，而最终用户几乎感觉不到210ms，但它应该在那里。