《我对后端优化的一点想法 ()》由会员分享，可在线阅读，更多相关《我对后端优化的一点想法 ()（28页珍藏版）》请在金锄头文库上搜索。
1、DTCC2012Jametong童家旺workalipay (2010.8-)workalibaba(2005.5-2010.8)work浙江移动台州公司 (2003.12-2005.5)Blog http:/ Weibo JametongDTCC2012什么是优化?响应时间 Vs 吞吐量性能与可伸缩性（Performance Vs Scalability)Instrument & metrics需要了解的一点硬件知识常见案例分析引用资料DTCC2012The fastest way to do something isdont do itAnonymousTwo ways to improv
2、e performance, doit less or do it fasterAnonymousPerformance is all about code pathFrom Cary Millsaphttp:/ Store或分表的方式将数据分开存储合理的利用硬件来提升访问效率使用缓存消除对数据的重复访问使用批量处理来减少交互次数（磁盘、网络）使用新硬件来降低后端的延时，提高效率提高系统的吞吐量对工作单元进行细化，减少串行操作优化硬件配置，提高整体的TCO与硬件利用率合理的拆分（水平、垂直拆分）以提高系统的整体吞吐能力DTCC2012性能衡量完成特定任务的速度或效率响应时间衡量系统与用户交互式
3、多久能够收到响应吞吐量衡量系统在单位时间里可以完成的任务量DTCC2012Response Time = Service Time + Queue Time经典的响应时间曲线.到达率为1.55trx/s,响应时间为3ms/Trx,服务时间为2ms/Trx,排队时间为1ms/trxDTCC2012450400350300250200150线性扩展Amdahl扩展扩展(f=0.3)Amdahl扩展扩展(f=0.2)Amdahl扩展扩展(f=0.1)USL扩展扩展(0.1,0.1)USL扩展扩展(0.1,0.2)1005000246810121416182022DTCC2012Amdahls law
4、使用多处理器进行 并行处理能够提升的性能的比例受限于程序中需要串行处理的比例USL Scalability使用多处理器进行 并行处理能够提升的性能的比例不仅受限于程序中需要串行处理的比例,还受限于进程之间的并发系数.DTCC2012What gets measured getsmanaged.Peter Drucker (彼得. 德鲁克 )Dont guess, get the dataAnonymousDTCC2012从杭州北京（花费了6个半小时）DTCC2012从杭州北京（花费了6个半小时）13:00 13:15 从公司下楼到淘宝(15分钟)13:30 13:50 从淘宝出发到上出租车(2
5、0分钟)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分钟)DTCC2012Metricsv$sys_time_model & v$sess_time_modelv$sysstat & v$sesstatv$system_event & v$s
6、ession_eventv$session_wait & v$event_histogramInstrumentExtended 10046 traceDTCC2012vmstat & iostat & netstat & tcprstat &sarstrace & oprofile & systemtapaspersa & latencytop & toporaclemytest $ ps -ef | grep dbworacle 8323 1 0 2010 ? 00:42:29 ora_dbw0_mytestoraclemytest $ strace -c -p 8323Process 8
7、323 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.000000 0 11 11 semtimedop- - - - -
8、-100.00 0.007312 863 11 totalDTCC2012L1 cache reference 0.5 ns(1GHz CPU)Branch mispredict 5 nsL2 cache reference 7 nsMutex lock/unlock 25 nsMain memory reference 100 nsCompress 1K bytes with Zippy 3,000 nsSend 2K bytes over 1 Gbps network 20,000 nsRead 1 MB sequentially from memory 250,000 nsRound t
9、rip 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 nsDTCC2012传统磁盘的IO特性Nand Flash本身的IO特性Read 25sWrite（program） 250 sErase 2000 sIntel 320 SSDRead 75 sWrite 90 sFusion-IORead : 68sWrite: 15s
10、Storage通道的处理延时10GbE的Latency ： 10-50 sFabric Channel 的latency：20-50 sInfiniBand 的Latency ：1-3 sDTCC2012FC Channel Infiniband设备延时对比（设备延时对比（s）25002000150010005000read write erase ReadNand Flash Nand Flash Nand Flash Intel 320Chip Chip Chip SSDwrite Read writeIntel 320 Fusion-IO Fusion-IOSSDtransfer10Gb
11、Etransfer 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，BitcaskDTCC2012DTCC2012模拟场景表中有5个字段(id, status, type, gmt_create, content)主要基于三个字段的组合进行查询字
12、段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 rnfrom ( select id,status,type,gmt_create,content from james_twhere status = 00 and type = 05 and gmt_create = trunc(sy
13、sdate) 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);24271301302715index co
14、lumnsstatus, type, gmt_creategmt_create, status, typestatus, gmt_createno indexdescriptionindex accessindex access + index filterindex access + table filterfull table scanLogical Reads53470Logical Readsfull table scanindex access + table filterindex access + index filterLogical Reads53470index acces
15、s2425125625DTCC20123125 15625 78125场景介绍表VeryBigTable含有30个列表的记录数为50,000,000条平均每个用户为300条左右其中有2个列属于详细描述字段,平均长度为2k其它的列的总长度平均为250个字节此表上的查询有两种模式列出表中的主要信息(每次20条,不包含详细信息,90%的查询)查看记录的详细信息(10%的查询)保存在Oracle数据库中,默认block size(8k)要求对此业务进行优化分析数据,说服开发部门实施此优化DTCC2012性能分析每块记录数8192 * 0.80(1) / 250 = 25.5 (主表)8192 * 0.
16、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改进前
17、=165.5 * ( 1 0.85 ) = 24.825访问时间(ms)改进后=逻辑IO时间+物理IO时间= 28.7 * 0.016 + 4.305 * 77 = 30.422ms改进前=逻辑IO时间+物理IO时间= 165.5 * 0.01 + 24.825 * 7 = 175.43msDTCC2012使用场景缓存的一致性维护问题数据的具体读写比变更频率业务对一致性的要求使用何种缓存方式.注意事项考虑缓存的刷新策略考虑缓存的数据延迟对业务的影响考虑缓存失效时,系统的支撑能力参考缓存工具: MemCached, Tair, RedisDTCC20121614121086420elapsed
18、timeLogical Readselapsed timeLogical Reads120000100000800006000040000200000DTCC2012在有批量需求的情况下,尽可能提供批量处理接口,如memcached的multiget,或者cassandra的getslice,针对RDBMS,可以使用批量接口(如Oracle的Array Interface).不要设置过大的批次大小这需要与对应的程序heap 空间设置过大可能会导致程序出现OOM错误网络send/receive_buffer大小(/proc/sys/net/core/wmem|rmem_max|default)D
19、TCC2012Five minute rule?Price / Performance Break Point?一台机器配置的代价机架成本电力成本（机器电力？Cooling？)CPU license成本（Oracle？Veritas ？）机器成本？使用PCI-E SSD？使用HBA？InfiniBand？交换机？多使用内存？多使用磁盘？单机故障对业务的影响代价？DTCC2012Optimizing 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 冯大辉/胡怡文/童家旺DTCC2012Q&ADTCC2012
