备份吞吐量突然从每小时1TB下降到350 1TB/小时。

Question

问题:在HPUX服务器中，1TB+数据库的备份吞吐量突然从每小时1TB+下降到350 in。使用Commvault备份软件通过10G网络对媒体代理进行备份。

已完成故障排除：

1. 数据库。我曾经尝试过使用相同的并行性、缓冲区和缓冲区大小来执行本机备份，比如通过commvault。我每小时的吞吐量大约是1TB+。因此，我不认为DB / DB设置是问题所在。
2. 网络。网络团队检查了端口只消耗了很低的利用率，低于0.5%的10G。开关上没有报告错误。从HPE智能管理中心检查，网络吞吐量与commvault显示的一致。
3. 奥斯。在备份期间，我注意到CPU一直在8%左右，内存在83%左右。因此，我不确定是否有任何资源瓶颈。
4. 备份软件(commvault)使用相同备份磁盘库、相同存储策略、相同媒体代理的其他备份客户端获得更高的吞吐量。因此，我认为备份软件不是问题所在。

我不知道该在哪里检查，也不知道该怎么做。我真的需要有人告诉我下一步该查什么。我有一种感觉，瓶颈来自网络或操作系统方面。我已经恢复到操作系统和网络团队，但都回复说，一切都好，从他们身边。所以我别无选择，只能自己解决问题。

非常感谢你的帮助！

Answer 1

首先，确定是否有任何变化。您的文章中的描述显示了管理此基础结构的多个团队，而且它们之间可能并不能很好地共享信息。找出吞吐量下降的确切时间，并询问一下(如果您还没有)。

接下来，让我们从这里的OSI层的底部开始，以我们的方式向上工作。先弄清楚事物是如何连接在一起的，这样你就知道该检查什么了。这种连接是通过某些物理交换机还是通过某个服务器上的虚拟交换机？如果一个端口利用率不高，那么总体利用率又如何呢？其他备份/同步是否同时运行？

在此之后，查找路径上的分组丢失以及传输此数据的协议的其他问题。我假设连接是TCP，所以请注意影响吞吐量的三大项，如TCP窗口大小、往返时间和可用带宽。像丢包这样的事情会导致TCP缩小，并且每个窗口发送的数据更少。较高的延迟意味着较慢的潜在下载速度(等待ACK的每个ms意味着没有发送更多数据的时间) TCPDUMP是您的朋友，捕获一部分流量并检查它。

接下来，检查这个连接中的两个端点，并重新检查它们是否与RAM或CPU负载无关。

最后，一些健全检查项目。

1)当备份不运行时，其他协议能否在相同端点之间以更快的速度下载？SMB？FTP？

( 2)在这种备份性能较差的环境中，是否存在一些历史？

3)与卖主一起开一张票，如果你有支持的话。

如果两者之间没有其他变化的话，网络很可能会参与其中。

Answer 2

汤米，找到这条线索，想知道你是否终于找到了解决这个问题的方法。

我们在我们的中心(LinuxRHEL-7上的DB2 ESE )实验同样的问题，DB2的吞吐量只有300-400Mb.当我们为Oracle PDB在1-2TB之间进行实验时！因此，如果能提供你的发现，它将对我们的研究方向有很大帮助。提前谢谢。