《我对后端优化的一点想法 ().ppt》由会员分享，可在线阅读，更多相关《我对后端优化的一点想法 ().ppt（28页珍藏版）》请在三一办公上搜索。
1、DTCC2012,Jametong童家旺workalipay(2010.8-)workalibaba(2005.5-2010.8)work浙江移动台州公司(2003.12-2005.5)Blog http:/,Weibo Jametong,DTCC2012,什么是优化?,响应时间 Vs 吞吐量,性能与可伸缩性（Performance Vs Scalability)Instrument&metrics需要了解的一点硬件知识常见案例分析引用资料,DTCC2012,The fastest way to do something isdont do it,Anonymous,Two ways to i
2、mprove performance,doit less or do it faster,Anonymous,Performance is all about code path,From Cary Millsap,http:/,DTCC2012,不访问不必要的数据使用B*Tree/hash等方法定位必要的数据使用column Store或分表的方式将数据分开存储合理的利用硬件来提升访问效率使用缓存消除对数据的重复访问使用批量处理来减少交互次数（磁盘、网络）使用新硬件来降低后端的延时，提高效率提高系统的吞吐量对工作单元进行细化，减少串行操作优化硬件配置，提高整体的TCO与硬件利用率,合理的拆分
3、（水平、垂直拆分）以提高系统的整体吞吐能力,DTCC2012,性能,衡量完成特定任务的速度或效率,响应时间,衡量系统与用户交互式多久能够收到响应,吞吐量,衡量系统在单位时间里可以完成的任务量,DTCC2012,Response Time=Service Time+Queue Time,经典的响应时间曲线.到达率为1.55trx/s,响应时间为3ms/Trx,服务时间为2ms/Trx,排队时间为1ms/trx,DTCC2012,450400350,300250200150,线性扩展Amdahl扩展(f=0.3)Amdahl扩展(f=0.2)Amdahl扩展(f=0.1)USL扩展(0.1,0.1
4、),USL扩展(0.1,0.2)10050,0,0,2,4,6,8,10,12,14,16,18,20,22,DTCC2012,Amdahls law,使用多处理器进行 并行处理能够提升的性能的比例受限于程序中需要串行处理的比例,USL Scalability,使用多处理器进行 并行处理能够提升的性能的比例不仅受限于程序中需要串行处理的比例,还受限于进程之间的并发系数.,DTCC2012,What gets measured getsmanaged.,Peter Drucker(彼得.德鲁克),Dont guess,get the data,Anonymous,DTCC2012,从杭州北京（花
5、费了6个半小时）,DTCC2012,从杭州北京（花费了6个半小时）13:00 13:15 从公司下楼到淘宝(15分钟)13:30 13:50 从淘宝出发到上出租车(20分钟)14:00-15:00 在出租车上,从淘宝机场(60分钟)15:10-15:20 拿机票(10分钟)15:25-15:50 安检(25分钟)16:00 17:00 在机场候机(60分钟)17:00-18:20 飞机上,杭州北京(80分钟)18:20-18:40 到出租车上车点(20分钟)18:40-18:55 等待出租车(15分钟),18:55-19:50 机场到酒店(55分钟),DTCC2012,Metrics,v$sy
6、s_time_model&v$sess_time_modelv$sysstat&v$sesstat,v$system_event&v$session_eventv$session_wait&v$event_histogram,Instrument,Extended 10046 trace,DTCC2012,vmstat&iostat&netstat&tcprstat&sarstrace&oprofile&systemtapaspersa&latencytop&top,oraclemytest$ps-ef|grep dbworacle 8323 1 0 2010?00:42:29 ora_dbw
7、0_mytestoraclemytest$strace-c-p 8323Process 8323 attached-interrupt to quitProcess 8323 detached%time seconds usecs/call calls errors syscall-98.39 0.007194 37 195 pwrite1.61 0.000118 0 644 times0.00 0.000000 0 1 read0.00 0.000000 0 1 open0.00 0.000000 0 1 close0.00 0.000000 0 10 getrusage0.00 0.000
8、000 0 11 11 semtimedop-100.00 0.007312 863 11 total,DTCC2012,L1 cache reference 0.5 ns(1GHz CPU)Branch mispredict 5 nsL2 cache reference 7 nsMutex lock/unlock 25 ns,Main memory reference 100 ns,Compress 1K bytes with Zippy 3,000 ns,Send 2K bytes over 1 Gbps network 20,000 nsRead 1 MB sequentially fr
9、om memory 250,000 nsRound trip within same datacenter 500,000 nsDisk seek 10,000,000 ns(7200rpm SATA)Read 1 MB sequentially from disk 20,000,000 nsSend packet CA-Netherlands-CA 150,000,000 ns,DTCC2012,传统磁盘的IO特性,Nand Flash本身的IO特性,Read 25s,Write（program）250 sErase 2000 s,Intel 320 SSD,Read 75 sWrite 9
10、0 s,Fusion-IO,Read:68sWrite:15s,Storage通道的处理延时,10GbE的Latency：10-50 s,Fabric Channel 的latency：20-50 sInfiniBand 的Latency：1-3 s,DTCC2012,FC Channel Infiniband,设备延时对比（s）25002000150010005000,read write erase ReadNand Flash Nand Flash Nand Flash Intel 320Chip Chip Chip SSD,write Read writeIntel 320 Fusio
11、n-IO Fusion-IOSSD,transfer10GbE,transfer transferDTCC2012,优化传统B*Tree 优化数据访问,如何更好的设计索引,使用Write Optimized B-Tree优化数据访问,Stratified B-trees（Acunu),LSM tree（BigTable,Cassandra,LevelDB）Fractal Tree Indexes(TokuDB),使用基于Hash的算法访问数据,Oracle Hash Cluster，BDB，Bitcask,DTCC2012,DTCC2012,模拟场景,表中有5个字段(id,status,typ
12、e,gmt_create,content)主要基于三个字段的组合进行查询,字段status,type总共有30个组合(status 5个值,type 6个值)每天有10000条记录,时间随机分布(共60天的数据),执行的查询,分页取第一个20条记录,select id,status,type,gmt_create,content from(selectid,status,type,gmt_create,content,rownum rn,from(select id,status,type,gmt_create,content from james_t,where status=00 and
13、type=05 and gmt_create=trunc(sysdate)andgmt_create trunc(sysdate+1),order by gmt_create desc)where rownum=0;分别创建三种不同的索引进行测试,create index james_t_idx on james_t(status,type,gmt_create);create index james_t_idx on james_t(status,gmt_create);create index james_t_idx on james_t(gmt_create,status,type);,
14、24,27,130,130,27,1,5,index columnsstatus,type,gmt_creategmt_create,status,typestatus,gmt_createno index,descriptionindex accessindex access+index filterindex access+table filterfull table scan,Logical Reads53470,Logical Readsfull table scanindex access+table filterindex access+index filter,Logical R
15、eads,53470,index access,2425,125,625,DTCC20123125 15625 78125,场景介绍表VeryBigTable含有30个列表的记录数为50,000,000条平均每个用户为300条左右其中有2个列属于详细描述字段,平均长度为2k其它的列的总长度平均为250个字节此表上的查询有两种模式列出表中的主要信息(每次20条,不包含详细信息,90%的查询)查看记录的详细信息(10%的查询)保存在Oracle数据库中,默认block size(8k)要求对此业务进行优化,分析数据,说服开发部门实施此优化,DTCC2012,性能分析,每块记录数,8192*0.80
16、(1)/250=25.5(主表)8192*0.80/2000=3.27(详情表)8192*0.80/(2000+250)=2.91,访问的逻辑IO(内存块访问),List的查询代价,改进后=(300/25.5)*y+4+x=4+x+11.8y=42+73+11.8*1.54=28.7改进前=(300/2.91)*y+4+x=4+x+103.y=4+7+103*1.5=165.5,访问涉及到的物理读(磁盘块访问),List的查询代价(逻辑IO*(1 命中率)改进后=28.7*(1 0.855)=4.305改进前=165.5*(1 0.85)=24.825,访问时间(ms),改进后=逻辑IO时间+
17、物理IO时间=28.7*0.016+4.305*77=30.422ms改进前=逻辑IO时间+物理IO时间=165.5*0.01+24.825*7=175.43ms,DTCC2012,使用场景缓存的一致性维护问题数据的具体读写比变更频率业务对一致性的要求使用何种缓存方式.注意事项考虑缓存的刷新策略考虑缓存的数据延迟对业务的影响考虑缓存失效时,系统的支撑能力,参考缓存工具:MemCached,Tair,Redis,DTCC2012,16,14121086420,elapsed timeLogical Reads,elapsed timeLogical Reads,12000010000080000
18、6000040000200000DTCC2012,在有批量需求的情况下,尽可能提供批量处理接口,如memcached的multiget,或者,cassandra的getslice,针对RDBMS,可以使用批量接口(如Oracle的Array Interface).不要设置过大的批次大小,这需要与对应的程序heap 空间,设置过大可能会导致程序出现OOM错误网络send/receive_buffer大小,(/proc/sys/net/core/wmem|rmem_max|default),DTCC2012,Five minute rule?,Price/Performance Break Poi
19、nt?,一台机器配置的代价,机架成本,电力成本（机器电力？Cooling？),CPU license成本（Oracle？Veritas？）机器成本？,使用PCI-E SSD？,使用HBA？InfiniBand？交换机？多使用内存？多使用磁盘？单机故障对业务的影响代价？,DTCC2012,Optimizing Oracle PerformanceBy Cary Millsap,Jeff HoltForecasting Oracle PerformanceBy Craig ShallahamerGuerrilla Capacity PlanningBy Neil J.GuntherRelational Database Index Design and the OptimizersBy Tapio LahdenmakiThink Clearly About PerformanceBy Cary Millsaphttp:/www.method-Oracle PerformanceBy Christian Antognini,性能诊断艺术Translated By 冯大辉/胡怡文/童家旺,DTCC2012,Q&A,DTCC2012,
