我们首次在具有超过12个内核的机器上测试我们的软件以实现可扩展性,并且在添加第12个线程后我们遇到了令人讨厌的性能下降.在花了几天时间之后,我们对接下来要尝试什么感到困惑.
测试系统是双Opteron 6174(2x12内核),内存为16 GB,Windows Server 2008 R2.
基本上,性能从10到12个线程达到峰值,然后从悬崖上掉下来,并且很快就能以与大约4个线程相同的速率执行工作.下降相当陡峭,并且通过16到20个线程,它在吞吐量方面达到了底部.我们已经使用运行多个线程的单个进程和运行单个线程的多个进程测试了两者 - 结果几乎相同.处理相当耗费内存,并且需要大量磁盘.
我们相当确定这是一个内存瓶颈,但我们不相信它是一个缓存问题.证据如下:
- 当从12个线程扩展到24个线程时,CPU使用率从50%继续攀升至100%.如果我们遇到同步/死锁问题,我们会在达到100%之前将CPU使用率提高到最高水平.
- 在后台复制大量文件时进行测试对处理速率的影响非常小.我们认为这排除了磁盘i/o作为瓶颈.
- 提交费用仅为4 GB左右,因此我们应远低于分页成为问题的阈值.
- 最好的数据来自使用AMD的CodeAnalyst工具.CodeAnalyst显示,当使用24个线程时,Windows内核从占用12个线程的大约6%的CPU时间到占CPU时间的80-90%.绝大部分时间花在ExAcquireResourceSharedLite(50%)和KeAcquireInStackQueuedSpinLockAtDpcLevel(46%)函数上.以下是从运行12个线程到运行24时内核因素变化的亮点:
指令:5.56(倍数)
时钟周期:10.39
内存操作:4.58
高速缓存未命中率:0.25(实际高速缓存未命中率为0.1,4小于12个线程的时间)
平均缓存未命中延迟:8.92
总缓存未命中延迟:6.69
存储库负载冲突:11.32
存储库存储冲突:2.73
Mem转发:7.42
我们认为这可能是本文中描述的问题的证据,但是我们发现将每个工作线程/进程固定到特定核心并没有改善结果(如果有的话,性能变得更糟).
这就是我们所处的位置.关于这个瓶颈的确切原因或我们如何避免它的任何想法？