原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: MYSQL数据库网卡软中断不平衡问题及解决方案

最近公司在MySQL的数据库上由于采用了高速的如PCIe卡以及大内存，去年在压力测试的时候突然发现数据库的流量可以把一个千M网卡压满了。随着数据库的优化，现在流量可以达到150M，所以我们采用了双网卡，在交换机上绑定，做LB的方式，提高系统的吞吐量。

但是在最近压测试的一个数据库中，mpstat发现其中一个核的CPU被软中断耗尽：

Mysql QPS 2W左右

——– —–load-avg—- —cpu-usage— —swap— -QPS- -TPS- -Hit%-
time | 1m 5m 15m |usr sys idl iow| si so| ins upd del sel iud| lor hit|
13:43:46| 0.00 0.00 0.00| 67 27 3 3| 0 0| 0 0 0 0 0| 0 100.00|
13:43:47| 0.00 0.00 0.00| 30 10 60 0| 0 0| 0 0 0 19281 0| 326839 100.00|
13:43:48| 0.00 0.00 0.00| 28 10 63 0| 0 0| 0 0 0 19083 0| 323377 100.00|
13:43:49| 0.00 0.00 0.00| 28 10 63 0| 0 0| 0 0 0 19482 0| 330185 100.00|
13:43:50| 0.00 0.00 0.00| 26 9 65 0| 0 0| 0 0 0 19379 0| 328575 100.00|
13:43:51| 0.00 0.00 0.00| 27 9 64 0| 0 0| 0 0 0 19723 0| 334378 100.00|

mpstat -P ALL 1说：

针对这个问题，我们利用工具，特别是systemtap, 一步步来调查和解决问题。

首先我们来确认下网卡的设置：

$uname -r
2.6.32-131.21.1.tb399.el6.x86_64

$ lspci -vvvv
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
        Subsystem: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 256 bytes
        Interrupt: pin A routed to IRQ 114
        Region 0: Memory at f6000000 (64-bit, non-prefetchable) [size=32M]
        Capabilities: <access denied>

01:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)
        Subsystem: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 256 bytes
        Interrupt: pin B routed to IRQ 122
        Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=32M]
        Capabilities: <access denied>

$cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: em1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: em1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 78:2b:cb:1f:eb:c9
Slave queue ID: 0

Slave Interface: em2
MII Status: up
Link Failure Count: 0
Permanent HW addr: 78:2b:cb:1f:eb:ca
Slave queue ID: 0

从上面的信息我们可以确认二块 Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)网卡在做bonding。

我们的系统内核组维护的是RHEL 6.1, 很容易可以从/proc/interrupts和/proc/softirqs得到中断和软中断的信息的信息。
我们特别留意下softirq, 由于CPU太多，信息太乱，我只列出7个核心的情况：

$cat /proc/softirqs|tr -s ' ' '\t'|cut -f 1-8
        CPU0    CPU1    CPU2    CPU3    CPU4    CPU5    CPU6
        HI:     0       0       0       0       0       0
        TIMER:  401626149       366513734       274660062       286091775       252287943       258932438
        NET_TX: 136905  10428   17269   25080   16613   17876
        NET_RX: 1898437808      2857018450      580117978       26443   11820   15545
        BLOCK:  716495491       805780859       113853932       132589667       106297189       104629321
BLOCK_IOPOLL:   0       0       0       0       0       0       0
        TASKLET:        190643874       775861235       0       0       1       0
        SCHED:  61726009        66994763        102590355       83277433        144588168       154635009
        HRTIMER:        1883420 1837160 2316722 2369920 1721755 1666867
        RCU:    391610041       365150626       275741153       287074106       253401636       260389306

从上面我们粗粗可以看出网卡的软中断接收和发送都不平衡。
单单这些信息还不够，还是无法区别为什么一个核心被压垮了，因为我们的机器上还有个中断的大户:fusionIO PCIe卡，在过去的测试中该卡也会吃掉大量的CPU，所以目前无法判断就是网卡引起的，因而我们用stap来double check下：

