一小型项目中并行计算缓慢的问题排查（三） 完结

    经过几天的测试，最终的测试结果于2015年1月6日出来了，这次的测试结果还令人满意，同样一个任务当调用32个核心时所花费的时间是61899秒，而当调用64个核心来计算同样一个任务时所花费的时间为32659秒，与使用千兆网络相比万兆网络有明显的优势。

    两个计算节点，一个计算节点是32个核心，在之前的千兆网络中，采用32个核心与采用64个核心来计算同一个任务所花费的时间没有明显的区别，而这次采用万兆网络后，计算的时间几乎有一半的差别，这说明，此次并行计算系统中的瓶颈的确是网络造成的。在最开始给客户推配置时，因只有两个计算节点，公司考虑到成本原因，就没有推万兆网络或IB网络，所以才造成了这项目的问题。通过这次问题也给自己提了一个醒，在以后的高性能系统中，计算节点只要是超过一个的，那计算节点与计算节点间的网络首先IB网络，在预算不足，计算节点数较少时才选择万兆网络（不知道在怎样的计算规模或多少个计算节点时万兆网络也会成为瓶颈）。

    但在测试结果出来后的第二天，我去客户处取测试交换机时，也现场提交了一个调用64个核心的任务，并在两个计算节点上收集了一些数据，包括万兆网卡流量的监视数据及系统负载的数据。下图是两个计算节点上网卡的流量监视图：

上边的这两张图是在我提交一个调用64核心计算任务后大约5分钟后的截图，从图中的数据来看网络的带宽也就跑到了近400Mbps左右，这与千兆网络中截图的数据差不多，这远远不是万兆网络的速度极限，看起来也就是一个千兆网络的带宽，这一点的确是很奇怪，这样为什么呢？

    在抓取上边两张图时，我分别在两个计算节点上用top命令都查看过两个计算节点的cpu都是满负荷的工作，且一旦把任务停止后，两网卡上的流量就减少到10kbits/s左右，所以，网卡是在正常工作着的，但为什么在速度上没有体现出万兆网卡的优势，而测试结果又让人认可呢？

    难道是lammpps软件在并行计算时不是每个时候对带宽的要求都是那么苛刻，只是在计算到某些步骤时高带宽才能发挥出他的优势，也就是说在某些时间里并行环境中计算节点间的通信会使用到高带宽。这只是我的猜测而已！

    这次我还提取了top命令的输出结果，也对比过用top与“mpstat -P -ALL”命令的输出，上一次在用这两个命令输出系统的cpu利用率时发现top中显示cpu的利用率在90%左右，但用“mpstat -P ALL”输出每个核心的利用率时，几乎每个核心的利用率都不高，是在30%左右，但这次用“mpstat -P -ALL”查看每个核心的利用率时发现每个核心的利用率都在70%左右，较之前有了明显的提升，而在top命令中按“1”（数字一）也显示出每个核心的高利用率。这种现象又该如何解释？

    从技术的角度讲，此系统的问题已得到解决。从千兆网更换到万兆网后，在用32个核心与64个核心计算同一个任务所得到的时间也几乎是随着核数的加倍，计算所花费的时间减半。但在这个过程中所发现的一些性能数据中的现象让我无法解释，所以写在这里，若以后有机会深入研究并行计算的知识再来作答。

    完！！！