Monthly Archives: June 2008

Unix/Linux 的 Load 初级解释

几乎每个接触类 Unix 操作系统的工程师都知道如何查看系统负载。但这东西的工作机理到底是怎样的，可能没有多少能说清楚。对比了一些相关信息，加上自己的理解，做一下笔记。

什么是 Load ? 什么是 Load Average ?

Load 就是对计算机干活多少的度量(WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度. Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。【最好的参考文章：UNIX® Load Average Part 1: How It Works】

下面是一个 uptime 命令输出：

$ uptime
 18:57:48 up 423 days,  3:55,  2 users,  load average: 1.16, 1.12, 1.20

尽管各种信息来源的定义都不太确定。能确定的一件事情是，你不能精确获取当前时间的 Load . 最小的计算粒度是 5 秒钟(CALC_LOAD 每 5HZ 计算一次, 5HZ 为 5秒钟，这里的 HZ 是系统定义的变量). 参见 Linux Kernel 这段代码:

 869        count -= ticks;
870        if (unlikely(count < 0)) {
871                active_tasks = count_active_tasks();
872                do {
873                        CALC_LOAD(avenrun[0], EXP_1, active_tasks); 
 874                        CALC_LOAD(avenrun[1], EXP_5, active_tasks);
 875                        CALC_LOAD(avenrun[2], EXP_15, active_tasks);
 876                        count += LOAD_FREQ;
877                } while (count < 0);
878        }
879}

如何判断系统是否已经 Over Load ?

对一般的系统来说，根据 CPU 数量去判断，如上面的例子，如果平均负载始终在 1.2 以下，而你是 2 颗 CPU 的机器。那么基本不会出现 CPU 不够用的情况。也就是 Load 平均要小于 CPU 的数量。

这是 Solaris 性能与工具(Solaris Performance Tools ) 一书推荐的评估方法。【在这里要推荐一下这本书，尽管在 Load 这个地方没有达到我期望的那么细致。但全书揭示了非常多的性能信息。每个 DBA、架构师的必须书。】

这么说实际上带来另外两个疑问：

1 如果是多核 CPU / 超线程的机器怎么判断? 对这样的机器，我的建议是看操作系统怎么识别的 CPU，根据系统识别出来的逻辑 CPU 数量来判断。如果要考虑性能系数，建议参考一下 Oracle 针对不同架构下多核 CPU 的收费标准。

2 如果应用是面向线程的怎么判断? 这实际上和 M:N 线程模型有关。你的系统是怎样的? 把这个问题考虑进去即可了。

多数情况下，Load 过高都未必和 CPU 有关。或许倒是有一个例外的，就是应用场景的问题。比如用单 CPU 的机器去做高并发 Web 服务器，麻烦就来了

Load 与容量规划(Capacity Planning)

任何一个相对成熟的站点都会利用 Cacti（基于RRDTool）等工具进行容量规划工作。抓取的 Load 会传 1、5、15 分钟列值过去，这三个度量采用哪个呢? 15 分钟为首选【参见Gunther 的 PPT】。

Load 与系统预警

很多对可用性要求比较高的环境都建立了邮件或SMS 报警机制。关于 Load 报警阈值的制定也有看到不太合理的时候。这里建议 Critical 值(如果用 Nagios 之类的工具你明白这是什么)上限为物理 CPU 的个数(当然你可以设置比这个低)。但比这个值高的话，意义就不大了。比如，数据库服务器有 4 颗 CPU，那么 Load 高于 4 就应该报警出来，设置比 4 高可能意义不大，因为接到报警还有个人为响应时间...

误解一：系统 Load 高一定是性能有问题。

真相：系统 Load 高也或许是因为在进行 CPU 密集型的计算(比如编译)

误解二：系统 Load 高一定是 CPU 能力问题或数量不够。

真相：Load 高只是代表需要运行的队列累积过多了。但队列中的任务实际可能是耗 CPU的，也可能是耗 I/O 乃至其它因素的。

误解三：系统长期 Load 高，首选增加 CPU。

真相：Load 只是表象，不是实质。增加 CPU 个别时候会临时看到系统 Load 下降，但治标不治本。

小小一个 Load 讲究其实不少。英文信息其实比较全的，尽量保证加入一点新信息到这篇文章里。入看到有写的不合理的地方或者有异议，请指正或告知。

--EOF--

