服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 相同的硬件/软件，性能差异显着
Intereting Posts
vsftp：为什么是allow_writeable_chroot = YES是个好主意？ 组www-data拥有的文件夹中的权限 更改基于Cookie的虚拟主机DocumentRoot？ 当文件存在时，如何有条件地设置SSLCertificateFile？ 如何从crontab调用perl？ PTRlogging只添加在IP所有者方？ 没有在DNS区域文件？ LUN和卷之间有什么区别？ 哪个registry项对应于“作为服务login”？ 转发systemd日记邮件/收集systemd日记邮件 有一个相当于Sigverif.exe的命令行吗？ Nginx忽略WordPresslogin目录的HTTPauthentication 检查Exchange2010服务器上的背压 在Linux上启动时创build一个SNMP事件 在同一个dockernetworking中的另一个容器的发布的暴露端口上拒绝访问 如何通过selinux允许80端口自定义程序

相同的硬件/软件，性能差异显着

介绍

我有两组机器， A组和B组 ，显然具有相同的硬件/软件configuration，但性能有显着差异。 集合B中的机器比集合A中的机器速度高达x4 。但是， 如果我重新启动集合A中的一台机器 ，莫名其妙地开始按预期执行，就像集合B中的机器一样。我找不到这种行为的解释。

硬件configuration

  • 英特尔S2600KP平台
  • 双处理器E5-2630v3物理核心，2.4GHz基频，3.2GHz Turbo频率。
  • 8x8GB RAM DDR4 DDR4,2133Mhz，每个通道一个模块
  • 机器中没有任何BMClogging的SEL事件可能指向硬件问题。
  • 在整个基准testing期间，机器都没有触发任何机器检查exception。

所有硬件组件在型号/部件号中都是相同的。

设置和软件

  • BIOS版本和BIOS设置是相同的，例如启用HT ， Turbo Boost启用。 详情请参阅链接。

  • 这些机器运行与内核2.6.32-504相同的64 bits版本的Red Hat 6 。

问题

两台机器都是闲置的，但无论我尝试运行的负载如何，在性能方面我都会得到不同的结果。 为了简单起见，我将运行核心0上的所有基准。结果在所有内核（两个处理器）上都是可重现的。

设置A. 

 [root@SET_A ~]# uptime 11:48:40 up 51 days, 19:34, 2 users, load average: 0.00, 0.00, 0.00 [root@SET_A ~]# taskset -c 0 sh -c 'time echo "scale=5000; a(1)*4" | bc -l > /dev/null' real 0m43.751s user 0m43.742s sys 0m0.005s

设置B. 

 [root@SET_B ~]# uptime 11:50:00 up 15 days, 19:43, 1 user, load average: 0.00, 0.00, 0.00 [root@SET_B ~]# taskset -c 0 sh -c 'time echo "scale=5000; a(1)*4" | bc -l > /dev/null' real 0m18.648s user 0m18.646s sys 0m0.004s

意见

在基准的整个持续时间内， turbostats报告核心0处于C0 Consumption状态以及在启用加速频率的情况下的P0 Performance状态。

设置A. 

 [root@SET_A ~]# turbostat -i 5 pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_% 3.15 3.18 2.39 0 3.26 0.00 93.59 0.00 40 46 49.77 0.00 0.00 0.00 46.45 22.41 0.00 0.00 0 0 0 99.99 3.19 2.39 0 0.01 0.00 0.00 0.00 40 46 0.00 0.00 0.00 0.00 29.29 12.75 0.00 0.00

设置B. 

 [root@SET_B ~]# turbostat -i 5 pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 CTMP PTMP %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_% 3.14 3.18 2.39 0 3.27 0.00 93.59 0.00 38 40 49.81 0.00 0.00 0.00 46.12 21.49 0.00 0.00 0 0 0 99.99 3.19 2.39 0 0.01 0.00 0.00 0.00 38 40 0.00 0.00 0.00 0.00 32.27 13.51 0.00 0.00

简化的基准

为了尽可能简化基准testing（没有FP，尽可能less的内存访问），我写了下面的32位代码。 

 .text .global _start _start: movl $0x0, %ecx oloop: cmp $0x2, %ecx je end inc %ecx movl $0xFFFFFFFF,%eax movl $0x0, %ebx loop: cmp %eax, %ebx je oloop inc %ebx jmp loop end: mov $1, %eax int $0x80 .data value: .long 0

它只是将寄存器从0递增到0xFFFFFFFF两次，没有别的。

设置A. 

 [root@SET_A ~]# md5sum simple.out 30fb3a645a8a0088ff303cf34cadea37 simple.out [root@SET_A ~]# time taskset -c 0 ./simple.out real 0m10.801s user 0m10.804s sys 0m0.001s

设置B. 

 [root@SET_B ~]# md5sum simple.out 30fb3a645a8a0088ff303cf34cadea37 simple.out [root@SET_B ~]# time taskset -c 0 ./simple.out real 0m2.722s user 0m2.724s sys 0m0.000s

x4的差异来增加一个寄存器。

更多的观察与简化的基准

在基准testing期间，两台机器上的中断次数是相同的， ~1100 intr/s （用mpstat报告）。 这些主要是CPU0上的本地定时器中断，因此中断源基本没有区别。

设置A. 

 [root@SET_A ~]# mpstat -P ALL -I SUM 1 01:00:35 PM CPU intr/s 01:00:36 PM all 1117.00

