Erlang非业余研究

大型的服务器，特别是数据库服务器的主要瓶颈主要在内存，CPU，以及IO上。CPU是可再生资源，不够用等等就有了；内存和土地一样是不可再生资源，被占用了，后续的使用必须等到该资源释放.而IO也非常依赖于内存的使用情况,故内存的倒腾效率会大大影响服务器的效率,那么了解服务器内存的使用情况就非常重要。

Linux内核的内存相关的信息主要有下面几个获取管道，这里我们主要讨论的是系统级别的，没具体到各个进程级别：

1. 内核启动时候，VM内存相关模块初始化信息，透过dmesg查看。
详细描述可参考这里
比如：

NUMA: Using 30 for the hash shift.
Bootmem setup node 0 0000000000000000-0000000340000000
Bootmem setup node 1 0000000340000000-0000000640000000
On node 0 totalpages: 3095549
DMA zone: 2613 pages, LIFO batch:0
DMA32 zone: 765896 pages, LIFO batch:31
Normal zone: 2327040 pages, LIFO batch:31
On node 1 totalpages: 3102720
Normal zone: 3102720 pages, LIFO batch:31
…
Memory: 24543920k/26214400k available (2547k kernel code, 612792k reserved, 1289k data, 208k init)
…
Total HugeTLB memory allocated, 0
…

2. /proc/meminfo。
每个字段的意思，可参考这里
比如：
Read more…

下午和周忱同学折腾复杂程序的内存泄漏问题，用了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不交钱不能用这个服务的，只能自己下载包安装。
Read more…

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

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

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

Read more…

微博上的@拉风_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内存里面，不会涉及到磁盘。

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

我们知道内核的模块在分配资源的时候，为了提高效率和资源的利用率，都是透过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提供一个参考面！

祝玩得开心！

昨天@淘宝雕梁 同学推荐了无锁的内存分配器，上网站粗粗的了解了下，这家叫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下！
未完待续！

祝玩得开心！