系统技术非业余研究

在做多线程程序的时候,为了避免使用锁,我们通常会采用这样的数据结构:根据线程的数目,安排一个数组, 每个线程一个项,互相不冲突. 从逻辑上看这样的设计无懈可击,但是实践的过程我们会发现这样并没有提高速度. 问题在于cpu的cache line. 我们在读主存的时候,数据同时被读到L1,L2中去,而且在L1中是以cache line(通常64)字节为单位的. 每个Core都有自己的L1,L2,所以每个线程在读取自己的项的时候, 也把别人的项读进去, 所以在更新的时候,为了保持数据的一致性, core之间cache要进行同步, 这个会导致严重的性能问题. 这就是所谓的False sharing问题, 有兴趣的同学可以wiki下.

具体的参考文章: http://software.intel.com/en-us/articles/avoiding-and-identifying-false-sharing-among-threads/

解决方法很简单:
把每个项凑齐cache line的长度,实现隔离.

typedef union {
    erts_smp_rwmtx_t rwmtx;
    byte cache_line_align__[ERTS_ALC_CACHE_LINE_ALIGN_SIZE(
				sizeof(erts_smp_rwmtx_t))];
} erts_meta_main_tab_lock_t;
或者 
_declspec (align(64)) int thread1_global_variable;
__declspec (align(64)) int thread2_global_variable;

这就是为什么在高性能服务器中到处看到cache_line_align, 号称是避免cache的trash.

类似valgrind和intel vtune的工具可以做这个层次的性能微调.

Read more…

我们在做高性能服务的时候，通常需要避免7宗罪，比如说内存拷贝，昂贵的系统调用等等。 但是这些罪的代价是多少，我们并不清楚。 在设计的时候，我们会需要根据数据去做方案的取舍。但是这些测量数据哪里来呢？ google大神是个很好的地方，但是有很多缺点，首先你需要的知识是分散的，第二你需要的知识是二手的。 这时候LMbench来救助了。

LMbench – Tools for Performance Analysis
官方网站： http://www.bitmover.com/lmbench/

What is LMbench? Read more…

看图不说话

参考： 图片来源

我们在做Linux服务器的时候经常会需要知道谁在做进程切换，什么原因需要做进程切换。 因为进程切换的代价很高，我给出一个LMbench测试出来的数字：
Context switching – times in microseconds – smaller is better
————————————————————————-
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
——— ————- —— —— —— —— —— ——- ——-
my174.cm4 Linux 2.6.18- 6.1100 7.0200 6.1100 8.7400 7.7200 8.96000 9.62000

在我的很高端的服务器上，进程切换的开销在8us左右， 这个相对于高性能的服务器是不可接受的， 所以我们要在一个时间片内尽可能的多做事情，而不是把时间浪费在无谓的切换上。

好奇害死猫，我们来调查下谁在切换我们的进程：

[root@my174 admin]# dstat 1
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  0   0 100   0   0   0|   0     0 | 796B 1488B|   0     0 |1004   128 
  0   0 100   0   0   0|   0     0 | 280B  728B|   0     0 |1005   114 
  0   0 100   0   0   0|   0     0 | 280B  728B|   0     0 |1005   128 
  0   0 100   0   0   0|   0     0 | 280B  728B|   0     0 |1005   114 
  0   0 100   0   0   0|   0   320k| 280B  728B|   0     0 |1008   143 
...

我们可以看到 csw的数目是 120/S, 但是dstat或者vmstat类似的工具并没有告诉我们谁在干坏事。好吧！我们自己动手行吧。
祭出我们可爱的systemtap!

[root@my174 admin]# cat >cswmon.stp
#! /usr/bin/env stap
#
#

global csw_count
global idle_count

probe scheduler.cpu_off {
  csw_count[task_prev, task_next]++
  idle_count+=idle
}


function fmt_task(task_prev, task_next)
{
   return sprintf("%s(%d)->%s(%d)",
                                task_execname(task_prev), 
                                task_pid(task_prev), 
                                task_execname(task_next), 
                                task_pid(task_next))
}

function print_cswtop () {
  printf ("%45s %10s\n", "Context switch", "COUNT")
  foreach ([task_prev, task_next] in csw_count- limit 20) {
    printf("%45s %10d\n", fmt_task(task_prev, task_next), csw_count[task_prev, task_next])
  }
  printf("%45s %10d\n", "idle", idle_count)

  delete csw_count
  delete idle_count
}

probe timer.s($1) {
  print_cswtop ()
  printf("--------------------------------------------------------------\n")
}
CTRL+D

这个脚本会每隔设定的时间打印出TOP 20切换最多的进程和他的pid, 我们来看下结果把：

[root@my174 admin]# stap cswmon.stp 5
                               Context switch      COUNT
                swapper(0)->systemtap/11(908)        500
                systemtap/11(908)->swapper(0)        498
                swapper(0)->fct1-worker(2492)         50
                fct1-worker(2492)->swapper(0)         50
                swapper(0)->fct0-worker(2191)         50
                fct0-worker(2191)->swapper(0)         50
                      swapper(0)->bond0(3432)         50
                      bond0(3432)->swapper(0)         50
                      stapio(879)->swapper(0)         26
                      swapper(0)->stapio(879)         25
                      stapio(879)->swapper(0)         19
                      swapper(0)->stapio(879)         17
                   swapper(0)->watchdog/9(31)          5
                   watchdog/9(31)->swapper(0)          5
                    swapper(0)->mysqld(18346)          5
                    mysqld(18346)->swapper(0)          5
                  swapper(0)->watchdog/13(43)          5
                  watchdog/13(43)->swapper(0)          5
                  swapper(0)->watchdog/14(46)          5
                  watchdog/14(46)->swapper(0)          5
                                         idle        859
--------------------------------------------------------------
...

我们可以看到进程从哪里切换到哪里，并且发生了多少次， 最后一行，我打印出来idle的次数，也就是说这时候系统没啥事情做，就切换到idle(0)这个进程去休息去了。

通过上面的调查，我们会很清楚的了解到我们系统的开销发生在那里，方便我们定位问题。
玩的开心！