系统技术非业余研究

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

霸爷，我看你在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…

今天曲山同学在线上问道：

我测试发现，如果cp一个文件，然后direct io读这个文件，会消耗很长时间。
我猜测dio不能用page cache，而这个文件cp以后都在cache里面，要强制刷到磁盘，才能读？
我cp这个文件很大，超过256M

由于数据文件默认是用bufferedio方式打开的，也就是说它的数据是先缓冲在pagecache里面的，写入的数据会导致大量的脏页，而且这部分数据如果内核内存不紧张的话，是一直放在内存里面的的。我们知道directio是直接旁路掉pagecache直接发起设备IO的，也就是说在发起IO之前要保证数据是先落地到介质去，所以如果文件比较大的话，这个时间会比较长。从pagecahce的回写行为我们可以知道，只要脏页的数量不超过总内存的10%, 我们的机器有4G的内存，所以2个100M的文件总共才200M，不会导致writeback发生，我们可以很顺利的观察到这个现象。

有了上面的分析，下面我们来重现下这个问题。以下是我的步骤：
Read more…

今天在内核群里印风同学问了个问题：

某台机器的ulimit -t 不知道为啥是300， 这是不是意味着程序占用CPU 300秒后会收到SIGKILL ？
我用gdb跑mysqld 跑了一会，收到SIGKILL信号，没有配置cgroup，也没啥后台脚本，看了下，就ulimit -t 比较诡异，其他机器都是unlimited。

简单的man ulimit下手册说：

-t The maximum amount of cpu time in seconds

貌似限制的是CPU最大执行时间，以秒为单位。
为了验证上面的说法，我特地设计了以下的场景：我们首先运行一个死循环程序消耗CPU时间，同时把进程的最大CPU消耗时间设定在180秒，期待在这个时间点进程会被杀掉。
以下是验证过程：

$ uname -r
2.6.32-131.21.1.tb477.el6.x86_64
$ ulimit -t 180
$ ulimit -t
180
$ cat busy.c
int main(int argc, char *argv[]) {
  for(;;);
  return 0;
}
$ gcc busy.c 
$ time ./a.out 
Killed

real	3m0.029s
user	2m59.966s
sys	0m0.007s

从现象来看，3分钟后我们的busy进程确实被杀了，dmesg也没说什么原因被杀。
Read more…

今天4月份在高阳同学的IO协议栈相关的PPT里面发现了这张图，最终来源 http://www.thomas-krenn.com/en/oss/linux-io-stack-diagram/linux-io-stack-diagram_v0.1.pdf，忍不住还是贴了出来。

这张图很清晰的把linux IO协议栈的层次给勾出来了，而且内容很与时俱进，特别是SCSI设备的层次对大家理解sg3这样的包非常有帮助，强烈推荐大家好好研习！

祝玩得开心！

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

玩得开心!

刚@淘宝雕梁 告诉我 GLIBC 2.16 支持systemtap静态检查点，消息源在这里， 摘抄相关部分如下：

* New configure option –enable-systemtap builds SystemTap static probes
into libc for setjmp and longjmp and into libpthread for various operations.
So far the setjmp/longjmp probes and some of the libpthread probes are
provided only for i*86 and x86_64.
Implemented by Roland McGrath and Rayson Ho.

目前主要是在setjmp/longjmp和pthread相关的锁操作，而且只支持 i*86 and x86_64 平台。我们到源码验证下：
Read more…