Erlang非业余研究

最近公司在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, 一步步来调查和解决问题。
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…

《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方面的折磨。
Read more…

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

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

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

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提供一个参考面！

祝玩得开心！

我们在研究内核的时候，看了内核代码后，就想着某个函数被谁谁调用。 调用路径有很多条，有热门的，有偏门的，但从代码不大容易看出。 如果我们能和gdb那样在函数上设个断点，看下内核函数的调用栈就清楚了。 但是如何统计热门路线呢？用systemtap就可以，参看这里， 这里。

但是用systemtap写统计的时候，用到统计功能的话，如果你的采样点非常多，超过systemtap规定的上线，systemtap会选择罢工，直接推出，很不爽。

kmalloc-top就是为了解决这个问题写的一个perl脚本，原本用来调查内核中kmalloc的使用情况的，在一个繁忙的内核中,kmallo每秒会被调用成千上万次，明显会超过处理的上限。 所以kmalloc-top的方法是stap部分只负责收集堆栈信息，收集一个就写到标准输出一个，然后由perl脚本来进一步分析统计。

脚本位于：/usr/local/share/doc/systemtap/examples/memory/kmalloc-top
Read more…

我在之前的博文提过Flashcache的cache是以set为单位管理的，每个set默认2M。 当单个set里面的脏页数量超过dirty_thresh_pct的时候，就会启动背景工作队列来把超过设置的脏页回写到后备磁盘去。 这里有别的同学对flashcache设计文档的翻译.

参看dirty_thresh_pct的文档解释：

dev.flashcache..dirty_thresh_pct = 20
Flashcache will attempt to keep the dirty blocks in each set
under this %. A lower dirty threshold increases disk writes,
and reduces block overwrites, but increases the blocks
available for read caching.

Flashcache之所以这样做的目的是当它在处理用户IO请求需要cache块的时候，保证马上可以拿的出来。因为读写的时候，如果需要的cache块不能满足的话，flashcache选择简单的绕过cache机制，直接走uncache io, 同时启动页面回收，一下子收回超过设置部分的页面，对性能有很大的损失。
特别是顺序写的时候，写一圈，再回绕在写的场合，性能特别差，就是这个原因。

那么如何保持一定量的可用cache块就很重要。通常cache数据都有冷热点，而且和时间很大关系。flashcache对冷热的判断是透过LRU类似的算法来判断的，这个是基于使用频度的维度。但是缺乏时间维度的判断。

新版本的flashcache引入了fallow_delay参数来解决这个问题，如果一个脏页超过fallow_delay秒，默认15分钟，都没有重新被访问到，那么数据就会被回写。 回写后，作为候选页面可以被新的cache重新利用。
Read more…