跟曹老大的接触不是特别多,但不得不说,他是我非常欣赏的人,每次都给我非常亲切的感觉,每次都能看到他真诚的淡淡的微笑..谨以此贴纪念之.

曹行携家人在海南度假期间发生溺水意外，永远离开了我们！！！

惊闻噩耗，难以置信，欲哭无泪！他的身影，亲切的笑容，充满智慧的话语，乐于助人的行为，令我们无法相信这残酷的事实！

此时此刻，我不知用什么样的文字才能纪念，才能缅怀我记忆中永远那么可爱的曹行！

LIFE GOES ON！生活在继续！让我们为失去的战友，导师，伙伴哀悼，让我们为曹行在天之灵祈福，保佑曹行的家人，让我们去实现曹行未尽的理想！珍惜生命，认真生活！

我们亲爱的战友，曹行， 你一路走好啊！

No related posts.

• a. 新增了对Compaction的优先级控制.
  -XX:+UseThreadPriorities \
  -XX:ThreadPriorityPolicy=42 \
  -Dcassandra.compaction.priority=1 \
• b. 对Hinted Handoff的手工控制.
  0.6.0: send hints to natural replicas
  0.6.0: fix row-level concurrency bottleneck
  0.6.2: option to disable entirely
  0.6.3: remove hourly scan
  0.6.4: lower priority
  0.6.5: paging of large hinted rows
  0.7.0: large rows
• c. 在0.6.4上调整了SEDA的流控制(Flow Control),将Message Deserializer的步骤去掉了(这在我们这边的测试中,成为了系统的写性能瓶颈)
• d. 在0.7版本中,大大提供了Cassandra的Read Performance(这一点,我非常期待)

2. Benjamin Black做的关于Cassandra的运维与故障诊断介绍.
故障诊断部分的介绍,我认为写的非常好, 对于做其他类似的问题的诊断也有部分效果.

• a. 如何调整Cassandra的Ring分布, 这个问题也是困扰我已久的问题, 内部也有兄弟问过我这个问题, 从我的理解上, Cassandra的Ring分布也是类似于Oracle的Hash Partition策略, 默认是按照bit位来分布, 但是可以手工对其进行调整, 这个ppt里面就介绍了具体的调整方法.
• b. 如何诊断Cassandra的读性能较差的问题, 通过noodtool tpstat与iostat命令确定是否由于磁盘的问题,以及给出一些简单的调整原则.
  less frequent memtable flush
  less frequent compaction
  less disk bandwidth demand
• c. 如何调整DiskAccessMethod或者说,如何合理调整mmap与JVM的使用策略

No related posts.

Flowdock是一个基于Web的团队通讯工具.所有的软件开发人员都应该使用它进行沟通,而不是使用Campfires、Skype Chats或IRC等工具.因为它可以更好的的支持他们的真实工作流.

上周,我们对Flowdock的数据库服务做了一次切换,聪从Cassandra迁移到了另一种NoSQL工具-MongoDB.由于我们的技术选择已经引起了大家的部分兴趣,我将在此向公众说明下我们的决策理由.

我们的部分客户一定对下面这个图片记忆犹新:

从一定程度上讲,我们遭遇到了Cassandra的稳定性问题.所有的节点都陷入无线无限循环(infinite loop),运行垃圾回收工作(GC, Garbage Collection)并尝试压缩数据文件-并偶尔导致集群瘫痪.除了对集群进行重启并经常性的手工对节点做压缩工作以让其稳定一会外,我们无计可施.其他人也报告过类似的问题.在前面几周的时间里,我们的Cassandra节点总是会吃掉给他分配的所有资源,而导致Flowdock运行缓慢.

由于我们刀口嗜血式的数据库选择(James注: 这是我不认同的地方,可能对于一些Startup的公司来讲,这是一种不得已的选择.),这已经不是我们第一次遇到此类问题了.从Cassandra 0.4升级到0.5的时候,我们被迫关闭了整个集群,仅仅是为了将所有的数据刷新到磁盘上(虽然,我们已经按照文档进行了手工刷新的操作).这个操作导致我们丢失了几分钟的讨论内容,以及我们手工创建的索引出现严重的不一致,以致于需要做完全的重建.我想,我们最后离开办公室的时间已经是凌晨4点了.

