ecFlow笔记：使用SSD盘保存ecFlow生成文件

NWPC 目前使用四个 ecFlow 服务，分布在 CMA-PI 业务分区的两个登陆节点上：

• login_b01 上运行 nwpc_op（确定性业务系统），nwpc_qu（准业务系统）和 nwpc_pd（后处理系统）
• login_b02 上运行 nwpc_qu_eps（集合预报系统）

在业务高峰时段，即 00 时次运行的 13:00 - 14:00 之间，使用 ecflow ui 监视系统时经常出现无法获取服务运行状态的情况。

在 ecflow ui 中显示效果如下图所示：

虽然这个问题之前也一直存在，只要等待一会儿就可以再次看到系统的运行状态。 但 7 月 21 日整个一下午的时间都无法连接作业数较多的 nwpc_pd 和 nwpc_qu_eps 两个服务，严重影响运维工作，也导致产品出现延迟。

我一直怀疑界面卡住的现象与磁盘IO性能有关，但缺乏足够的证据。

之前写的两篇文章尝试分析定时任务为什么没有启动，很可能与界面卡住的原因类似。

《ecFlow笔记：定时任务没有启动 - 排查》

《ecFlow笔记：定时任务没有启动 - 分析》

本文介绍最近两天在信息中心的配合下，我们进行的一些尝试。

分析

下图以 GRAPES GFS 后处理系统为例说明 NWPC 数值预报业务系统 ecFlow 的目录结构。

ecFlow 的 ecf 脚本和 include 文件保存在用户分区 /g1/u 中。 可执行程序和绘图脚本也保存在该分区中。

ecFlow 运行任务时生成的 job 文件和 job 脚本运行的标准输出和标准错误输出重定向文件保存到另一个分区 /g3 中。 系统的运行目录，即生成数据产品和图片产品的目录，也在 /g3 分区中。

界面卡住的一个可能原因就是 ecFlow 服务根据 ecf 脚本和 include 文件生成 job 文件的时间太长（超过阈值 4 秒）。 根据之前两篇文章的分析，NWPC 使用的 ecflow 服务在生成 job 文件的同时不会响应客户端请求。

生成 job 超时的原因可能有多种：

• 从 /g1/u 中读取脚本速度慢
• ecflow 服务内部进行预处理速度慢
• 将 job 文件写入到 /g3 中速度慢

想要找到问题的根源，就需要控制变量进行对比试验。

方案

在信息中心的支持下，我们终于有机会验证上面的第三点是否是导致 job 生成超时的主要因素。

我们将 ECFOUT 目录迁移到挂载 SSD 固态硬盘的 /g0 目录下。 为了保持业务系统稳定性，将 /g3 目录下的 ECFOUT 改为指向 /g0 的软连接。

下图是更新后的 ecFlow 目录设计图。 相对于现有方案，仅将 ECFOUT 目录迁移到新的分区中。

效果

通过统计 ecFlow 日志中记录生成 job 超时的记录个数来判断迁移到 SSD 是否有效果。

超时记录如下所示：

WAR:[13:53:59 14.5.2020] Job generation for task /meso_post/09/meso_togrib2/grib2WORK/019/pre_data2grib2_019 took 4633ms, Exceeds ECF_TASK_THRESHOLD(4000ms)

nwpc_pd 从 7 月 21 日 12 时次开始切换到 /g0。 下图是 7 月 1 日到 23 日的作业生成超时数。 21 日明显比之前增加很多，切换目录后 22 日和 23 日仅有个位数的超时任务。

nwpc_qu_eps 从 7 月 23 日 00 时次开始切换到 /g0。 下图是 7 月 1 日到 23 日的作业生成超时数。 同样可以看到 21 日和 22 日有明显的增加，而 23 日因为没有超时作业，在图中没有显示。

结论

虽然仅有一天的对比，但可以明显看出，将 job 文件保存目录 ECFOUT 切换到 SSD 固态硬盘分区后，作业生成超时现象几乎不再发生。

说明 “将 job 文件写入到 /g3 中速度慢” 是作业生成超时的主要原因。

但也应该注意到，nwpc_pd 依然有个别的任务生成 job 超时，这可能与剩下的两个因素有关，有待进一步研究。