引出问题
在trafodion的环境中,sqcheck是检查各服务装态的工具。正常情况下,sqcheck的速度很快,10s左右就能出结果,一般结果如下图所示。
但是,有时候你会发现sqcheck很慢,可能需要等待1min以上才能出结果。那么sqcheck慢到底是什么原因呢?
问题分析
定位到sqcheck慢的原因jps
首先,通过which sqcheck查看文件那在哪个位置,然后检查sqcheck是二进制文件还是文本文件,经过检查发现是文本文件并且是shell脚本。
所以,我们可以通过shell脚本的调试方式来调试并观察慢主要在哪一个步骤。
以下是脚本的调试:
$ sh -x sqcheck
...
+ /usr/bin/pdsh -R exec -w esggy-clu-n010.esgyn.cn -w esggy-clu-n011.esgyn.cn -w esggy-clu-n012.esgyn.cn -w esggy-clu-n013.esgyn.cn ssh -q -n %h /usr/lib/jvm/java-1.8.0-openjdk.x86_64/bin/jps
我们调试发现,sqcheck慢的主要原因是通过jps获取各节点进程状态。所以我们可以判断可能是jps慢,但是具体哪个节点慢还是每个节点均慢我们需要通过以下方式进行判断。
切换到各节点,然后使用jps命令获取进程信息。最后,我发现其中的一个节点jps命令执行非常慢,这是导致sqcheck慢的罪魁祸首。现在已经比较明确了,其中一个节点的jps慢,接下来就是分析为什么只有这个节点的jps慢。
jps命令慢的问题分析调查
首先,检查是否其他linux命令也很慢,经检查发现其他的linux命令运行很快(一般秒出),所以可以判断不是操作系统cpu、内存等资源紧张导致的。为了进一步确定,通过top命令、free命令检查了cpu、内存等资源均非常空闲,所以排除是资源紧张引起的问题。此时,真有点不知从何下手了?后面有同事提到执行 ll /tmp很慢,的确/tmp下存在很多的小文件,遍历/tmp目录下的文件很慢,但是jps慢和这有什么关系呢?后面经过了解jps获取进程号信息是通过/tmp/sperfdata...目录下的信息。但是,如果我手动的找到对应的目录进入读取数据或者写入数据速度都很快,但是为了不放过一丝可能的机会,同事清理了/tmp目录下的文件,然后再次使用jps命令,速度瞬间飞了起来。哇,这是真的吗?真的和这个目录有关。后面再次分析如果jps是遍历了/tmp目录找到的对应的进程信息,这样的话就能够合理的解释这个问题。全凭想象,不过好在问题得到解决,希望这篇文章能帮助到遇到相同问题的朋友们。有兴趣的可以继续探索,如果有答案请别忘了告诉我,提前谢过。