从我们最初选择Cassandra到现在,NoSQL社区已经出现了很大的变化.MongoDB已经发生了很大的改变,最近新增的自动分片(auto-sharding)与副本集(replica set)使得它可以作为Cassandra的有力的替代品.因此,我们决定试试MongoDB.

写从Cassandra往MongoDB的数据迁移的脚本耗费我一天的时间.在一周左右的时间内,我们已经可以完全在MongoDB上运行Flowdock了.在生产环境部署MongoDB之前,内部测试持续进行了好几个星期.

目前,我们已经完成这个调整,

• 1. 智能(多键)索引. 手工维护的索引令人生厌,MongoDB可以自动帮我们维护所需的索引.例如,我们的消息包含标签(tag),例如下面这个格式的document:

  { content: "Write a blog post about #mongodb.",
    workspace: 'myflow',
    tags: ["mongodb", "todo", "@Otto"] }
  这样,如果仅检索自己的任务,Flowdock的后台只需要做下面这个查询:
  db.messages.find({
    workspace: 'myflow',
    tags: { $all: ["todo", "@Otto"] }
  })
  

• 2. 查询.无论数据模型多么简单,每当需要执行一个查询的时候,你都不需要提前规划此事.在MongoDB中,你可以直接在控制台定制复杂的查询,这一点非常类似于SQL数据库.它会据此执行一次顺序扫描,这比在客户端手工处理上百万的记录要更快捷也更便利.
• 3. Map-Reduce. 这是分析人员的利器啊.MongoDB的Map-Reduce功能支持虽然不是非常完美,但它起码很易用.
• 4. GridFS让我们的文件存储操作变得非常容易.它的存储能力可以随着我们的MongoDB集群的扩展一起增长.

我们也遭遇到部分轻微的限制:

• 1. 我们发现了一个JSON解析的bug,不过我们在10分钟内就解决了此bug.
• 2. BSON的Document键中不支持点(dot).通常,这或许不是个问题,但是我们必须在数据迁移中解决此问题.
• 3. Document有4MB的大小限制.这对于我们的数据模型来讲不是问题,由于MongoDB对在位的原子更新(atomic in-place updates)有非常好的支持,所以,你需要关注,Document不要超过4MB的限制.
• 4. 增加新的节点没有在Cassandra中那么容易.然而,Cassandra在新增节点的负载均衡上有它自己的问题.

到目前为止,它的运行还非常平稳.开发人员与数据库管理员的工作也因此减轻了很多.

No related posts.

摘自 http://mor.ph/blogs/5-lessons-when-switching-switching-to-cloud-Amazon-IT

• 1. Moving to cloud computing is a business decision, not political or marketing mandate. Target the project as a multi-year effort.
• 2. Server consolidation and virtualization are important initial steps.
• 3. Start with simple applications; with financials as the last to move.
• 4. Do homework. Execute risk assessment and take steps to evaluate cloud vendor.
• 5. Think hard and implement security at the application level, not just at operations.

• 1. 迁移到云集算平台上是一个商业决策,不能只是政治或市场指令. 此项目可能需要多年的努力.
• 2. 服务器的整合与虚拟化对于迁移成功很重要.
• 3. 先迁移简单的应用,将财务类的应用放到最后再做.
• 4. 做大量的准备. 做好风险评估并花费资源评估各云提供商的产品.
• 5. 在应用层对安全做深入的考虑以及实现,而不只是考虑运维层面的安全性.

No related posts.

新相关同学点击此链接重新订阅.

订阅本Blog

No related posts.

测试的过程如下.

--1. 构造一个500w条记录的表. 并创建需要rebuild online的索引.
--表的数量设置到这么大,,主要是为了给后续的操作留出手工运行的时间.
create table james_t as
select rownum id,dbms_random.string('l',20) user_name
from dual
connect by level <= 5e6;

create index james_t_pk on james_t (id);

--2. 在Session 2 (故意设置阻塞的进程)运行一个针对表james_t 的单条记录的更新.
update james_t set user_name = 'test 1' where rownum <= 1;

--3. 在Session 3中观察,当观察到session 1被堵塞在Table Share Lock的Request模式时进行下一步.
select /*+ rule*/a.* from v$lock a,v$session b where a.sid = b.sid and b.username = 'JAMES';

