系统技术非业余研究

最近在不少项目特别是存储相关的项目用到了lz4压缩算法，它有什么特点呢？

LZ4 is a very fast lossless compression algorithm, providing compression speed at 300 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speeds up and beyond 1GB/s per core, typically reaching RAM speed limits on multi-core systems.

这个特性对于需要大吞吐量的压缩场合还是非常有用的，以很小的CPU代价换来更大的存储密度。

官方网站：https://code.google.com/p/lz4/， 摘抄下它的性能指标：

Name Ratio C.speed D.speed
LZ4 (r59) 2.084 330 915
LZO 2.05 1x_1 2.038 311 480
QuickLZ 1.5 -1 2.233 257 277
Snappy 1.0.5 2.024 227 729
LZF 2.076 197 465
FastLZ 2.030 190 420
zlib 1.2.5 -1 2.728 39 195
LZ4 HC (r66) 2.712 18 1020
zlib 1.2.5 -6 3.095 14 210

更多的测试可以看 这里 这里

它还有个高压缩率的版本：

LZ4 HC – High Compression Mode of LZ4

从源码lz4.c可以看到快的原因之一：

这个技术叫做 “The Blocking Technique”, 见图：

考虑在项目中用起来。

祝玩得开心！

最近关注线上CPU load的人挺多，很多人觉得load太高系统就有问题，就想各种办法来折腾。其实在我看来load只是系统CPU运行队列的在运行进程数的近似值, 如下图：

对于Unix发展的初期，机器的性能比较差，CPU核数也少，参考意义比较大。现在的机器都是非常强悍的，CPU，内存，IO各个部件都可以并行运作，这个load相应的就应该和机器的变化相应的变大，我觉得很正常，无需担心，反而应该把注意力放到服务的QPS和RT才是王道。

在微博上讨论了一下午CPU Load，收到非常多的反馈,这里我顺手整理下方便大家：

1. Understanding Linux CPU Load – when should you be worried? 谢谢@nizen靖
参考： 这里 中文版

2. Understanding Linux Load Average 谢谢 @jametong
参考：part1 part2 part3

3. UNIX Load Average 谢谢 @jametong
参考：part1 part2 part3

4. Loadavg问题分析 谢谢 @淘木名、 @淘伯瑜、 @何_登成
参考 这里

小结：群众的力量无穷，很短的时间内挖出这么多有意义的材料。

祝玩得开心！

前天有同学在博客上给我留言，表达了对做技术的迷茫:

霸爷，我看你在CU采访中提到“余锋认为技术是随着业务量的增加而逐渐成熟起来的，京东和苏宁等电子商业网站正在经历这个过程。”，你真的觉得京东正在经历淘宝N年前的过程吗。现在有个机会去应聘京东云计算中心，但是我觉得xx没有技术基因，不太靠谱，不怕xx起步晚，技术薄弱，就怕xx没有这个做出一番事业的心气。很羡慕淘宝的这种公司，但是无奈不能离开南京。喜欢技术，希望用8到10年的努力…

今天刚好收到正明写给核心系统的一封信很应景的解答了这个问题，我自己真的被感动到了，不敢独享和大家一起共勉：

在回顾的同时，我也希望有更多的创新从核心系统的土壤里成长起来，有更好的技术服务和产品提供给我们的集团业务。为此，我希望大家和我一起：
一、专注：做基础技术的专家
我们坚持选拔一流的人才，坚持做一流人才的乐土，坚持我们的技术理念，专注地去做集团最需要我们去做的事情，持续钻研，不断提升我们的技术能力。希望将来，核心系统的每一个人走出去，都能够成为各个领域的资深专家。
二、服务：做业务问题的解决者
不能够应用于业务的技术不是好技术。为此，我们必须更加强调我们的服务意识，去贴近和了解业务，学会从业务使用者的角度来考虑技术问题，真正深入到业务之中去，解决好业务问题和需求，会让我们的服务和产品更有竞争力和生命力。这对我们来说非常重要。
三、创新：做技术创新的领跑者
技术创新可以创造更大的价值。创新从哪里来？需要从我们做业务问题解决者的敏感嗅觉中来，从我们的专注精神、过硬的技术能力中来。我们要不断挑战自己，做别人做不了的事情，我们一定会是最有技术活力的团队！

我坚信，无论在那里做什么，坚持，服务，创新，创造价值，其他的东西自然都会来的。

Happy hacking!

原文地址：http://www.alibabatech.org/article/detail/3405/0?ticket=d69f07f8-b60b-43f8-9572-7d795bb8429d
作者：鸣嵩
PPT这里下载：

该文已在《程序员》2012年10期上发表。

MySQL作为一个低成本、高性能、可靠性好而且开源的数据库产品，在互联网企业应用非常广泛，例如淘宝网有数千台MySQL服务器的规模。虽然近两年来NoSQL的发展很快，新产品层出不穷，但在业务中应用NoSQL对开发者来说要求比较高，而MySQL拥有成熟的中间件、运维工具，已经形成一个良性的生态圈等，因此从现阶段来看，MySQL占主导性，NoSQL为辅。
在过去一年时间里，我们（阿里集团核心系统数据库团队）在MySQL托管平台方向做了大量工作，设计和实现了一套UMP(Unified MySQL Platform)系统，提供低成本和高性能的MySQL云数据服务。开发者从平台上申请MySQL实例资源，通过平台提供的单一入口来访问数据，UMP系统内部维护和管理资源池，以对用户透明的形式提供主从热备、数据备份、迁移、容灾、读写分离、分库分表等一系列服务。平台通过在一台物理机上运行多个MySQL实例的方式来降低成本，并且实现了资源隔离，按需分配和限制CPU、内存和IO资源，同时支持不影响提供数据服务的前提下根据用户业务的发展动态的扩容和缩容。

架构的演变
UMP系统第一版基于mysql-proxy 0.8版修复若干bug，并对proxy插件中管理用户连接和数据库连接的状态机流程进行一些修改，同时编写Lua脚本实现去中心数据库获取用户认证信息和后台数据库地址，对用户进行验证，建立到后台数据库的连接和转发数据包等逻辑。

图1 UMP系统的第一版采用MySQL Proxy

在开发和部署第一版的过程中，我们逐渐认识到几个问题：
Read more…

我们的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在这里

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

祝大家玩得开心！