$cat i.stp
global hard, soft, wq

probe irq_handler.entry {
hard[irq, dev_name]++;
}

probe timer.s(1) {
println("==irq number:dev_name")
foreach( [irq, dev_name] in hard- limit 5) {
printf("%d,%s->%d\n", irq, kernel_string(dev_name), hard[irq, dev_name]);
}

println("==softirq cpu:h:vec:action")
foreach( 1 in soft- limit 5) {
printf("%d:%x:%x:%s->%d\n", c, h, vec, symdata(action), soft1);
}

println("==workqueue wq_thread:work_func")
foreach( [wq_thread,work_func] in wq- limit 5) {
printf("%x:%x->%d\n", wq_thread, work_func, wq[wq_thread, work_func]);
}

println("\n")
delete hard
delete soft
delete wq
}

probe softirq.entry {
soft[cpu(), h,vec,action]++;
}

probe workqueue.execute {
wq[wq_thread, work_func]++
}

probe begin {
println("~")
}

$sudo stap i.stp
==irq number:dev_name
73,em1-6->7150
50,iodrive-fct0->7015
71,em1-4->6985
74,em1-7->6680
69,em1-2->6557
==softirq cpu:h:vec:action
1:ffffffff81a23098:ffffffff81a23080:0xffffffff81411110->36627
1:ffffffff81a230b0:ffffffff81a23080:0xffffffff8106f950->2169
1:ffffffff81a230a0:ffffffff81a23080:0xffffffff81237100->1736
0:ffffffff81a230a0:ffffffff81a23080:0xffffffff81237100->1308
1:ffffffff81a23088:ffffffff81a23080:0xffffffff81079ee0->941
==workqueue wq_thread:work_func
ffff880c14268a80:ffffffffa026b390->51
ffff880c1422e0c0:ffffffffa026b390->30
ffff880c1425f580:ffffffffa026b390->25
ffff880c1422f540:ffffffffa026b390->24
ffff880c14268040:ffffffffa026b390->23

#上面软中断的action的符号信息：
$addr2line -e /usr/lib/debug/lib/modules/2.6.32-131.21.1.tb411.el6.x86_64/vmlinux ffffffff81411110
/home/ads/build22_6u0_x64/workspace/kernel-el6/origin/taobao-kernel-build/kernel-2.6.32-131.21.1.el6/linux-2.6.32-131.21.1.el6.x86_64/net/core/ethtool.c:653

$addr2line -e /usr/lib/debug/lib/modules/2.6.32-131.21.1.tb411.el6.x86_64/vmlinux ffffffff810dc3a0
/home/ads/build22_6u0_x64/workspace/kernel-el6/origin/taobao-kernel-build/kernel-2.6.32-131.21.1.el6/linux-2.6.32-131.21.1.el6.x86_64/kernel/relay.c:466

$addr2line -e /usr/lib/debug/lib/modules/2.6.32-131.21.1.tb411.el6.x86_64/vmlinux ffffffff81079ee0
/home/ads/build22_6u0_x64/workspace/kernel-el6/origin/taobao-kernel-build/kernel-2.6.32-131.21.1.el6/linux-2.6.32-131.21.1.el6.x86_64/include/trace/events/timer.h:118

$addr2line -e /usr/lib/debug/lib/modules/2.6.32-131.21.1.tb411.el6.x86_64/vmlinux ffffffff8105d120
/home/ads/build22_6u0_x64/workspace/kernel-el6/origin/taobao-kernel-build/kernel-2.6.32-131.21.1.el6/linux-2.6.32-131.21.1.el6.x86_64/kernel/sched.c:2460

这次我们可以轻松的定位到硬中断基本上是平衡的，软中断都基本压在了1号核心上，再根据符号查找确认是网卡的问题。

好了，现在定位到了，问题解决起来就容易了：
1. 采用多队列万M网卡。
2. 用google的RPS patch来解决软中断平衡的问题, 把软中断分散到不同的核心去，参见这里.