--4. 在Session 1 (运行index rebuild online的进程)运行如下语句.
alter session set events '10704 trace name context forever,level 10';
alter session set events '10046 trace name context forever,level 12';
alter index james_t_pk rebuild online;

--5. 在Session 2 提交前一个事务,使得rebuild online 过程继续,并运行一个需要大量index字段的更新操作.
--构造需要rebuild online在获取下一次Table Share lock之前需要Merge的数据.
commit;
update james_t set id = 5000000 + id where rownum <= 3e5;
commit;

--6. 在Session 2上运行一个类似于第二步的简单更新,意在阻塞Rebuild Online获取Table Share Lock.
update james_t set user_name = 'test 1' where rownum <= 1;

--7.  在Session 3中观察,当观察到session 1被堵塞在Table Share Lock的Request模式时,执行下面的语句后进行下一步.
--清空Buffer Cache以观察Session 1在获取Table Share Lock后执行的操作.(可供下载的Trace文件没有做这一步)
alter session set events = 'immediate trace name flush_cache';

--8. 提交Session 2的事务, 等待Rebuild Online结束..

--9. 从Session 3中提取出Session 1对应的Trace文件,,以及下面的v$session_longops 的结果.
SID	SERIAL#	OPNAME	TARGET	TARGET_DESC	SOFAR	TOTALWORK	UNITS	START_TIME	LAST_UPDATE_TIME
10	19	Sort Output			14759	14759	Blocks	07/28/2010 09:14:26	07/28/2010 09:14:41

1. 取得表上的Sub Share锁. 索引的object_id = 6399.
*** 2010-07-27 23:07:16.000
ksqcmi: TM,18fe,0 mode=2 timeout=21474836
ksqcmi: returns 0

2. 创建日志表.
"JAMES"."SYS_JOURNAL_6399"

create table "JAMES"."SYS_JOURNAL_6399" (C0 NUMBER, opcode char(1), partno number, rid rowid, primary key( C0 , rid ))
organization index TABLESPACE "USERS"

CREATE UNIQUE INDEX "JAMES"."SYS_IOT_TOP_6406" on "JAMES"."SYS_JOURNAL_6399"("C0","RID") INDEX ONLY TOPLEVEL TABLESPACE "USERS" NOPARALLEL

3. 请求表上的Share锁.
*** 2010-07-27 23:07:16.000
ksqcmi: TM,18fe,0 mode=4 timeout=21474836
WAIT #1: nam='enqueue' ela= 3072242 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072273 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072430 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3071962 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072350 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072367 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072086 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072453 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 387366 p1=1414332420 p2=6398 p3=0
ksqcmi: returns 0

2010-07-27 23:07:16.000 + 24.965529 = 2010-07-27 23:07:40.966
--此时间与下面获取Table Sub Share Lock的时间仅相差20ms左右. 中间的时间主要为统计误差,,因为Trace中的输出是连续的.

4. 取得完毕之后,,立即获取表上的Sub Share锁.
*** 2010-07-27 23:07:41.000
ksqcmi: TM,18fe,0 mode=2 timeout=21474836
ksqcmi: returns 0

5. 读取基础表,,创建索引.
WAIT #1: nam='db file scattered read' ela= 42228 p1=5 p2=4709 p3=4
WAIT #1: nam='db file scattered read' ela= 326 p1=5 p2=4710 p3=3
WAIT #1: nam='db file scattered read' ela= 236 p1=5 p2=4711 p3=2
.................
WAIT #1: nam='db file scattered read' ela= 549 p1=5 p2=36357 p3=4
WAIT #1: nam='db file scattered read' ela= 481 p1=5 p2=36358 p3=3

6. 开始Sort并输出索引. (写入临时文件)
WAIT #1: nam='direct path write' ela= 6 p1=201 p2=19942 p3=31
WAIT #1: nam='direct path write' ela= 2 p1=201 p2=19973 p3=4
WAIT #1: nam='direct path write' ela= 2 p1=201 p2=19721 p3=31
WAIT #1: nam='direct path write' ela= 395 p1=201 p2=19752 p3=12

--继续从表上读取内容.
WAIT #1: nam='db file scattered read' ela= 476 p1=5 p2=36359 p3=2
WAIT #1: nam='db file sequential read' ela= 417 p1=5 p2=36360 p3=1

