HPC上运行Tmap出现的BUG

HPC上运行Tmap出现的BUG

最近接到的任务，在HPC上处理一堆数据，但一个BUG让我损失了十分之一的算力。

系统环境：

Linux集群，输入输出在网络磁盘(浪潮1PB，raid6)，centos6.5，PBS，tmap和samtools

节点配置：

CPU： Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz X2

内存：125.7G

本地磁盘：200G

网络磁盘：656T （任务读写都在这）

症状：

node10 load高，但实际上程序是处于D的状态，load高是由于其他原因导致而不是CPU计算产生。而这个原因就是我想找的。

top -H 截图，tmap的进程基本都是D状态

节点表现：

ganglia node10 last day 截图

上图是node10一天之内的运行状态，mnode10 Load last day 中有明显的平台段，mnode10 Memory last day 中 Cache 的内存较多，正常。最有趣的是 CPU System，当 node10 上的进程进入D状态，CPU System 会慢慢提高，然后突然的到百分之十几，此时 CPU User 也突然升高，说明此时CPU在计算，而且一会儿就算完。后面就进入循环：得到下一个计算任务，继续D状态，过一到两个小时又突然开始计算，算完，得到下一个计算任务......

ssh 到node10查看top,刚打开时%us是23.7%，但马上又消失，top不会占用这么多CPU，而从iostat -xm中看到%user也是23.7%，而且是一直是。

top 打开的瞬间 截图

iostat -xm 截图

排查：

    1. cpu空闲量大，内存充足，本地磁盘和网络磁盘状态良好，没有zombie进程，iostat -xm反应的%user是个疑点。

    2. node10与其他的节点配置一样，但运行的状态异常，任务是由PBS分配，如果是任务有问题也不能总是node10出问题。

    3. node10是PBS最先访问的计算节点，在有任务、有资源的情况会优先使用node10。

结果：

        这个BUG还没有解决，但数据已经处理完毕，1月25日完成和预期比慢了3天。