我们还是用穷人的方案，写了个shell脚本来做这个事情：

$cat em.sh
#! /bin/bash                                                                                                                                                           

for i in `seq 0 7`
do
  echo f|sudo tee /sys/class/net/em1/queues/rx-$i/rps_cpus >/dev/null
  echo f|sudo tee /sys/class/net/em2/queues/rx-$i/rps_cpus >/dev/null
done

$sudo ./em.sh

$mpstat -P ALL 1

就可以看到我们的成果：

网卡的软中断成功分到二个核心上了，不再把一个核心拖死。

小结：多观察系统是好事。
后记：

有同学留言说:

根据我们的测试，BCM5709应该是支持多队列的

从中断来看确实是平衡的，也就是说多队列在工作，但是为什么软中断不平衡呢，还有CPU1上还压着什么任务呢？继续调查！
待续～

祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: systemtap如何跟踪libc.so

下午和周忱同学折腾复杂程序的内存泄漏问题，用了valgrind, gogle perftools等工具都不大好用，很容易把应用程序搞死，于是打算用systemtap来在libc.so层面了解内存的使用情况。主要思路就是看malloc/realloc和free的调用次数的平衡。

首先准备下环境，系统是标准的RHEL 5u4：

$ uname -r
2.6.18-164.el5

$ stap -V
SystemTap translator/driver (version 1.3/0.137 non-git sources)
Copyright (C) 2005-2010 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: LIBRPM LIBSQLITE3 NSS BOOST_SHARED_PTR TR1_UNORDERED_MAP
$stap -L  'kernel.function("printk")'
kernel.function("printk@kernel/printk.c:533") $fmt:char const* $args:va_list

$ stap -L  'process("/lib64/libc.so.6").function("malloc")'
Missing separate debuginfos, use: debuginfo-install glibc-2.5-42.x86_64

内核的符号是OK的，glibc没有安装符号。系统提示用 debuginfo-install glibc-2.5-42.x86_64 命令安装符号信息，但是RHEL 5不交钱不能用这个服务的，只能自己下载包安装。

$ wget -c ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/x86_64/Debuginfo/glibc-debuginfo-2.5-42.x86_64.rpm
$ sudo rpm -i  glibc-debuginfo-2.5-42.x86_64.rpm
$ stap -L  'process("/lib64/libc.so.6").function("malloc")'
process("/lib64/libc-2.5.so").function("__libc_malloc@/usr/src/debug/glibc-2.5-20061008T1257/malloc/malloc.c:3560") $bytes:size_t

这次有了glibc的符号了，可以方便的跟踪libc.so中malloc的使用情况。
接着我们来简单的写个c程序调用malloc, 同时写个stap脚本来跟踪malloc的调用堆栈：

$ cat t.c
#include <stdlib.h>

void fun() {
  malloc(1000);
}

int main(int argc, char *argv[]) {
  fun();
  return 0;
}

$cat m.stp
probe process("/lib64/libc.so.6").function("malloc") {
if (target()== pid()) {
print_ubacktrace();
exit();
}
}
probe begin {
println("~");
}

$ gcc  -g t.c

$ stap -L 'process("./a.out").function("*")'
process("/home/chuba/a.out").function("fun@/home/chuba/t.c:3")
process("/home/chuba/a.out").function("main@/home/chuba/t.c:7") $argc:int $argv:char**

现在程序准备好了，那么我们来执行下看内存泄漏在那里：

$sudo stap m.stp -c ./a.out
~
 0x33d5e74b96 : malloc+0x16/0x230 [libc-2.5.so]
 0x4004a6 [a.out+0x4a6/0x1000]

我们看到在a.out的0x4004a6的地方地方调用了malloc, 但是具体在程序里面是哪行呢？ 用add2line就很容易找出来：

$ addr2line -e ./a.out 0x4004a6
/home/chuba/t.c:5
$ nl t.c
     1  #include <stdlib.h>

     2  void fun() {
     3    malloc(1000);
     4  }

     5  int main(int argc, char *argv[]) {
     6    fun();
     7    return 0;
     8  }

