问题：HPUX 服务器中 DB2 数据库的备份吞吐量突然从每小时 1TB+ 降至每小时 350GB。使用 Commvault 备份软件通过 10G 网络备份到介质代理。
故障排除完成：
数据库。我尝试使用相同的并行度、缓冲区数量和缓冲区大小（如通过 commvault）进行本机备份。我每小时的吞吐量约为 1TB+。因此，我认为 DB/DB 设置不是问题所在。
网络。网络团队检查发现端口的利用率非常低，不到 10G 的 0.5%。交换机上未报告任何错误。从 HPE Intelligence 管理中心检查发现，网络吞吐量与 commvault 显示的数据相符。
操作系统。备份期间我注意到 CPU 一直保持在 8% 左右，内存保持在 83% 左右。因此我不确定是否存在资源瓶颈。
备份软件（commvault）。使用相同备份磁盘库、相同存储策略、相同介质代理的其他备份客户端获得更高的吞吐量。因此，我认为备份软件不是问题所在。
我不确定我应该检查哪里，也不知道我该做什么。我真的需要有人建议我下一步该检查什么。我感觉瓶颈来自网络或操作系统方面。我已经回复操作系统和网络团队，但他们都回复说他们那边一切都很好。所以我别无选择，只能自己排除故障。
非常感谢你的帮助！
答案1
首先，确定是否有任何变化。您的帖子中的描述表明有多个团队参与管理此基础架构，他们之间可能没有很好地共享信息。找出吞吐量下降的确切时间并四处询问（如果您还没有这样做的话）。
接下来，让我们从 OSI 层的底部开始，然后逐步向上。首先弄清楚事物是如何连接在一起的，这样您就知道要检查什么。此连接是通过某个物理交换机还是某个服务器上的虚拟交换机进行的？如果一个端口的利用率不高，那么整体利用率如何？是否同时运行其他备份/同步？
之后，查找路径上的数据包丢失以及传输此数据的协议的其他问题。我假设连接是 TCP，因此请注意影响吞吐量的三大项，如 TCP 窗口大小、往返时间和可用带宽。数据包丢失等因素会导致 TCP 缩减并在每个窗口发送更少的数据。更高的延迟意味着潜在的下载速度更慢（等待 ACK 的每一毫秒都意味着不发送更多数据的时间）TCPDUMP 是您的好朋友，捕获一部分流量并进行检查。
接下来检查此连接中的两个端点，并重新检查它们是否因 RAM 或 CPU 负载而造成瓶颈。
最后，一些健全性检查项目。
1) 当您的备份未运行时，其他协议是否可以在相同端点之间以更快的速度下载？SMB？FTP？
2）在这种环境下是否存在备份性能不佳的历史？
3) 如果您需要支持，请向供应商开具一张票据。
假设中间没有其他变化，那么网络很可能参与其中。
答案2
Tommy，我刚看到这个帖子，想知道你最终是否找到了这个问题的罪魁祸首/解决方案。
我们在我们的中心（Linux/RHEL-7 上的 DB2 ESE 多节点）试验了同样的问题，DB2 的吞吐量只有 300-400 Mb……而我们试验的 Oracle PDB 的吞吐量在 1-2 Tb 之间！！所以如果你能提供你的发现，这将对我们研究的方向有很大帮助。提前谢谢。