WAIT #1: nam='direct path write' ela= 6 p1=201 p2=19942 p3=31
WAIT #1: nam='direct path write' ela= 2 p1=201 p2=19973 p3=4
WAIT #1: nam='direct path write' ela= 2 p1=201 p2=19721 p3=31
WAIT #1: nam='direct path write' ela= 395 p1=201 p2=19752 p3=12

--从临时文件读出排好序的结果.
WAIT #1: nam='direct path read' ela= 211 p1=201 p2=19763 p3=1
WAIT #1: nam='direct path read' ela= 57865 p1=201 p2=27472 p3=31
WAIT #1: nam='direct path read' ela= 14829 p1=201 p2=34281 p3=31
..........
WAIT #1: nam='direct path read' ela= 14853 p1=201 p2=20342 p3=19
WAIT #1: nam='direct path read' ela= 16932 p1=201 p2=26315 p3=31
WAIT #1: nam='direct path read' ela= 12710 p1=201 p2=21154 p3=31
WAIT #1: nam='direct path read' ela= 16599 p1=201 p2=32412 p3=31

写索引文件,扩展segment信息.

select file# from file$ where ts#=:1
select type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,NVL(lists,65535),NVL(groups,65535),cachehint,hwmincr, NVL(spare1,0) from seg$ where ts#=:1 and file#=:2 and block#=:3
insert into seg$ (file#,block#,type#,ts#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,lists,groups,cachehint,bitmapranges,scanhint, hwmincr, spare1) values (:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,0,0,:16,DECODE(:17,0,NULL,:17))
中间再夹杂部分
WAIT #1: nam='direct path read' ela= 20442 p1=201 p2=31559 p3=1

--结束Sort Output并使用Direct path write写入新索引.
WAIT #1: nam='direct path read' ela= 8504 p1=201 p2=19849 p3=1
WAIT #1: nam='direct path read' ela= 263 p1=201 p2=19974 p3=1
WAIT #1: nam='direct path read' ela= 46962 p1=201 p2=19721 p3=1
WAIT #1: nam='direct path write' ela= 359 p1=5 p2=48351 p3=7
WAIT #1: nam='direct path write' ela= 5 p1=5 p2=48358 p3=7

---在此时间点结束新索引的创建工作.
SID SERIAL# OPNAME TARGET TARGET_DESC SOFAR TOTALWORK UNITS START_TIME LAST_UPDATE_TIME
10 19 Sort Output 14759 14759 Blocks 07/28/2010 09:14:26 07/28/2010 09:14:41

7. 读取Journal表上的变更,,将变更Merge到新的索引上.
--从10046 的traced Event的角度看,,新的索引文件写完成,开始读取Journal表的内容,以merge新索引.

WAIT #1: nam='direct path read' ela= 23577 p1=201 p2=31718 p3=1
WAIT #1: nam='direct path read' ela= 60459 p1=201 p2=31877 p3=1
WAIT #1: nam='direct path write' ela= 5622 p1=5 p2=52496 p3=7
WAIT #1: nam='direct path write' ela= 3 p1=5 p2=52503 p3=2
WAIT #1: nam='db file sequential read' ela= 32390 p1=5 p2=397 p3=1
WAIT #1: nam='db file sequential read' ela= 34345 p1=5 p2=397 p3=1
WAIT #1: nam='db file sequential read' ela= 100004 p1=5 p2=52005 p3=1

--结束新索引的Merge工作.
WAIT #1: nam='db file sequential read' ela= 1521 p1=5 p2=32192 p3=1
WAIT #1: nam='db file sequential read' ela= 205 p1=5 p2=32192 p3=1
WAIT #1: nam='db file sequential read' ela= 252 p1=5 p2=32200 p3=1
WAIT #1: nam='db file sequential read' ela= 375 p1=5 p2=32200 p3=1

8. 请求表上的Share所.
--请求表上的Share 锁,,以准备结束索引重建..
*** 2010-07-28 09:15:17.000
ksqcmi: TM,18fe,0 mode=4 timeout=21474836
WAIT #1: nam='enqueue' ela= 3071546 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072536 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072024 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072293 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072416 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072140 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072175 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072294 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072249 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072318 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072184 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072216 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 3072247 p1=1414332420 p2=6398 p3=0
WAIT #1: nam='enqueue' ela= 1244788 p1=1414332420 p2=6398 p3=0
ksqcmi: returns 0

9. 读取刚刚阻塞Index Rebuild获取Share 锁所产生的Journal日志并将变更merge到索引上.

--说明,,由于Index Rebuild Online进程是做Enqueue Conversion,所以只可能有一个Session会阻塞此进程.
--此次需要Merge的变更量只是阻塞进程产生的变更量,因此一般情况下,,持有Share锁的时间比较短.
--但是会比第一次持有要稍长一点. 需要等后续清理对象的操作结束才能释放.

10. 删除Journal表
drop table "JAMES"."SYS_JOURNAL_6399"

9. 申请Journal表上的Exclusive 锁.
*** 2010-07-27 23:11:03.000
ksqcmi: TM,1906,0 mode=6 timeout=0
ksqcmi: returns 0
=====================

10. 结束索引重建,,修改相关数据字典表
--更新索引上的data_object_id.
update ind$ set ts#=:2,file#=:3,block#=:4,intcols=:5,type#=:6,flags=:7,property=:8,pctfree$=:9,initrans=:10,maxtrans=:11,blevel=:12,leafcnt=:13,distkey=:14,lblkkey=:15,dblkkey=:16,clufac=:17,cols=:18,analyzetime=:19,samplesize=:20,dataobj#=:21,degree=decode(:22,1,null,:22),instances=decode(:23,1,null,:23),rowcnt=:24,pctthres$=:31*256+:25, indmethod#=:26, trunccnt=:27,spare1=:28,spare4=:29,spare2=:30,spare6=:32where obj#=:1
bind 19: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=08 oacfl2=1 size=24 offset=0
bfp=032cc81c bln=24 avl=03 flg=05
value=6405
bind 33: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=08 oacfl2=1 size=24 offset=0
bfp=032cd8dc bln=22 avl=03 flg=05
value=6399

更新对象的data_object_id
update obj$ set obj#=:6,type#=:7,ctime=:8,mtime=:9,stime=:10,status=:11,dataobj#=:13,flags=:14,oid$=:15,spare1=:16, spare2=:17 where owner#=:1 and name=:2 and namespace=:3 and(remoteowner=:4 or remoteowner is null and :4 is null)and(linkname=:5 or linkname is null and :5 is null)and(subname=:12 or subname is null and :12 is null)

设置对象新关联的seg实体.通过ts#,header_file#,header_block#
update seg$ set type#=:4,blocks=:5,extents=:6,minexts=:7,maxexts=:8,extsize=:9,extpct=:10,user#=:11,iniexts=:12,lists=decode(:13, 65535, NULL, :13),groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17,0,NULL,:17) where ts#=:1 and file#=:2 and block#=:3

执行Ojbect Checkpoint.
WAIT #1: nam='rdbms ipc reply' ela= 54 p1=5 p2=21474836 p3=0
WAIT #1: nam='rdbms ipc reply' ela= 44 p1=5 p2=21474836 p3=0

11. 到此索引Rebuild完成.

完整的Trace文件文件下载. james_ora_4268.trc.gz

Related posts:

1. index rebuild online处理过程

• 1. 介绍 — 此文
• 2. 磁盘与表空间碎片
• 3. 表碎片
• 4. 索引碎片

介绍
By Jonathan Lewis Translated By Jametong

单词“fragmentation”（碎片）的涵义是某些东西被分成多个片段,不过,有时也隐含表示被拆成了大量的小片段.在Oracle的语境下,需要仔细考虑你所说的“片段”,片段的粒度大小,以及其对性能产生的可能影响.由于可以在(逻辑)磁盘层面、文件层面、表空间(tablespace)层面、段(segment)层面、区间(extent)层面以及块(block)层面来讨论碎片,当你在评论种说出类似于“我的表空间有碎片”或“我的索引有碎片”时,需要仔细想清楚你到底想要说明什么.

让我从一个例子开始:我创建了一个新的表空间,并移入了一张表.当我检查dba_extents视图,将发现此表空间有100个区间.很明显,从这个单词的基本涵义看,它被“分成多片”了,它有100个不同的片段组成.另一方面,因为此表是我在此表空间内创建的第一个对象,我可以发现所有的区间都相邻,你可以说此表“逻辑上分成多片”但是“物理上连续”.

这个碎片的例子会不会影响你的系统的性能呢？由于大部分Oracle IO都是在块级别上完成(我们将数据块读入到数据库高速缓冲区,我们将数据块写入到数据文件),任何特定区间内的数据块的位置都是无关的,答案或许是no.但有些时候,当我们在一个单一读请求(全表扫描 (TableScan)或者索引快速全扫描(Index Fast Full Scan))中尝试读取多个相邻的数据块时;如果我们的“物理上连续”的表却是“逻辑上被拆分”到了很多个区间,这会不会有问题呢?

假如说,每个区间都只能是64K,这会限制我们将发起的“db file multiblock read”请求的大小吗或者这些请求可以跨越区间边界读取吗?如果这个表空间是有两个(或多个)数据文件组成,而这些区间又是以“轮流”在两个文件之间分配的,这会影响读操作的方式吗?如果我们尝试进行并行表扫描,这些限制在“direct path read”上会不会有所不同呢?如果你的运行系统是一个数据仓库,需要花费大量的时间运行这种操作,那么这些就是你需要回答的问题.(例如,参见我3年前写的关于运行并行查询时的部分IO异常的记录,以及Christian Antognini在大约几年后描述的Oracle 11g中的一个相关改进.)

只有当你开始想清楚你理解“碎片”到底是什么,你才可以理解它可能导致的问题,以及为什么它会(或不会)对你的系统造成问题的理由. 在第二部分中,我将讨论你该如何考虑表级别以及表空间级别的碎片问题.

No related posts.

什么是Cache？ 什么是Buffer？ 二者的区别是什么？

http://wenda.tianya.cn/wenda/thread?tid=595a1d68b3009fed

Buffer和Cache的区别
buffer与cache操作的对象就不一样。

buffer（缓冲）是为了提高内存和硬盘（或其他I/0设备）之间的数据交换的速度而设计的。

cache（缓存）是为了提高cpu和内存之间的数据交换速度而设计，也就是平常见到的一级缓存、二级缓存、三级缓存。

cpu在执行程序所用的指令和读数据都是针对内存的，也就是从内存中取得的。由于内存读写速度慢，为了提高cpu和内存之间数据交换的速度，在cpu和内存之间增加了cache，它的速度比内存快，但是造价高，又由于在cpu内不能集成太多集成电路，所以一般cache比较小，以后intel等公司为了进一步提高速度，又增加了二级cache，甚至三级cache，它是根据程序的局部性原理而设计的，就是cpu执行的指令和访问的数据往往在集中的某一块，所以把这块内容放入cache后，cpu就不用在访问内存了，这就提高了访问速度。当然若cache中没有cpu所需要的内容，还是要访问内存的。

缓冲（buffers）是根据磁盘的读写设计的，把分散的写操作集中进行，减少磁盘碎片和硬盘的反复寻道，从而提高系统性能。linux有一个守护进程定期清空缓冲内容（即写入磁盘），也可以通过sync命令手动清空缓冲。举个例子吧：我这里有一个ext2的U盘，我往里面cp一个3M的MP3，但U盘的灯没有跳动，过了一会儿（或者手动输入sync）U盘的灯就跳动起来了。卸载设备时会清空缓冲，所以有些时候卸载一个设备时要等上几秒钟。

修改/etc/sysctl.conf中的vm.swappiness右边的数字可以在下次开机时调节swap使用策略。该数字范围是0～100，数字越大越倾向于使用swap。默认为60，可以改一下试试。–两者都是RAM中的数据。

简单来说，buffer是即将要被写入磁盘的，而cache是被从磁盘中读出来的。

buffer是由各种进程分配的，被用在如输入队列等方面。一个简单的例子如某个进程要求有多个字段读入，在所有字段被读入完整之前，进程把先前读入的字段放在buffer中保存。

cache经常被用在磁盘的I/O请求上，如果有多个进程都要访问某个文件，于是该文件便被做成cache以方便下次被访问，这样可提高系统性能。

No related posts.

OS : Windows XP (Intel T7250 ,3G mem) +
soft : Oracle 9201 32位

No related posts.