首先快速概述一下环境：
NetBackup 在配备 LTO3 驱动器的 Windows 服务器（如果您愿意的话，是 6.5.4）上运行。
备份目标曾经是 Sun 硬件上的 Solaris 9 服务器，带有 Veritas Volume Manger。
重建为 RHEL5 盒，使用 LVM 来管理卷，现在位于 Xiotech SAN 上。具有大量卷。
数据和盒子运行的应用程序 (Optix) 的性质是，它曾经写入卷，直到达到一定大小，然后该卷被永远锁定。因此我们有 \u01 \u02 \u03 ... \u50。不久前（仍然在 solaris 版本上），我们扩展并打开了这些卷以进行写入，因此在任何一天，它们中的任何一个或全部都可能发生变化。备份吞吐量过去平均为 40MB/秒。
在新的 Linux 版本中，我们的平均速度接近 8MB/秒。考虑到这里有 2.1TB 的数据，这有点令人无法接受，即使运行 4 个流也需要 48 小时以上才能完成。服务器上的 I/O 是固定的。我很确定这不是 SAN，因为使用相同存储类别和类似服务器硬件的其他客户端正在以缓慢但可以容忍的 20MB/秒的速度进行备份。
我正在寻找提高吞吐量的想法。隔壁办公室的 Solaris 人员将 LVM 归咎于 Linux。没有人认为这是备份环境的问题，因为它在其他地方仍然表现良好。现在非常慢的机器的管理员说：“我不知道这不是我的问题，用户说它很好。”这可能是真的，因为它是一个文档管理系统，他们正在读取和写入小文件。
解决问题的想法？有人见过 LVM 垃圾备份或其他 I/O 性能吗？尤其是考虑到有大量卷包含大量（可能 1000 万个）小文件？
已编辑以更正单位。
编辑后添加：
NIC 为 1000/Full（从操作系统和交换机检查）
文件系统是 EXT3。
更多新信息....
性能下降似乎发生在运行 LVM 和 EXT3 的几个机器上。基本上是我们今年夏天制造的所有新 RHEL5 机器。
答案1
您是否使用过 sar 或 iostat 在备份期间监控磁盘性能，以了解 Linux 对磁盘性能的看法？
那么使用某种基准测试实用程序来测试系统上文件的原始读取性能怎么样？我刚刚想到了这个，所以这可能是一个糟糕的方法，这实际上只是用于顺序读取，但是：
sudo dd if=/u1/some_large_file of=/dev/null
基本上，如果您使用基准测试实用程序复制读取所有小文件，您就可以知道它是否是磁盘，然后从那里开始。
以下内容不再相关：
如果您所说的 20 kb/s 指的是千比特，除非我因为时间太早而搞错了，否则您的数字对不上号。您说您在 20 kb/s 下有 2.1 TB：
即使只有 1 TB：
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
我是不是搞错了这些计算？（如果真是这样的话我一定会羞愧地删除我的帖子 :-)）
答案2
问题原来是 NetBackup 客户端版本问题，而不是 Linux/LVM 问题。当该机器重建为 Linux 机器时，安装了 6.5 客户端。今天，为了解决另一个问题，我们将客户端版本升级到 6.5.4。我又能以 25-27mb/秒的速度从机器中提取数据了。
我怎么可能忘记了 NetBackup 或任何备份软件的首要规则呢？确保您的客户端和服务器版本匹配如果你有问题我不知道。也许我需要纹身。
答案3
您在 LVM 卷上使用什么文件系统？
这 1000 万个小文件是如何存储的——全部存储在一个目录中（或少数几个目录中），还是分散在许多目录和子目录？（“很多” 表示任意大的数字）
我问这个问题的原因是，有些文件系统在有数千个文件时会出现严重的性能问题。这就是其中之一可能的导致你的速度变慢。
例如，没有打开 dir_index 功能的 ext2 或 ext3（IIRC，dir_index 已经成为 ext3 上的默认设置好几年了。它有很大帮助，但并不能完全消除问题）。
您可以使用 tune2fs 来查询和/或设置 ext3 的 dir_index 功能。例如查询：
# tune2fs -l /dev/sda1 | grep 功能 文件系统功能：ext_attr resize_inode dir_index filetype sparse_super
如果您在该列表中没有看到 dir_index，那么您需要像这样打开它：
并设置：
# tune2fs -O 目录索引 /dev/sda1 tune2fs 1.41.8（2009 年 7 月 11 日）
（是的，tune2fs 仅通过打印其版本号来响应...并不费心告诉您操作是成功还是失败。不好，但如果失败，它可能会打印错误）
最后：如果这确实是问题所在，并且启用 dir_index 也无济于事，那么您可能需要考虑使用其他文件系统。XFS 是一种很好的通用文件系统，据我所知 ext4 没有这个问题。两者都是替代文件系统的合理选择（尽管 ext4 相当新，即使许多人使用它没有问题，但我还不确定我是否会在生产服务器上信任它）
答案4
LVM 本身实际上不应该对此产生影响。据我所知，LVM 位并非在每个元数据操作中都引用，这就是延迟发挥作用的地方。它位于内核的不同层。LVM 对挂载/卸载的影响大于对文件打开/关闭的影响。
更有可能的是 Craig 指出的大目录会影响性能。Linux 因不能很好地处理大目录问题而臭名昭著。VxFS 可以快速处理多达 100K 个文件/目录，而 ext2/ext3/reiserfs 通常在此之前就开始变慢。这是一个在迁移目标的文件系统选择不当会严重损害备份性能的领域。
也就是说，如果这是您的问题，那么对这些目录的普通访问也应该会受到影响。打开文件可能需要 80 毫秒和 210 毫秒，这对最终用户来说几乎察觉不到，但应该存在。