问题现象
在执行 OceanBase 数据库的 NFS 介质单副本恢复任务时，首次尝试从 23:41 开始至次日 09:27 结束，耗时 9 小时且最终任务失败。在任务失败后，更换了恢复的时间点重新发起恢复任务，并发度调整为 1，第二次恢复仅耗时 30 分钟即完成，符合预期的恢复时间。
关键信息
在恢复过程中，服务器日志显示了大量的拉日志超时错误。
使用相同的文件和测试程序，测试场景为 16 线程并发操作同一个文件，每个线程执行逻辑为
stat->open->read->close指定文件，NFS 路径上的完整执行流程需要 42 秒，而本地文件系统上仅需 5 毫秒。NFS版本如下图所示。
问题原因
根因是 NFS 与操作系统存在兼容性问题，对于恢复中的一个特定场景：多线程 open 同一个文件后 read，会出现类似 open 时间随并发度逐渐增加的现象。
使用引起并发 open read 的脚本测试，结果如下。
此问题并非由 OceanBase 产品本身的 BUG 引起，而是与外部存储介质的性能相关。
问题的风险及影响
物理恢复较慢或失败，可能导致数据恢复延迟，影响业务连续性和数据可用性。
适用版本
非 OceanBase 产品 BUG，受外部环境影响。
解决方法
联系 NFS 厂商确认并解决 NFS 访问速度慢的问题。
或者更换为其他性能更稳定的存储介质。
确认备份恢复介质后，可先用 ob_admin 提供的验证 OBServer 节点到备份介质的读写性能的 io_adapter_benchmark 提前确认对象存储的性能，主要关注
read/write/read_user_provided这几类测试的性能。read_user_provided命令在 OceanBase 数据库 V4.4.0/V4.3.5 BP3/V4.2.5 BP5 版本开始提供。
规避方式
更换存储介质，选择性能更为稳定可靠的存储解决方案。
对于 ARM 架构的 NFS 客户端，考虑使用 x86 架构的机器作为 NFS 客户端，以避免类似问题的发生。
