2010-02-06 Sat
一种情况下，比如我现在有个项目经过充分考虑已经设计的差不多了，自己也论证了N次，比较满意。结果这个时候有人提出了新的要求，咋一看对现有方案甚至可能冲击比较大，于是我就会从各个角度“论证”新要求的不合理性以及不可完成性。但若我换了个态度，先不顾及自己已有的方案，由于已经经过多次分析，可以迅速在增加需求的基础上，重新设计一套方案，最后发现，重新设计出来的完整的方案跟原方案一对比，居然没有什么本质的差异，只需要一点点改动，或者一点点折中就能达成双赢。但通常情况我可能是在跟提出新需求的吵了半天要么以被强奸者的态度去改变，要么以胜利者的姿态坚持了自己的意见。 但这个时候“我”是赢了，公司却未必赢。
说这个问题，不代表所有需求我们都要满足，也可能我重新“设计”了方案之后发现不可行，那也没关系，我想提需求的人也应该是能理性看待问题的，只要我们内心真的认真去“拥抱”了这个变化，大家最终能达成理解的。这也是加深我们之间信任的一种方式。
那上面是一件比较具体的工作，还有一些思维方式或者行为方式的差异，“我”的固见会使得我在态度上就无法平静下来，更不会换位思考或者尝试一理解和包容的态度去思考双方的差异。这是我们人与人之间难以快速有效沟通和达成信任的巨大障碍。
说这个问题，不代表所有需求我们都要满足，也可能我重新“设计”了方案之后发现不可行，那也没关系，我想提需求的人也应该是能理性看待问题的，只要我们内心真的认真去“拥抱”了这个变化，大家最终能达成理解的。这也是加深我们之间信任的一种方式。
那上面是一件比较具体的工作，还有一些思维方式或者行为方式的差异，“我”的固见会使得我在态度上就无法平静下来，更不会换位思考或者尝试一理解和包容的态度去思考双方的差异。这是我们人与人之间难以快速有效沟通和达成信任的巨大障碍。
p {
text-indent:28px;
}
在前两篇（前篇、中篇）中，分别介绍了Key Cache的基本原理（LRU和Midpoint Insertion Strategy）。最后，将介绍一些相关的参数、状态参数和命令。
Key Cache的配置很灵活，可以针对全局配置，还可以针对某个单独数据表分配Key Cache的大小；如果一个数据表某部分的索引块被访问的非常频繁（较之其他索引块），那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。
1. 如何配置Key Cache的大小
#配置文件my.cnf
key_buffer_size=50*1024*1024
另外，Key Cache的大小可以动态的改变
2. 给数据表划分单独的Key Cache
例如：划分一块128K的Key buffer空间，指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。
SET GLOBAL hot_cache.key_buffer_size=128*1024;
CACHE INDEX t1 IN hot_cache;
SET GLOBAL hot_cache.key_buffer_size=0;
3. 预先载入某些数据表的索引
LOAD INDEX INTO CACHE t1, t2
4. 关于Key Cache的使用情况观察 Flush现象
mysql> show status like "key%";
+------------------------+----------+
| Variable_name ...
p {
text-indent:28px;
}
本文将分为前、中、后三篇，分别介绍MyISAM Key Cache的一般机制、Mid-point strategy、状态、参数和命令。
“Cache为王”，无所不在。为了最小化磁盘I/O，MyISAM将最频繁访问的索引块（“index block”）都放在内存中，这样的内存缓冲区我们称之为Key Cache，它的大小可以通过参数key_buffer_size来控制。在MyISAM的索引文件中（MYI），连续的单元（contiguous unit）组成一个Block，Index block的大小等于该BTree索引节点的大小。Key Cache就是以Block为单位的。
1. MyISAM如何使用Key Cache
当MySQL请求(读或写)MyISAM索引文件中某个Index Block时，首先会看Key Cache队列中是否已经缓存了对应block。如果有，就直接在Key Cache队列中进行读写了，不再需要请求磁盘。如果是写请求，那么Key Cache中的对应Block就会被标记为Dirty（和磁盘不一致）。在MyISAM在Key Cache成功请求（读写）某个Block后，会将该Block放到Key Cache队列的头部。
如果Key Cache中没有待请求（读或写）的Block，MyISAM会向磁盘请求对应的Block，并将其放到Key Cache的队列头部。队列如果满了，会将队列尾部的Block删除，该Block如果是Dirty的，会将其Flush到磁盘上。我们看到MyISAM维护了一个LRU（Least Recently Used）的Key Cache队列。队列中的Dirty Block会在Block被踢出队列时Flush到磁盘上。
2. 图解
下图展示了访问Index Block的过程：（黑色部分为磁盘中的Index文件）
3. 并发访问
Key Cache中的index Block是可以被并发访问的（Shared access ），下面是一些规则：
多个没有更新操作的session可以并发同一个block buffer
多个session同时访问某一个block buffer，如果某个session是update操作，则优先访问
多个session如果都需要进行block replacement，是可以并发操作。（从index file中读取block更新到key cache，但是key cache已满，需要删除一些block buffer的操作叫做block replacement）
4. 补充说明
Key cache中的Block大小可能和索引文件中的Index Block大小不同，可能是大于、小于、等于中的任何一种，但是一般都是成倍数关系的。Key Cache的block大小由参数Key_cache_block_size控制。
（未完待续）
p {
text-indent:28px;
}
在前篇中介绍了Key Cache的基本机制，并且介绍了Key Cache的LRU算法。作为对LRU算法的改进，MyISAM还提供了另一个缓存算法：“Midpoint Insertion Strategy”。本文将重点介绍该算法的原理和配置。
1. 相关参数
该策略涉及的参数有：key_cache_division_limit、key_cache_age_threshold
2. 原理介绍
(1) 该策略将前面的LRU队列（LRU Chain）分成两部分，hot sub-chain和warm sub-chain。并根据参数key_cache_division_limit划分，总保持warm sub-chain在这个百分比以上。默认情况key_cache_division_limit是100，所以默认时候只有warm sub-chain,即LRU Chain。
(注：Multiple Key cache情况，每个key cache都有对应的key_cache_division_limit值)
(2) 在warm sub-chain中的某个block如果被访问（Access）次数超过某个值时候，就将该block放到hot sub-chain的底部。
(3) 在hot sub-chain中的block会随着每一次的hit调整位置，hit越多，越接近底部。在顶部停留时间过长就会被降级到warm sub-chain中，而且是warm sub-chain的顶部（很可能很快就会被移出key cache）。
(4) Hot sub-chain中的顶部的block停留时间超过一个阈值后就会被降级到warm sub-chain。这个阈值由参数key_cache_age_threshold决定。具体的计算方法是：设N为key cache中的block个数，如果在最近的（N*key_cache_age_threshold/100）次访问中，key cache顶部的block仍然没有被访问到，那么就会被移到warm sub-chain的顶部。
(5) 默认情况key_cache_division_limit = 100，这时只有只有一个Chain，所以不使用该策略。即退化的Midpoint Insertion Strategy是LRU算法。
3. 如何使用Midpoint Insertion Strategy
我们可以通过配置key_cache_division_limit、key_cache_age_threshold的值来控制。参数key_cache_division_limit控制了Key Cache Chain中warm sub-chain的百分比，如果你的Index Block中明显有30%是非常Hot（较之其他的Block更加被常常访问），那么你可以设置你的warm sub-chain长度为70%，剩余30%作为hot sub-chain。参数key_cache_age_threshold定义了warm sub-chain中的block被移除的机制（参照前文介绍）。
（未完待续）
在经历了2009年的分布式启步之后，经过改造的数据库系统性能得到极大的提升，但这个变化仍然不构成今天这篇文章的主题，我想要说的是另外一方面的变化，这个变化在某种程度上影响着当前DBA的角色变化问题。
在分布式数据库时代，开发DBA的开发支持工作相比于以前，会有更多的系统思考问题的机会，会结合应用来设计量身定做的分布式数据库系统，如果一个DBA对业务有着深刻的理解，深刻理解数据库原理，既具有整体性的架构思维，又有一些关键细节把握能力的时候，设计一套分布式系统是水到渠成的事。对于开发支持的一些工作，比如SQL审核，表结构变更，数据订正，历史迁移，如果没有工具的支持，那做起来还是比较吃力的。这些方面，我们还有许多的道路要走，怎么样改变目前的现状。
在分布式数据库时代，系统DBA的运维要求难度在某方面有所降低，整个应用因为在容错性方面做了比较多的努力，比如down掉一个数据库时，对于整个应用系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维，在另外一个层面运维难度又有所增加，第一，运维的机器数量呈几何指数的增长，由于大量采用低端机器，集群中某个机器出问题的概率大增，可能每天都会处理好几次down机的事故;第二，对监控系统的要求增加，对10台数据库的监控与对1000台数据库的监控方法肯定会有许多差异的,我们的监控系统也应该具有分布式的能力,避免单点；第三，系统精细化运维能力需要提升，采用大量低端pc server,在机房的设计上要尽可能的下功夫，可以参考一下google的机房建设的论文，pc server的硬件在不同应用上的定制化以尽量节能，CPU个数是否存在严重过多的情况,pc server上装的linux os是否有优化过，不同版本的os是否存在稳定性问题，os上跑的mysql是否已经足够的优化。
另外一个方面的变化，是来自于我们的分布式数据层的开发人员。他们开发的数据层是前端应用与底层数据库集群的中间纽带,是整个分布式数据库系统最重要的组成部份。而开发分布式数据层的开发人员自然会成为核心的核心，他们对于许多底层技术的理解相当的深入。与他们讨论问题时，倍感知识的匮乏。大部份DBA由于缺乏长期的开发经验的积累，双方沟通时，有时会比较吃力。
从长远的方向来讲，分布式数据库系统将会越来越依重于分布式中间件产品，整个应用系统的健康也会更依赖于开发人员的能力。在某种程度上，分布式数据库时代的DBA的重要性，会低于集中式数据库时代的DBA重要性。但对于公司而言，整个公司的技术实力有了质的飞跃,大大节约了成本,也掌握了未来的主动权。
如何扩大DBA的外延与内涵，来适应这种变化，是我们共同努力的方向.
mysqldump是非常重要的MySQL备份工具。然而在长年累月的使用过程中，TAOBAO多次出现了因mysqldump意外终止而导致备份失败的情况。
以下是我们经常遇到的问题：
1、Lost connection to MySQL server at 'reading initial communication packet'：
这个主要是因为DNS不稳定导致的。如果做了网络隔离，MySQL处于一个相对安全的网络环境，那么开启skip-name-resolve选项将会最大程度避免这个问题。
2、Lost connection to MySQL server at 'reading authorization packet'：
从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中，网络波动会导致握手失败。增加connect_timeout可以解决这个问题；然而增加connect_timeout并不能防止网络故障的发生，反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请求。
3、Lost connection to MySQL server during query：
这个问题具备随机性，而淘宝MySQL的应用场景决定了我们无法多次备份数据以便重现问题。
然而我们注意到这个问题一般会在两种情况下会发生。一种是mysqldump **** | gzip ****；另外一种是mysqldump **** > /nfs-file
注意，不管是gzip还是nfs都有一种特点，那就是它们影响了mysqldump的速度。从这个角度思考，是不是mysqldump从MySQL接受数据包的速度不够快导致Lost connection to MySQL server during query错误呢？
为了定位到问题，我搭建了一个测试环境：
test@192.168.0.1：3306
CREATE TABLE `test` (
`id` bigint(20) NOT NULL auto_increment,
`b` varchar(2000) default NULL,
`c` varchar(2000) default NULL,
`d` ...
在这篇文章里，给大家简单介绍一下本人对Oracle索引的理解，如有不妥的地方，请不吝指教。
本文只讲最最平常最最简单的索引，就是以create index ix on tx(a,b,c);形式创建的索引，而不讲位图索引、反向键索引、倒序索引、基于函数的索引等等。其实呢，只要是基于B树的索引，不管是在Oracle, Mysql，还是其它数据库中，原理应当都是一样的。
索引最重要的一个性质应该就是有序，索引中的每一项，是从左到右，从小到大，以严格的顺序排列好的。
下面的讨论都以上面的索引ix(a,b,c)为例。
把这棵索引的叶子节点画到纸上，大概是这样的：
a1 a2 a3 ...... an
b1 b2 b3 ...... bn
c1 c2 c3 ...... cn
上面这个3×n的矩阵，每一列代表了一条记录，同时这一列记录，也对应了表里的唯一一条记录。当然，在Oracle里，对于non-unique索引，需要补上rowid，才是真正唯一的。上面的索引相当于create unique index ix on tx(a,b,c,rowid); 我们把这个细节忽略掉。
把每一列看作一个向量,vi = (ai, bi, ci)，
有序的含义就是：
vi < vj iff i ＜ j;
vi < vj这么定义：
(ai ＜ aj) or (ai = aj and bi ＜ bj) or (ai = aj ...
"And God said, Let there be network: and there was timeout"
在使用MySQL的过程中，你是否遇到了众多让人百思不得其解的Timeout？
那么这些Timeout之后，到底是代码问题，还是不为人知的匠心独具？
本期Out-man，讲述咱们MySQL DBA自己的Timeout。
先看一下比较常见的Timeout参数和相关解释：
connect_timeout
The number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake.
interactive_timeout
The number of seconds the server waits for activity on an interactive connection before closing it.
wait_timeout
The number of seconds ...
章文嵩博士（LVS开源项目创始人）进入淘宝好几个月了，今天是他第一次讲解LVS的实现原理。作为DBA的一员，终于近距离膜拜了大牛。
讲解的内容就不具体介绍了，在LVS官方网站上面可以找到。PPT的内容和网站上基本上一样，只是讲解人是章博士本人。我在这整理一下自己的理解，不对请大家指正。 ^_^
组成LVS最重要的部分有三个：请求分发服务器、处理服务器、共享存储。
典型的Web集群并不需要共享存储，只有请求分发服务器和处理服务器，如下图所示：
如果完成请求需要基于数据，那么共享存储就是LVS必须的组件了。LVS邮件服务器集群如下所示：
目前能应用于LVS的MySQL集群只能是NDB Cluster，因为MySQL众多的存储引擎中，只有NDB Cluster实现了共享存储的功能。
在NDB Cluster中，SQL Node相当于处理服务器，Data Node相当于共享存储。LVS可以让应用程序的开发更加简单，开发人员并不需要知道执行SQL的数据库服务器到底是哪一个，但是可以获得自己想要的数据。而NDB Cluster提供的数据拆分和扩容功能，保证了数据库的可扩展性。
美中不足的是，NDB Cluster的性能实在太差。即使LVS负载均衡做得很好很强大，NDB Cluster也会成为瓶颈。
根据我的观察发现，LVS的架构非常适用于CPU-bound的应用场景。虽然共享存储的引入使得LVS能够支持有状态的连接，但是LVS并不适用于IO-bound的应用。因为不管负载如何均衡，最终瓶颈在于共享存储之上。而共享存储如何拓展，LVS并不关心。也许只有NDB Cluster提升了IO性能之后，LVS才能真正在MySQL方面应用起来。
非常感谢章博士的分享，NDB Cluster终于让我觉得不那么鸡肋了。
p {
text-indent:28px;
}
记得刚开始看InnoDB文档的时候，Double Write一节（其实只有一小段）就让我很困惑。无奈当时内力太浅，纠缠了很久也没弄明白。时隔几个月，重新来整理一下。
涉及到的概念：Buffer Pool简称BP，Dirty Page，Log file，Flush，innodb tablespace。
1. 什么是Double Write
在InnoDB将BP中的Dirty Page刷（flush）到磁盘上时，首先会将Page刷到InnoDB tablespace的一个区域中，我们称该区域为Double write Buffer。在向Double write Buffer写入成功后，再择机将数据拷贝到正在的数据文件对应的位置。
咋一看，这个过程有些多余
2. 为什么需要Double Write
InnoDB中有记录（Row）被更新时，先将其在Buffer Pool（简称BP）中的page更新，并将这次更新记录到Log file中，这时候BP中的该page就是被标记为Dirty。在适当的时候（BP不够、系统闲置等），这些Dirty Page会被flush到磁盘上。
试想，在某个Dirty Page（一般是16K）flush的过程中，发生了系统断电（或者OS崩溃），16K的数据只有8K被写到磁盘上，这种现象被称为（partial page writes、torn pages、fractured writes）。一旦partial page writes发生，那么在InnoDB恢复时就很尴尬：在InnoDB的Log file中虽然知道这个数据页被修改了，但是却无法知道这个页被修改到什么程度，和这个页面相关的redo也就无法应用了。
举个例子：在InnoDB的log file中有如下Log：
Log sequence number 0 4285149977
Log sequence number 0 4287355447
Log sequence number 0 4289260680
Log sequence number 0 4291279900
Log sequence number 0 4293359020
其中第1、3个Log修改了该page，但是在断电时，BP中该page只被flush了一部分。那么InnoDB是无法决定上面的Log是否应该被应用的。这时，数据就出现了不一致。
所以，Log file的有效应用，前提是InnoDB的数据文件中的Page是一致的。
简而言之，Double ...
开发DBA周会中，丁原提出的问题：
DML语句中where子句中添加rownum alter session set nls_language=american;
SQL> create table test as select 1 as id from dba_objects where rownum < 10;
n 把表中的数据块dump出来
SQL> select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,
2 dbms_rowid.rowid_block_number(rowid) as block#
3 from test;
FILE# BLOCK#
---------- ----------
4 988
SQL> alter system dump datafile 4 block 988;
System altered.
n 查看trace文件，其中的部分数据如下：
Block header dump: ...
昨天装好的RAC，客户已经打了几个电话咨询，严重质疑RAC的稳定性。
结果是，昨天有人把网线都插拔了一遍，两台机器都挂了；
今天有台机器的网线又被扯，又断了一台。
客户质疑RAC，我只好一遍一遍解释，这个网络啊、心跳啊、VIP啊，对Oracle是灰常灰常重要的。
当然看看日志也有收获，NIC网卡Down的信息，这没什么好说的：
又发现有Lost ticks的提示信息：
关于lost ticks找到一些参考信息：
另外一篇文章则为我解释了CPU Frequency scaling的含义：
感谢网络，感谢网友们的分享，我要继续不断学习。
-The End-
结果是，昨天有人把网线都插拔了一遍，两台机器都挂了；
今天有台机器的网线又被扯，又断了一台。
客户质疑RAC，我只好一遍一遍解释，这个网络啊、心跳啊、VIP啊，对Oracle是灰常灰常重要的。
当然看看日志也有收获，NIC网卡Down的信息，这没什么好说的：
Feb 6 10:13:21 wg1 kernel: bnx2: eth0 NIC Copper Link is Down确认当时的确是有人动了网线，否则不能排除是否网卡本身不稳定。
Feb 6 10:57:20 wg1 kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
Feb 6 10:57:29 wg1 login(pam_unix)[7424]: session opened for user root by LOGIN(uid=0)
Feb 6 10:57:29 wg1 -- root[7424]: ROOT LOGIN ON tty1
Feb 6 10:58:31 wg1 kernel: bnx2: eth0 NIC Copper Link is Up, 100 Mbps full duplex
又发现有Lost ticks的提示信息：
kernel: warning: many lost ticks.
kernel: If your CPU support 'CPU Frequency scaling',You could ignore this warning
kernel: else your time source seems to be instable or some driver is hogging interupts
kernel: rip __do_softirq+0x4d/0xd0
关于lost ticks找到一些参考信息：
在某些系统上，当首次访问一些 IDE 设备时，可能显示信息warning:many lost ticks（警告：丢失许多嘀嗒信号）。当 IDE 设备没有使用 DMA 进行数据传输时，会显示此信息，因为非 DMA 传输所用的时间比计时器嘀嗒信号间隔长很多（在此期间，处理器无法处理计时器嘀嗒信号中断）。此信息并不表示系统出现故障，也不会导致任何功能问题。如果系统运行的是带 Update 1 或更高版本（含适用于此控制器的更新驱动程序）的 Red Hat Enterprise Linux 4，则连接至 Intel ICH7 IDE控制器的设备不会遇到这种问题。但是，由于其它 IDE 设备无法使用DMA，因此该信息仍然会显示。
在基于 AMD 处理器的系统上，如果启用非一致内存存取 (Non Uniform Memory Access) 功能，则系统在高负载情况下将显示"lost ticks"（丢失嘀嗒信号）信息当运行 Red Hat Enterprise Linux 4（更新 4 之前的版本）的系统处于高负载时，屏幕将显示以下信息：
warning: many lost ticks.（警告：丢失许多嘀嗒信号。）
Your time source seems to be instable or some driver is hogging interrupts
（时间源似乎不稳定或者某些驱动程序干扰中断）
rip __do_softirq+0x4d/0xd0
当在基于 AMD 处理器的系统上使用非一致内存存取 (NUMA) 功能时，将出现此问题。要解决此问题，请将以下参数添加到内核命令行：
console=tty0 numa=off
注：确保 numa=off 为内核命令行中的最后一个选项。如果 numa=off 不是最后一个选项，
将不能识别此参数。
在 Red Hat Enterprise Linux 4 更新 4 中已解决这一问题。
（上面这一篇是DELL的文档上的解释）
您可以安心忽略 RHEL4 U4 丟失滴答計時的訊息(6483062)
在沈重的負載下，RHEL4 訊息檔案與 dmesg 記錄檔可能顯示類似下列的訊息：
Warning many lost ticks
Your time source seems to be unstable or some driver is hogginginterrupts.
此訊息是由不同 IRQ 處理常式之間的爭用所導致，但是對於系統沒有負面影響。
(上面一小段是SUN的文档上的解释)
同时注释一下HPET的全称吧：High Precision Event Timer (HPET)
另外一篇文章则为我解释了CPU Frequency scaling的含义：
CPU Frequency scaling，这一选项允许改变CPU的主频，使CPU在低负荷或使用电池时降低主频，达到省电的目的。
Enable CPUfreq debugging，是否允许调试CPU改变主频的功能，如果要调试，还需要在启动时加上参数。cpufreq.debug=
1：变频技术的内核调试
2：变频技术的驱动调试
4：变频技术的调节器调试
感谢网络，感谢网友们的分享，我要继续不断学习。
-The End-
相关文章|Related Articles
- Redflag Linux安装Oracle 10gR2 RAC记事
- OEL Linux与Oracle Validated Configurations
- Linux下如何查看文件秒级修改及访问时间
- Linux + Oracle 数据库系统启动能有多快?
- 使用Linux下script工具记录Oracle输出
评论数量(0)|Add Comments
本文网址：http://www.eygle.com/archives/2010/02/linux_many_lost_ticks.html
推荐一本书，著名语言学家周有光先生的新作《朝闻道集》。包括梁文道在内，最近有很多人都在推荐这本书。
推荐这本书，不是因为周先生已经是一位105岁的老人，也不是因为他敢讲，这年头敢讲的人其实也不少，网络上就有很多，我有的时候也很敢讲，关键在于，他讲的很有道理，都是些真知灼见，特别是他针对中国社会的批评具有难得的世界精神。
我以前曾推荐他的《语文闲谈》，还有《周有光百岁口述》：http://mumu6.blog.sohu.com/113361585.html
当当网关于《朝闻道集》的介绍: http://product.dangdang.com/product.aspx?product_id=20732729
梁文道的推荐：http://book.ifeng.com/psl/kjbfz/201002/0202_3554_1534072.shtml
http://book.ifeng.com/psl/kjbfz/201002/0203_3554_1535641.shtml
《南方人物周刊》采访：http://news.sina.com.cn/c/sd/2010-02-05/103219635742.shtml
《南方都市报》采访：http://epaper.nddaily.com/C/html/2010-01/24/content_999668.htm
凤凰卫视许戈辉名人面对面20100110周有光A
http://www.letv.com/ptv/vplay/501067.html
凤凰卫视许戈辉名人面对面20100110周有光B
http://www.letv.com/ptv/vplay/501070.html
凤凰卫视许戈辉名人面对面20100117周有光c
http://www.letv.com/ptv/vplay/512329.html
《凤凰大视野》生命的光芒.周有光http://www.56.com/u50/v_MjU4NzM3MTE.html
《小崔说事》：http://vsearch.cctv.com/plgs_play-CCTVNEWSprog_20071217_2587930_0.html?
