LSF - bjobs频繁查询导致集群性能问题的debug分析

LSF - bjobs频繁查询导致集群性能问题的debug分析

问题描述

用户user00在使用lshosts, bhosts, bjobs等mbd命令查询时，会出现连接LSF timeout的情况，如下所示

...snippet ommitted...
28
ls_gethostinfo(): Communication time out
fail
29
ls_gethostinfo(): Communication time out
fail
...snippet ommitted...

或

LSF is processing your request. Please wait ...

问题分析

根据Diagnose query requests说明，LSF管理员查看对应的性能日志，发现有大量的bjobs查询来自于机器sz-host-aa-0001的用户user01。单用户查询，全局总计高达700次/分钟。

$ badmin diagnose -c query -f /tmp/debug #启动query的日志收集。
$ badmin diagnose -c query -o #2分钟后，停止日志收集。
$ #下面进行日志查看
$ wc -l /tmp/debug.querylog.<master_hostname>
1400
$ tail -1 /tmp/debug.querylog.<master_hostname>
Jul 29 11:01:39 2021 bjobs,user01,sz-host-aa-0001,110864,0x1A
$ #count by username whose position is 6.
$ awk -F ' |,' '{count[$6]++}END{for (user in count) {print count[user],user}}' /tmp/debug.querylog.<master_hostname> | sort -nrk1
500 user01
16 user02
...

找用户user01核对，他正在跑synopsys sentaurus TCAD任务，会在GUI上提交LSF任务。用户将任务停掉后，频繁的查询随后消失。可以确认是user01跑的synopsys sentaurus TCAD导致的频繁查询操作。

资料查看

根据Sentaurus™ Device User Guide 搜关键字Job Polling interval所描述，工具在提交LSF任务后，会以一定时间间隔取查询任务。该间隔默认是1次/s，可以手工设置。有三个作用范围，分别是Global level，site level与user level，优先顺序是Global level < site level < user level。

问题解决

由于本问题涉及的故障域其实是整个LSF集群，只是本问题刚好由某个工具触发了该故障。因此解决需要由两个方面入手：

• 一是本case涉及的工具侧解决；
• 二是LSF管理员需要设置查询频率限制，避免用户的不当查询导致集群性能问题。

解决详情：

• 工具侧解决：按照上述资料查看的方法，在Global level的配置文件中，设置成60秒一次查询。并且写一篇指导，供用户参考写user level的配置！样例略；
• LSF侧解决：根据Limit the number of batch queries所述，按照其介绍的方法设置即可。

问题延伸

发起大量query查询的，可能是用户的脚本、或工具调用的bjobs命令，也可能是调用了LSF的库，由库发起的查询。不同的场景需要不同的措施来应对。同时，研发环境要想健壮，必须考虑有小白用户或小白工具（这里说的小白工具，指的是发起密集query操作而不考虑整体集群性能的、不负责任的工具。这类工具通常是一些小创业公司开发的工具，他们往往只注重功能，不注重性能）的存在，因此管理员也需要做响应的优化——如限流。

总结

问题要找资料，总结以避免再次踩坑。

参考资料

https://www.researchgate.net/profile/Nabil_Ashraf2/post/How-to-obtain-photocurrent-and-incident-optical-power-to-calculate-responsivity-of-a-phototransistor/attachment/5a4372374cde266d587e004a/AS%3A576121978142721%401514369591383/download/Sentaurus_TCAD+manual.pdf