设置B. 

 [root@SET_B ~]# mpstat -P ALL -I SUM 1 01:04:50 PM CPU intr/s 01:04:51 PM all 1112.00

对于P-States和C-States持有同上。

性能分析

设置A. 

  Performance counter stats for 'taskset -c 0 ./simple.out': 41,383,515 instructions:k # 0.00 insns per cycle [71.42%] 34,360,528,207 instructions:u # 1.00 insns per cycle [71.42%] 63,675 cache-references [71.42%] 6,365 cache-misses # 9.996 % of all cache refs [71.43%] 34,439,207,904 cycles # 0.000 GHz [71.44%] 34,400,748,829 instructions # 1.00 insns per cycle [71.44%] 17,186,890,732 branches [71.44%] 143 page-faults 0 migrations 1,117 context-switches 10.905973410 seconds time elapsed

设置B. 

  Performance counter stats for 'taskset -c 0 ./simple.out': 11,112,919 instructions:k # 0.00 insns per cycle [71.41%] 34,351,189,050 instructions:u # 3.99 insns per cycle [71.44%] 32,765 cache-references [71.46%] 3,266 cache-misses # 9.968 % of all cache refs [71.47%] 8,600,461,054 cycles # 0.000 GHz [71.46%] 34,378,806,261 instructions # 4.00 insns per cycle [71.41%] 17,192,017,836 branches [71.37%] 143 faults 2 migrations 281 context-switches 2.740606064 seconds time elapsed

意见

  • 内核空间指令的数量由于导致重新调度的控制path而不同。 除了最终的sys_exit以外，没有涉及任何系统调用。 显然，集合A的上下文切换的数量更高。
  • 用户空间指令（ ~10M ）也有很小的差异。 这可能是由于上述原因造成的？ 导致重新计划的说明被认为是用户空间。 或中断上下文中的指令？
  • 集合A的指令总数增加了0.06% ，但是L3 cache references的数量是双倍的。 这是预期的吗？ 快速检查cachingconfiguration会导致相同的结果。 caching正确启用（ CR0: 0x80050033 ，CD为0）和MTRRconfiguration是相同的。
  • 可能最有趣的值是每个周期的内容。 在组A上每循环1次，在组B上每循环4次 。

最后的问题

  • 有没有一个明显的原因可以解释这种性能差异？

  • 为什么Set A中的机器每循环运行1次，而Set B中的机器每循环运行4次，考虑到硬件/软件configuration是相同的？

  • 为什么重新启动机器似乎可以解决这个问题？ 正如介绍中所解释的那样，如果我在集合A中重启一台机器，它将按照预期开始执行。

这里的原因或者太微不足道，我错过了它，或者太复杂，无法解释。 我希望这是前者，任何帮助/提示/build议表示赞赏。

当然，如果有人能够给出一个答案，可以立即解决你的问题，那将是非常好的。 但是我担心，没有明显的答案。 但是可能还有一些攻击这个问题的方向还没有尝试：

  1. 在这个假设下，你的一些机器有时会performance出行为，而其他人从来没有这样做过，可以得出微妙的硬件问题（零星的，通过系统诊断手段无法察觉）。 相反的假设是，这可能发生在你的任何机器上。

    • 第一步：确保机器的所有部件都能被追踪。
    • 步骤2：挑选一些被称为“好”的机器，并运行一些“坏”机器的硬盘驱动器，看看效果是否显示。
    • 第3步：控制步骤。 用“好”的硬盘运行坏的机器，看看问题是否出现。

如果效果也显示在“良好”的机器上，那么安装（HD内容）或硬盘必须有细微的差异。

如果这个效果从来不会在“好”的机器上显示出来，那么“微妙的硬件问题”理论就会被证实。

  1. 寻找那些“真的，明显不能造成这种 – 永远不会！”的差异。 有一个关于通用汽车公司工程师的故事，是为了调查为什么一辆通用汽车的车主无法启动，只要该车的车主买了草莓冰淇淋，但从来没有在商店里买过香草……在你的情况下，好的和坏的机器被放置。 房间通风多，less？ 靠近一些窗户和阳光直射？ 距离某些电气设备越来越远（气候控制，…）？ build筑物的不同电源网？ 更多的东西连接到一些电源控制path/ USV？ 乍一看，我在这里build议的看起来似乎不太合理，但是，嘿，你的问题是相当零星的，对吗？ （50天的正常运行时间和您的机器在此期间“转”）。

把好的机器放在坏的地方，看看会发生什么。

  1. 作为一名embedded式软件工程师，我的一些更加痛苦的工作时间来自于在我的办公桌上交换“相同设备”的人……而我花了半天的时间 – 半个月时间试图找出为什么我的东西不能像以前那样工作之前，我已经离开了一夜…有时甚至一些组件（或软件/configuration版本闪闪发光）的最微小的修改可以有一些可观察到的影响。 在我的一些案例中，甚至连制造商都没有意识到这些“不重要的”变化 – 有时只是在某些PCB布局或者电容器供应商变成了第二个来源。

步骤1应该帮助find这些细微差别，确定哪些机器工作，哪些不工作。 第三步是find解释。

  1. 尝试评估“MTBF”并对其进行分析。 由于您可以清楚地看到机器何时开始减速，因此您可以测量机器减速所需的平均时间。 那么，如果不同的机器有不同的失败时间，如果时间聚集在一个值附近，或者根本没有任何模式（当它发生的时候是完全随机的），那么它可以是有洞察力的。