FAQ 1：数据库服务器突然 CPU 100% 繁忙，咋办?

A ：一般情况下，这是由糟糕的 SQL 引起。建议抓取 Slow Query Log ，针对 I/O 开销比较大(重点看全表扫描）的 SQL 进行优化。根据经验值，每个 CPU Core 一秒钟能处理 100-400MB 数据量。如果是大量的并发 I/O 操作，尽管存储的吞吐可能还没那么大，也可能会把 CPU "塞满"。

看 Twitter 人谈架构扩展问题

前微软头号 Blogger Robert Scoble 采访 Twitter 的几个家伙。谈及 Twitter 的一些比较严重的问题。

谁来拯救大兵 Twitter ? 前几天看到新闻说他们请了 Pivotal 实验室来解决当前存在的问题。从这几天观察来看，好像并没有什么明显进展。也或许并非一时半刻就能完成吧。今年用的最多的 Web 2.0 服务就是 Twitter 了，没有了这东西还真的有些不习惯。

Twitter 的初期设计对消息采用了 Single Instance Storage (SIS)，这直接导致了消息持久化产生了数据库单点问题(?) . 每一种设计思路应该都有其理由。旁观者清也只是没介入到那个环境吧。接下来 Twitter 会做什么? Sharding ?

这个视频更像是 Twitter 不服气外界质疑而进行的宣传。其实 Twitter 的一些扩展性问题对 Web 2.0 站点来说是个绝佳的案例，有正面的成长参考，也有为错误买单的痛苦。或许这才是主要吸引我们关注它的地方。

–EOF–

JDBC 的 setTimestamp 性能问题

偶然发现三年前的一个技术问题。当时比较匆忙，避免掉即过去了。现在 Metalink 上其实已经把这个问题作为一个 Bug 处理了。

问题描述：通过 JDBC 上来的 Java 查询应用，SQL 表现异常。表字段使用了 DATE 类型，针对该字段时间区域很小的范围查询(预期应该是走 INDEX RANGE SCAN)，在 SQL Map 上指定索引，发现无效。仍然是 FULL TABLE SCAN (FTS)。

罪魁祸首：setTimestamp() 把值绑定为 TIMESTAMP 类型，这样和 DATE 类型比较的时候，CBO 就会选择全表扫描。

通过 Trace 能观察到该异常行为。TIMESTAMP 在 Oracle 的 JDBC 9.2.0.1 上就有了，连续几个版本其实都有类似的问题。

解决办法：使用 setString() 而不是 setTimestamp() 方法。

这个故事告诉我们，Oracle 的 JDBC 驱动程序其实问题挺多的。同样，TIMESTAMP 潜在的问题也不少，尽管这个数据类型已经出现多时。

–EOF–

InfoQ 数据库架构采访文字修正稿(2)

书接上文。视频请访问 InfoQ。

InfoQ中文站: 在 Web 2.0的时代，海量数据对于越来越多的开发者来说，已经不再是一个遥不可及的话题了，可能随便哪一个访问量很大的Web2.0网站都有可能拥有令人咂舌的数据量，那么对于这种网站，除了对数据库存储进行优化，除了缓存，然后还有那些策略？

Fenng: 我觉得可能主要是在存储方面会有一些大的挑战。比如存储的可靠性，像以前就有过 BSP服务商对客户的数据居然没有备份，导致了很多用户损失了一段时间之内的数据，这样总体来说对网站的声誉有很大影响、对用户的体验也很糟糕。

随着互联网的飞速发展，数据总体来说是趋于膨胀性的，在这个过程中，如何把数据有效的存储，并且有效的获取，便是个比较复杂的问题。我们前面说了太多 Web 2.0相关的话题，【换个角度】比如说我所在的公司支付宝，也面临着这样的大数据量、海量数据的挑战。当前我们的一个策略，也是沿袭 SOA 的战略化思想，就是数据库相关的数据服务进行一定的 SOA 化处理。另外一个比较重要的策略就是数据生命周期的管理，我们对这样的，在数据生命周期已经完成后，会对相关的数据做一些归档化的处理，再进行二级存储或者分级存储。那么话说回来，对一些 Web 2.0 网站，我觉得也可以运用这样的思想机制: 对用户已经不大可能访问或者访问频率比较低的（数据），采用分级存储，或者额外做一些访问策略的制订，是很有必要的。

InfoQ中文站: 我们也听说过另外一种分片数据库机制，那么请你谈谈分片这种策略是怎么样一种策略？

Fenng: 分片总的来说，它不是一种比较新的技术， MySQL 在 5 .x 版本之后，有了分区功能。那么在这之前，MySQL 是没有分区功能的。当时如果需要处理一些比较大的数据量，比方说要对根据时间对数据进行历史化处理，就会比较麻烦。人们可能是因地制宜，就产生 Sharding 这样技术策略。

严格来说，数据分片其实在我们以前也有一些相关的实践，在其他(类型)的数据库上，我们也会有一些历史策略，只是当时这个名词没有完全定义下来。据我所知，这个词是从大型在线游戏中发展出来的。大部分用户会集中在某个区域。这一部分集中在某个区域的用户，会把他们放在特定的服务器上。不同区域之间的用户之间的关联度可能不大，这个场景和我们现在的数据库分片策略其实是非常非常相似的，我们当前如果对数据库做一些分片，也会采用这样的基本思想，比如说根据不同的用户 ID 范围，或者说不同的地区(来分片)。

如果建的是商务网站，可能根据产品的类型来做，我们会把不同产品类型的数据扔到不同的 DB上，这些 DB 之间的关联度是很小的。然后我们在 DB 之间，可能会有一个封装层，在这个封装层之上，对应用程序用户来说，就像是透明的，那么就达到了我们数据库上高度扩展化的目标。

InfoQ中文站: 那分片这种策略有什么利弊吗？

Fenng: 首先，分片的好处还是很容易看到的。起码我们的 DB 能达到不依赖于某个单点，而这样能做到平滑的扩展，就像大家常说的 Scale Out (横向扩展)机制。它的弊端也是比较明显，对于事务高速处理这样的网站，它有它的自己的不足之处，事实上好多朋友也应该知道，一个事务如果跨数据库，这样对设计者，对编码人员来说，还是比较棘手的。那么如果一个事务如果跨两个甚至多个 DB，Sharding 复杂度就会很高。Sharding 在业界的应用场景基本上也就是这种读应用比较重的情况，而且对事务的安全性要求不高，这样的场景会非常适合。

【上个月写了篇 Sharding 的东西给《程序员》，还不知道什么时候发表出来】

InfoQ中文站: 目前在许多网站的架构设计中有绝大多数的项目在持久化方面就是采用数据关系映射（ORM）的方式。大家对于这种高负载的大规模网站应用来说，你觉得存在哪些应用呢？

Fenng: 首先一点，我想拿我们支付宝来说，ORM 大家觉得用得非常好。在一个相对比较大的开发环境，对开发团队来说，它的弊端可能就不大容易看出来。因为我们用的是 ORM，就很容易把中间 DB 这层完全隔离出来。然后把这一层的 SQL 处理交给专门的 DB 人员—-我们这边还有专门的开发DBA，由他们来专门对这层进行集中的监控管理，乃至一些规划类的工作。这样开发工程师还有架构师这边，他们可以集中精力在其他方面做更多的投入，一个比较大的团队中我觉得像 ORM 这些还是很容易能看到好处的。

【ORM 还有个比较好的地方在于安全性，能有效减少 SQL 注入的隐患】

在另一方面，我们看一下它的弊端，因为像一些 Web 中小网站，可能相对人手也比较少，大家用的(开发)工具(或框架)呢，可能像 PHP、 ROR 这些东西，也就是在开发上，上手又比较容易的。那么这个时候，事实上一个潜在的问题是，当代码规模到一定程度，如果没有去做一些 ORM，那么可能会给网站带来一些潜在的比如说代码管理上的问题，这一点只是我的个人看法，实际上大家在具体的应用场景可能会有各自头疼的问题，我在这方面不是专家，也仅供大家参考。

InfoQ中文站: 那你所做的支付宝，其实是企业级别的应用，在企业级别应用所采用的这种架构策略和一般 Web 2.0 网站所采用的这种架构策略会有什么异同？

Fenng: 事实上，很明显的一点，支付宝其实业务是非常复杂的【也有一部分人误解支付宝业务很简单】，这和我们很多的Web2.0公司不大一样，Web2.0它可能从一个点切入进去。在这一点上，我觉得做得比较透。支付宝呢，它可能有点像我们以前做的一些通用软件，他要考虑不同的行业、不同的用户、还有像买卖之间，与这么多银行之间的关系等等，这个复杂度还是很大的。

这实际上就从一定程度上决定了我们和 Web 2.0 公司截然不同的应用解决方案，像当前我们在支付宝，在一年之前，甚至两年之前就已经考虑，把我们的整个网站 SOA 化、组件化。在这个过程中，也考虑了一些像 Web 2.0 中的技术元素，但总体的思路呢，还是说向SOA 化，向面向服务这方面大步的跨进，然后就从 SOA 这一点，事实上很多 Web 2.0 公司，他们未必能完全的实现，完全的做到这样的面向服务化，我觉得这可能是两者截然不同的一个表面特点。

另外，像支付宝也在尝试做一些，对外部客户、服务提供一些接口，甚至完全开放的一个平台，这一点又和我们当前这些像 FaceBook ，或者是说，像美国的 MySpace 这样的社交区、SNS 网络了有一些共通之处。

InfoQ中文站: 那目前在 Web 2.0 网站这个领域里面，网站的架构主要有哪些趋势，下边还将有怎么样一个走向呢？

Fenng: 其实作为一个技术人员，每当要谈到趋势，肯定要给大家笑。从中长期来看，国内的一些 Web 2.0 新服务逐渐涌现出来了，随着发展，我相信会有更多的商业化元素加进来。像以前是好多 Web 2.0 公司是完全使用开源的技术，伴随规模扩大化，一些以前提供开源技术的组织或个人他们会尝试进行一些商业化的运作。商业化并不是个坏事情，一方面给我们提供更好的服务。另一方面，他们得到了足够的商业支持，反过来之后他们又会对整体的开源开发环境、发展环境起到很好的促进。我相信在未来的两到三年之内，会有一部分的商业公司涌到 Web 2.0 的发展生态圈里面。

然后从技术方面来讲，像前面几个月 MySQL 被 Sun 收购，起码是在 Web 2.0 这样的软件链条中的一个重要环节(MySQL),有些人可能会感觉出了一些问题。但现在像在数据库这一层呢，也不排除像 PostgresSQL 这些其它的数据库，趁这个机会被商业公司所拥抱，他们也会做出一些更大规模的应用场景出来。在数据库这方面可能会限制大家，几家开源数据库形成一个僵局，Sun 在……这个有些扯远了，还是绕回来。像现在很多的 Web 2.0 公司，他们对 Web 服务器这方面也会采用一些比较新的，像 Nginx，我觉得在起码在接下来的一段时间内会吸引绝大多数公司长期、大规模的去使用它、去拥抱它，甚至为它开发一些更激动人心的新特性。

【这段时间比较热炒的开放平台、云计算也或许能给我们带来一些思路：很多有技术积累的的公司都有自己打造一套底层的架构的意图，比如针对存储层面向应用的虚拟化等。】

InfoQ中文站: 那最后作为一个由 DBA (Administrator) 成长为DB Architect，同样都是A，但这个A已经有一个变化，那么你对后来者有哪些建议呢？

Fenng: 建议谈不上，跟大家谈谈自己在这个过程中的一些转变。首先从DBA(的角度说)，因为 DBA 做一些实际相关的维护工作，从这个过程转到架构师这边，是相对从这比较”实”的岗位转换到现在看起来相对好像稍稍”虚”了一些，但是在这个”虚”的过程中，又相当于我们且退一步，然后就能看得更远一些，能看到整个软件架构的网站发展，甚至是公司战略上的一些事情，这对个人成长是有好处的，我希望大家如果有这个意愿也可以稍微尝试一下，因为 DBA 只是我们整个软件开发行业中的一个环节，那么在这个环节前面和后面，其实都有很多可以做的事情。

其实每个人都不是不可替代的，那我们是否可以尝试一下是否能够去替代别人呢？谢谢大家。

–EOF–

什么是 Load ? 什么是 Load Average ?

如何判断系统是否已经 Over Load ?

Load 与容量规划(Capacity Planning)

Load 与系统预警

误解 一：系统 Load 高一定是性能有问题。

误解 二：系统 Load 高一定是 CPU 能力问题或数量不够。

误解 三：系统长期 Load 高，首选增加 CPU。

FAQ 1：数据库服务器突然 CPU 100% 繁忙，咋办?

误解一：系统 Load 高一定是性能有问题。

误解二：系统 Load 高一定是 CPU 能力问题或数量不够。

误解三：系统长期 Load 高，首选增加 CPU。