系统技术非业余研究

我们的mysql官方网站在这里:http://mysql.taobao.org, 正式对外开放了.
目前介绍了下我们目前在做的工作, 研究方向,以及部分资料可以下载, 后续我们会提供经过生产系统验证的mysql binary下载, 敬请期待!
截屏如下:

玩得开心!

昨天有同学在使用sysbench时候遇到了点小麻烦：

$ sysbench --test=oltp --oltp-table-size=100000000 --oltp-read-only=off --init-rng=on --num-threads=16 --max-requests=0 --oltp-dist-type=uniform --max-time=1800 --mysql-user=root   --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=simple prepare
sysbench 0.4.12:  multi-threaded system evaluation benchmark

FATAL: unable to connect to MySQL server, aborting...
FATAL: error 1049: Unknown database 'sbtest'
FATAL: failed to connect to database server!
...

错误提示说：mysql连接不上， sbtest库没找到。

首先确认mysql是正常的…

$ mysql -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 91
Server version: 5.1.48-debug-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use sbtest;
ERROR 1049 (42000): Unknown database 'sbtest'

但是库 sbtest确实不存在。

通过查看sysbench-0.4.12/sysbench/drivers/mysql/drv_mysql.c:400行

  DEBUG("mysql_real_connect(%p, \"%s\", \"%s\", \"%s\", \"%s\", %u, \"%s\", %s)",
        con,
        host,
        args.user,
        args.password,
        args.db,
        args.port,
        args.socket,
        (MYSQL_VERSION_ID >= 50000) ? "CLIENT_MULTI_STATEMENTS" : "0"
        );
  if (!mysql_real_connect(con,
                         host,
                         args.user,
                         args.password,
                         args.db,
                         args.port,
                         args.socket,
#if MYSQL_VERSION_ID >= 50000
                          CLIENT_MULTI_STATEMENTS)
#else
                          0)
#endif

我们可以看到sysbench在连接的时候需要先连接到sbtest库，但是库不存在，所以出现问题。

解决问题的方法很简单：
在mysql的shell下运行：

create database sbtest;

搞定。

小结：开源软件总是有点小问题，自己动手丰衣足食！

玩得开心！

ulimit最初设计是用来限制进程对资源的使用情况的，因为早期的系统系统资源包括内存,CPU都是非常有限的，系统要保持公平，就要限制大家的使用，以达到一个相对公平的环境。以下是典型的机器默认的限制情况:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 204800
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 204800
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

但是很多年过去了，情况发生变化了，硬件在过去的时间里面发展的非常迅猛，一个拥有几十个核心的，上百G内存的机器差不多也是白菜价格了。但是软件的限制还是没怎么发生变化，导致一系列使用的问题。其中很重要的文件句柄使用限制尤为明显。

特别是类似web服务器，数据库程序等需要大量的文件句柄，一旦开太小，比如默认(1024),在句柄使用完毕的时候，系统就频繁出现emfile错误
，这时候系统很容易陷入不可用。但是如果设定太大了，又会有这样的副作用。很多服务器程序是事件派遣的，比如说用epoll，程序在启动的时候通常会根据最大的文件句柄数来预留内部的slot，比如说Erlang一个slot貌似要占用几K的资源，如果你设定文件句柄数目太大，就可能无端的浪费了几百M内存。所以要正视这个问题，设定一个合适的值。

通常我们是在shell下用来ulimit -n NNNN来设定新开的进程的文件句柄的限制，但是在一个生产环境下会有如下麻烦：

$ ulimit -n 22222222
-bash: ulimit: open files: cannot modify limit: Operation not permitted
$ sudo ulimit -n 22222222
sudo: ulimit: command not found

JulyClyde(julyclyde@gmail.com)同学介绍解释了这个问题：

shell里不能直接更改，是因为登录的时候pam已经从limits.conf中设置了上限，ulimit命令只能在低于上限的范围内发挥了。

这时候我们通常需要修改/etc/security/limits.conf

# 确认包含下面的内容：
* soft nofile NNNNN
* hard nofile NNNNN

修改后，重现登录shell, 用ulimit -Hn和ulimit -Sn确认修改已生效.

另外淘宝雕梁说：

在linux kernel 2.6.25之前通过ulimit -n(setrlimit(RLIMIT_NOFILE))设置每个进程的最大打开文件句柄数不能超过NR_OPEN (1024*1024),也就是100多w(除非重新编译内核)，而在25之后，内核导出了一个sys接口可以修改这个最大值(/proc/sys/fs /nr_open).具体的changelog在这里

直接在你自己的程序里面绕开文件句柄的限制。

祝大家玩得开心！

我在最新的ubuntu11.04下编译leveldb的时候发现问题,但是在更早前的这个版本很正常：

yufeng@yufeng-laptop:/usr/src/leveldb$ make
g++ -c -DLEVELDB_PLATFORM_POSIX -I. -I./include -std=c++0x -g2 db/db_bench.cc -o db/db_bench.o
In file included from ./port/port.h:14:0,
                 from ./util/coding.h:17,
                 from ./db/dbformat.h:13,
                 from ./db/db_impl.h:9,
                 from db/db_bench.cc:8:
./port/port_posix.h:14:22: fatal error: cstdatomic: 没有那个文件或目录
compilation terminated.
make: *** [db/db_bench.o] 错误 1

Read more…

前段时间google的工程师提出对tcp的拥塞窗口的初始值进行增大可以显著的提高http的性能，这个主要是针对tcp的slow start的优化.
具体参考这里, 这里. 谢谢叔度同学从美国带回第一手信息!

