系统技术非业余研究

MySQL和IO(上）在这里可以看到。

最近在把玩些高速的SSD和nvram设备的时候，发现iostat无法统计到这些设备的信息，很是奇怪，于是分析和总结了一把，挺有意思的。

现象描述如下：

# uname -a
Linux dr4000 2.6.32-131.17.1.el6.x86_64 #1 SMP Wed Oct 5 17:19:54 CDT 2011 x86_64 x86_64 x86_64 GNU/Linux
# ls -al /dev/nvdisk0
brw-rw-r– 1 root root 252, 0 Mar 10 16:18 /dev/nvdisk0
# iostat -d
Linux 2.6.32-131.17.1.el6.x86_64 (dr4000) 03/10/2012 _x86_64_ (24 CPU)

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 60.74 200.21 95.44 55171731 26299534

iostat很奇怪的看不到nvdisk0的IO统计信息.

开始我们的分析之旅，先简单的用strace看下iostat从那里读取这些统计信息的：
Read more…

大型的服务器，特别是数据库服务器的主要瓶颈主要在内存，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…