哈哈,
祝大家玩得开心。

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: 给你的Linux系统上点stress

《debug hacks》 这本书介绍了非常多的调试手段和工具， 其中提到了stress这个简单的压力测试工具，在我们的日常工作中很有用。利用它可以给我们的系统施加CPU，内存,IO和磁盘的压力，在模拟极端场景给应用系统造成的压力方面很有帮助。

主页见这里：http://weather.ou.edu/~apw/projects/stress/
这里还有一篇介绍如何使用的博客。

stress is a deliberately simple workload generator for POSIX systems. It imposes a configurable amount of CPU, memory, I/O, and disk stress on the system. It is written in C, and is free software licensed under the GPLv2.

这个stress实现非常的简单，所有的功能在一个.c文件里面实现， 系统运行的时候会fork多个子进程，分别进行CPU,内存，IO方面的折磨。

因为简单所以稳定。参考例子：

$ stress –cpu 2 –io 1 –vm 1 –vm-bytes 128M –timeout 10s –verbose
stress: info: [9372] dispatching hogs: 2 cpu, 1 io, 1 vm, 0 hdd
stress: dbug: [9372] (243) using backoff sleep of 12000us
stress: dbug: [9372] (262) setting timeout to 10s
stress: dbug: [9372] (285) –> hogcpu worker 9373 forked
stress: dbug: [9372] (305) –> hogio worker 9374 forked
stress: dbug: [9372] (325) –> hogvm worker 9375 forked
stress: dbug: [9372] (243) using backoff sleep of 3000us
stress: dbug: [9372] (262) setting timeout to 10s
stress: dbug: [9372] (285) –> hogcpu worker 9376 forked
stress: dbug: [9375] (466) hogvm worker malloced 134217728 bytes
stress: dbug: [9372] (382) <-- worker 9374 signalled normally
stress: dbug: [9372] (382) <-- worker 9373 signalled normally
stress: dbug: [9372] (382) <-- worker 9375 signalled normally
stress: dbug: [9372] (382) <-- worker 9376 signalled normally
stress: info: [9372] successful run completed in 10s

由于stress支持posix平台，简单的下载，编译和安装就好了, 很顺利！
按照文档默认的运行参数，让系统来点体验：

$stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10d
stress: info: [23176] dispatching hogs: 8 cpu, 4 io, 2 vm, 0 hdd

pstree可以看到：

nmon可以看到：

具体使用可以参考man stress！

祝大家玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: fio配合cgroup测试存储设备IOPS分配

随着包括存储设备在内服务器的能力越来越高，特别是用上了PCIe存储卡后，IOPS能力通常有10几万，马上过剩。在这种情况下，一台服务器可以干很多事情，在上面跑很多服务。那么如何保证系统的服务质量是个很重要的事情了。

我们在下来的的项目中倾向于用cgroup来做资源的隔离和限制，原因是cgroup的开销很小，而且很易用。cgroup 可以参考这里

我们特别关心cgroup的blkio子模块，他有2种限制模式:
1. throttle，限制每个进程能使用的IOPS或者吞吐量。
2. weight，现在每个进程能使用的IOPS的能力的比例，必须通过CFQ调度器来实现。
文档和具体的参数可以看上面提到的cgroup文档。

要使用blkio的weight限制需要注意几个事情：
1. 必须走directio, 如果buffered io因为最终写IO的进程不是发起IO的进程，结果会有很大的偏差。
2. 调度器必须是CFQ。
3. 测试工具必须支持cgroup的相关限制。
4. 最好是随机的IO。

新版本的支持cgroup的fio可以在这里下载 git clone git://git.kernel.dk/fio.git， 更多参看这里。

man fio下可以看看cgroup相关的文档:

cgroup=str
Add job to this control group. If it doesn’t exist, it will be created. The system must have a mounted cgroup blkio mount
point for this to work. If your system doesn’t have it mounted, you can do so with:

# mount -t cgroup -o blkio none /cgroup

cgroup_weight=int
Set the weight of the cgroup to this value. See the documentation that comes with the kernel, allowed values are in the
range of 100..1000.

cgroup_nodelete=bool
Normally fio will delete the cgroups it has created after the job completion. To override this behavior and to leave
cgroups around after the job completion, set cgroup_nodelete=1. This can be useful if one wants to inspect various cgroup
files after job completion. Default: false

这里只是粗粗演示下如何用fio按照比例来限制进程使用的IO, 我们来构造下场景：

我们在创建2个1g大小的文件，进行随机的混合读写，一个给500的比例，一个给100的比例，总的比例是1000。那么理论上可以看到A进程可以得到多于B进程5倍的IO能力。

操作如下：

$ cat test.fio
[global]
bs=4k
ioengine=libaio
iodepth=32
direct=1
rw=randrw
rwmixread=90
time_based
runtime=180
cgroup_nodelete=1

[test1]
filename=test1.dat
size=1G
cgroup_weight=500
cgroup=test1

[test2]
filename=test2.dat
size=1G
cgroup_weight=100
cgroup=test2

$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq] 

$ sudo fio test.fio
test1: (g=0): rw=randrw, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32
test2: (g=0): rw=randrw, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio 2.0
Starting 2 processes
Jobs: 2 (f=2): [mm] [5.5% done] [618K/90K /s] [151 /22  iops] [eta 02m:51s]
...

我们从另外一个终端可以看到IO能力的分配情况：

$ sudo lssubsys -am
cpuset
net_cls
perf_event
cpu /sys/fs/cgroup/cpu
cpuacct /sys/fs/cgroup/cpuacct
memory /sys/fs/cgroup/memory
devices /sys/fs/cgroup/devices
freezer /sys/fs/cgroup/freezer
blkio /sys/fs/cgroup/blkio
$ pgrep -x fio
3837
3839
3840
$ cat /sys/fs/cgroup/blkio/test1/tasks
3839
$ cat /sys/fs/cgroup/blkio/test2/tasks
3840
$ sudo iotop

差不多是5:1的比例，符合预期。

我们在使用的时候会担心kernel的稳定性，所以用fio能够大压力，长时间的来测试cgroup模块的可靠性，收集数据作为应用的参考。

祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Flash存储设备在淘宝的应用实践(2011年iDevOps系统技术沙龙）

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: SSD在淘宝的应用实践

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: 大文件重定向和管道的效率对比

微博上的@拉风_zhang提出了个问题：

@淘宝褚霸 请教个问题，#1. cat huge_dump.sql | mysql -uroot ；#2. mysql -uroot < huge_dump.sql ；#1效率要高，在linux中通过管道传输 和 < 这种方式有什么差别呢？谢谢！#AskBaye#

这个问题挺有意思的，我的第一反应是：

没比较过，应该是一样的，一个是cat负责打开文件，一个是bash

这种场景在MySQL运维操作里面应该比较多，所以就花了点时间做了个比较和原理上的分析：
我们先构造场景：
首先准备一个程序b.out来模拟mysql对数据的消耗：

$ cat b.c
#include <stdio.h>
int main(int argc, char *argv[])
{
  char buf[4096];
  while(fread(buf, sizeof(buf), 1, stdin) > 0);
  return 0;
}
$  gcc  -o b.out b.c
$ ls|./b.out

编译好再顺手我们的程序功能是正确的：纯消耗流。

再来写个systemtap脚本用来方便观察程序的行为。

$ cat test.stp
function should_log(){
  return (execname() == "cat" ||
      execname() == "b.out" ||
      execname() == "bash") ;
}
probe syscall.open,
      syscall.close,
      syscall.read,
      syscall.write,
      syscall.pipe,
      syscall.fork,
      syscall.execve,
      syscall.dup,
      syscall.wait4
{
  if (!should_log()) next;
  printf("%s -> %s\n", thread_indent(0), probefunc());
}

probe kernel.function("pipe_read"),
      kernel.function("pipe_readv"),
      kernel.function("pipe_write"),
      kernel.function("pipe_writev")
{
  if (!should_log()) next;
  printf("%s -> %s: file ino %d\n",  thread_indent(0), probefunc(), __file_ino($filp));
}
probe begin { println(":~") }

这个脚本重点观察几个系统调用的顺序和pipe的读写情况，

然后再准备个419M的大文件huge_dump.sql,在我们几十G内存的机器很容易在内存里放下：

$ sudo dd if=/dev/urandom of=huge_dump.sql bs=4096 count=102400
102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 63.9886 seconds, 6.6 MB/s

因为这个文件是用bufferio写的，所以它的内容都cache在pagecahce内存里面，不会涉及到磁盘。

好了，场景齐全了，我们接着来比较下二种情况下的速度：

$ time (cat huge_dump.sql|./b.out)

real    0m0.596s
user    0m0.001s
sys     0m0.919s

$ time (./b.out <huge_dump.sql)

real    0m0.151s
user    0m0.000s
sys     0m0.147s

从数字看出来速度有3倍左右的差别了，第二种明显快很多。

是不是有点奇怪？好吧我们来从原来上面分析下，还是继续用数据说话：

这次准备个很小的数据文件，方便观察然后在一个窗口运行stap

$ echo hello > huge_dump.sql
$ sudo stap test.stp
:~
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_pipe
     0 bash(26570): -> sys_pipe
     0 bash(26570): -> do_fork
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_close
     0 bash(26570): -> do_fork
     0 bash(13775): -> sys_close
     0 bash(13775): -> sys_read
     0 bash(13775): -> pipe_read: file ino 20906911
     0 bash(13775): -> pipe_readv: file ino 20906911
     0 bash(13776): -> sys_close
     0 bash(13776): -> sys_close
     0 bash(13776): -> sys_close
     0 bash(13776): -> do_execve
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_close
     0 bash(13775): -> sys_close
     0 bash(26570): -> sys_wait4
     0 bash(13775): -> sys_close
     0 bash(13775): -> sys_close
     0 b.out(13776): -> sys_close
     0 b.out(13776): -> sys_close
     0 bash(13775): -> do_execve
     0 b.out(13776): -> sys_open
     0 b.out(13776): -> sys_close
     0 b.out(13776): -> sys_open
     0 b.out(13776): -> sys_read
     0 b.out(13776): -> sys_close
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_close
     0 b.out(13776): -> sys_read
     0 b.out(13776): -> pipe_read: file ino 20906910
     0 b.out(13776): -> pipe_readv: file ino 20906910
     0 cat(13775): -> sys_open
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_open
     0 cat(13775): -> sys_read
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_open
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_open
     0 cat(13775): -> sys_read
     0 cat(13775): -> sys_write
     0 cat(13775): -> pipe_write: file ino 20906910
     0 cat(13775): -> pipe_writev: file ino 20906910
     0 cat(13775): -> sys_read
     0 b.out(13776): -> sys_read
     0 b.out(13776): -> pipe_read: file ino 20906910
     0 b.out(13776): -> pipe_readv: file ino 20906910
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_close
     0 bash(26570): -> sys_wait4
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_wait4
     0 bash(26570): -> sys_write

stap在收集数据了，我们在另外一个窗口运行情况1管道的情况：

$ cat huge_dump.sql|./b.out

我们从systemtap的日志可以看出: bash fork了2个进程，然后execve分别运行cat 和 b.out进程, 这二个进程用pipe通信，数据从由cat从 huge_dump.sql读出，写到pipe,然后b.out从pipe读出处理。

那么再看下情况二重定向的情况:

$ ./b.out < huge_dump.sql 

stap输出：
      0 bash(26570): -> sys_read
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_pipe
     0 bash(26570): -> do_fork
     0 bash(28926): -> sys_close
     0 bash(28926): -> sys_read
     0 bash(28926): -> pipe_read: file ino 20920902
     0 bash(28926): -> pipe_readv: file ino 20920902
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_wait4
     0 bash(28926): -> sys_close
     0 bash(28926): -> sys_open
     0 bash(28926): -> sys_close
     0 bash(28926): -> do_execve
     0 b.out(28926): -> sys_close
     0 b.out(28926): -> sys_close
     0 b.out(28926): -> sys_open
     0 b.out(28926): -> sys_close
     0 b.out(28926): -> sys_open
     0 b.out(28926): -> sys_read
     0 b.out(28926): -> sys_close
     0 b.out(28926): -> sys_read
     0 b.out(28926): -> sys_read
     0 bash(26570): -> sys_wait4
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_read

bash fork了一个进程，打开数据文件，然后把文件句柄搞到0句柄上，这个进程execve运行b.out，然后b.out直接读取数据。
现在就非常清楚为什么二种场景速度有3倍的差别：
情况1. 读二次，写一次,外加一个进程上下文切换。
情况二：只读一次。

小结： 越简单的事情，有时候越有意思！
祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Erlang R15B 全新的observer

新发布的R15B在亮点里面提到：

There is a new GUI tool in the observer application which integrates pman, etop, appmon and tv into one tool. The tool does also contain functions for activating tracing in an easy way.

这个observer完全用wx重新改写过，界面操作速度非常块，整合了几个常用的观察工具，很方便用户，我们来尝鲜下：

$ erl
Erlang R15B (erts-5.9) 1 [smp:2:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9  (abort with ^G)
1> observer:start().
ok

上截图：

系统信息:

Appmon:

Etop:

Tv:

Pman:

界面看起来很清爽！

祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: slabtop简单的用途

我们知道内核的模块在分配资源的时候，为了提高效率和资源的利用率，都是透过slab来分配的。我们通过slab的信息，再配合源码能粗粗了解系统的运行情况，比如说什么资源有没有不正常的多，或者什么资源有没有泄漏。

linux系统透过/proc/slabinfo来向用户暴露slab的使用情况的,我们来看下：

$ head /proc/slabinfo
slabinfo - version: 2.0
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <batchcount> <limit> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
msi_cache              2      2   3840    1    1 : tunables   24   12    8 : slabdata      2      2      0
ip_fib_alias          11    226     16  226    1 : tunables  120   60    8 : slabdata      1      1      0
ip_fib_hash           11    119     32  119    1 : tunables  120   60    8 : slabdata      1      1      0
dm_mirror            100    105   1052    7    2 : tunables   24   12    8 : slabdata     15     15      0
dm_mpath               0      0   1052    7    2 : tunables   24   12    8 : slabdata      0      0      0
dm_tio                 0      0     16  226    1 : tunables  120   60    8 : slabdata      0      0      0
dm_io                  0      0     20  185    1 : tunables  120   60    8 : slabdata      0      0      0
dm-bvec-(256)          0      0   3072    2    2 : tunables   24   12    8 : slabdata      0      0      0
...

其实还有更好的查看工具：slabtop很直观的可以看到slab使用情况和汇总，上图：

很清晰的为性能调优和trouble shoot提供一个参考面！

祝玩得开心！

原创文章，转载请注明： 转载自Erlang非业余研究

本文链接地址: Lockless Memory Allocator试用记

昨天@淘宝雕梁 同学推荐了无锁的内存分配器，上网站粗粗的了解了下，这家叫Lockless的公司主要有2个产品：
Lockless MPI 和 Lockless Memory Allocator， 我对内存分配器比较感兴趣，它对高性能服务器的影响还是非常大的,特别是mysql这样的服务器，看它的文档对性能的提升好像比较明显。

我们重点来了解下 Lockless Memory Allocator:

The Lockless Memory Allocator is downloadable under the GPL 3.0 License.

官网强调的特性：

Multithread Optimized
The Lockless memory allocator uses lock-free techniques to minimize latency and memory contention. This provides optimal scalability as the number of threads in your application increases. Per-thread data is used to reduce bus communication overhead. This results in thread-local allocations and frees not requiring any synchronization overhead in most cases.

官网做的和主流的几种分配器的性能比较：

详细的bechmark见这里，看上去让人挺印象深刻的。

代码在这里下载 http://locklessinc.com/downloads/， 支持32位和64位的Linux, 安装文档在这里

我们来尝鲜实验下：

$  wget http://locklessinc.com/downloads/lockless_allocator_src.tgz
$ tar xzf lockless_allocator_src.tgz
$ cd lockless_allocator
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC) 

$ make
/bin/sh -ec 'gcc -MM  ll_alloc.c | sed -n "H;$ {g;s@.*:\(.*\)@ll_alloc.c := \$\(wildcard\1\)\nll_alloc.o ll_alloc.c.d: $\(ll_alloc.c\)@;p}" > ll_alloc.c.d'
cc ll_alloc.c -fomit-frame-pointer -Wcast-qual -Wmissing-format-attribute -Wlogical-op -Wstrict-aliasing -Wsign-compare -Wdeclaration-after-statement -Wnested-externs -Wdisabled-optimization -Winline -Wundef -Wimplicit -Wunused -Wfloat-equal -Winit-self -Wformat=2 -Wswitch -Wsequence-point -Wparentheses -Wimplicit -Wchar-subscripts -Wredundant-decls -Wstrict-prototypes -Wbad-function-cast -Wpointer-arith -Wwrite-strings -Wno-long-long -Wmissing-declarations -Wmissing-prototypes -Wextra -Wall -pedantic -ggdb3 -std=gnu99 -O3  -fPIC -pthread -c -o libllalloc.o
strip -g libllalloc.o
ar rcs libllalloc.a libllalloc.o
ranlib libllalloc.a
cc ll_alloc.c -fomit-frame-pointer -Wcast-qual -Wmissing-format-attribute -Wlogical-op -Wstrict-aliasing -Wsign-compare -Wdeclaration-after-statement -Wnested-externs -Wdisabled-optimization -Winline -Wundef -Wimplicit -Wunused -Wfloat-equal -Winit-self -Wformat=2 -Wswitch -Wsequence-point -Wparentheses -Wimplicit -Wchar-subscripts -Wredundant-decls -Wstrict-prototypes -Wbad-function-cast -Wpointer-arith -Wwrite-strings -Wno-long-long -Wmissing-declarations -Wmissing-prototypes -Wextra -Wall -pedantic -ggdb3 -std=gnu99 -O3  -shared -fpic -Wl,-soname,libllalloc.so.1.3 -Wl,-z,interpose -o libllalloc.so.1.3
strip libllalloc.so.1.3

$ ls libllalloc.*
libllalloc.a  libllalloc.o  libllalloc.so.1.3

$ LD_PRELOAD=./libllalloc.so.1.3  erl
Erlang R14B04 (erts-5.8.5) 1 [64-bit] [smp:16:16] [rq:16] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.8.5  (abort with ^G)
1> 

#另外一个终端确认libllalloc.so.1.3在使用
$ lsof  -c beam.smp
COMMAND   PID           USER   FD      TYPE DEVICE     SIZE    NODE NAME
beam.smp 8458          chuba  txt       REG    8,5  2344032 3775338 /usr/local/lib/erlang/erts-5.8.5/bin/beam.smp
...
beam.smp 8458          chuba  mem       REG    8,6    40384  195304 /home/chuba/lockless_allocator/libllalloc.so.1.3
...

这里面有个问题： 编译的时候需要的gcc版本比较高，gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)编译不过。
之前tcmalloc就没通过erl的使用，因为erlang内部的指针的后4位被用了，如果分配器不遵守16字节对齐，就会出问题。

看了代码实现的也很简单，代码质量也一般，不知道具体的性能如何，后续找个案例benchmark下！
未完待续！

祝玩得开心！