由于低版本的linux内核的问题，这个参数的正确设置需要对os打patch,这个过程对线上机器来讲非常麻烦。 底下我用systemtap给出了个解决方案，免除这个麻烦. 我们在RHEL 5U4上作这个试验:
Read more…

具体会议信息请参看 http://ecug.org/

关于 ECUG Con

本站（ECUG.ORG）是 ECUG Con 大会的官方支持站点。

ECUG 成立于 2007-10-14 日的 CN Erlounge II。最初定位为 Erlang China User Group（Erlang中国用户组）。它是一个民间团体，致力于促进 Erlang 中文社区的交流，以发展和壮大 Erlang 中国社区（了解 “ECUG 社区的发展历程”）。

按照 ECUG 的计划，预计每年我们都会举行一次全国性的 ECUG Con 大会（原称：CN Erlounge 大会）。下面是历届的会议资料：

1. 2007年9月8日，CN Erlounge I，珠三角Erlang爱好者小聚。无会议资料，但酝酿了之后具有里程碑意义的 CN Erlounge II。
2. 2007年10月13~14日，CN Erlounge II （ECUG Con 2007）在珠海召开。金山为大会主要赞助方。
3. 2008年12月20~21日，CN Erlounge III（ECUG Con 2008）在上海召开。盛大网络为大会主要赞助方。
4. 2009年11月7~8日，CN Erlounge IV （ECUG Con 2009）在杭州召开。盛大网络为大会主要赞助方。

今年我们不再以 CN Erlounge V 命名本届大会，而改称为 ECUG Con 2010 大会。而 ECUG 的名字，也由 Erlang China User Group 改为 Effective Cloud User Group。之所以有此变动，原因如下：

这个修改主要为了以便符合我们对它原本的期望，也为了更清楚告诉大家大会准确意图。一直以来，我们在大会 Topic 征集时都在强调，我们关注的是并发模型和分布式开发的最佳实践。Erlang 语言的思想给了我们很大的启发1。然而我们并不希望局限于 Erlang 语言本身，所有的探索都应该被肯定，需要分享与发扬光大。

其实这个修改在去年的大会上我已经提出过，但是直到这一届才真正给 ECUG 这个会议正名，是因为当时会议准备工作已经差不多了，修改起来显得仓促。

今年我们将于10月16~17日举行的 ECUG Con 2010，亦可简称 ECUG 2010。
ECUG Con 2010 – 发起

* 时间：2010-10-16 ~ 2010-10-17，为期2天
* 地点：北京（详细待定）
* 议题： 研究、探讨、关注随着移动互联网的普及，以及用户的高速增长，我们需要什么样的分布式架构可以满足这种需求变化？话题以技术为主，并限制于并发、分布式开发相关的实践。另外，话题可不局限于服务端的高并发解决方案，客户端或者Web前端为了支撑高并发而作出的架构调整，也是非常有趣的话题。
* 面向人群：对多台机器协作，构成一个强大威力的超级计算机有痴迷，并愿意投入大量精力专研的人。
* 会议主持：ECUG 会务组

会议形式

* 多数时间由交流会讲师针对某个 Topic 进行论述，其他人提问（Q&A）方式交流。
* 留出一小段时间，安排沙龙式的对等交流机会。

会议规则

* 会议的讲师报销来回路费和住宿（申请成为讲师）。点击这里可以查看已经确定的讲师名单。
* 任何人可报名免费参与听讲（注册并申请参加本会议）。

注：由于场地限制，我们可能没法接受所有的与会申请，请谅解。如果名额已满，我们会回信说明。
重要时间点

1. 讲师注册及 Topic 征集截止日期：2010-9-5
2. 普通参会者报名截止日期： 2010-9-20
3. 讲师投稿截止日期：2010-9-25
4. 详细会议议程安排公布：2010-10-1
5. 会议日期：2010-10-16 ~ 2010-10-17

ECUG Con 2010 – Topic 征集
Topic范围

问题域：

1. 随着移动互联网的普及，以及用户的高速增长，我们需要什么样的分布式架构可以满足这种需求变化？
2. 多台机器一起协作，构成一个强大威力的超级计算机，这样的计算机应该是什么样子？

话题以技术为主，并限制于并发、分布式开发相关的实践。不局限于服务端的高并发解决方案，客户端或者Web前端为了支撑高并发而作出的架构调整，也是非常有趣的话题。

投稿请发往 ECUG 会务组。
讲稿建议

1. 内容有深度，而不是泛泛而谈。忌局限于一个事实或者一个实践，但是没有任何结论。
2. 内容有一个Focus的问题域。告诉大家你要解决什么问题，它又是如何被解决的。
3. 如果能够结合一个实际的应用实践，那是最棒不过了。

随着硬件技术的发展， CPU也越来越强大的。普通的服务器装配的Intel(R) Xeon(R) CPU E5520有4个core,每个core有32KL1D, 32KL1I, 256KL2，这些core还共享8M的L3。这些cache对提高系统的性能非常帮助， 因为L1的性能比主村高2个数量级。但是我们也看到L1 cache太小了，而且对程序员来讲是透明的，我们不知道它的存在。

那么我们的程序如何利用这些硬件设施呢。 设想下，如果你的4个core能同时工作，每个core又在充分利用自己的L1,L2, 同时L3还充满备用数据，那么这个提速是可以想象的到的。

这时候我们需要blocking technique技术：
看图不说话

这个技术的核心就是把数据集控制在L1的范围内，并发的多核计算！

有兴趣的同学可以进一步：
下载更详细的CISE-12-2-ScientificPro

玩的开心！