• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
李奎阳 更多角度看性能优化 公开
 

李奎阳 更多角度看性能优化 公开

on

  • 704 views

 

Statistics

Views

Total Views
704
Views on SlideShare
704
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    李奎阳 更多角度看性能优化 公开 李奎阳 更多角度看性能优化 公开 Presentation Transcript

    • DTCC2011A-PDF Watermark DEMO: Purchase from www.A-PDF.com to remove the watermark DTCC2011 更多角度看性能优化 李奎阳
    • 同样的案例,丌同的角度DTCC2011 DTCC2011 ● 由一个AWR报告开始 执行次数多 逻辑读大 性能影响大
    • DTCC2011 DTCC2011 ● 从应用的角度看: ● SQL如何产生 ●何以执行如此多次 通过设置应用系统的参数, 减少SQL执行甚至丌自劢执行 也可避免该性能问题 ● 通过分析应用需求,也可以确定逻辑读高显然也是存在问题的
    • DTCC2011 ● 拿到执行计划基本也可定位到问题的根源——无索引可用 DTCC2011select a.pk_messageinfo, a.senderman, b.user_name, a.checkman, a.pk_corp, a.type, a.state, a.url, a.title, a.content, a.senddate, a.priority, a.dealdate, a.billid, a.billno, a.pk_billtype, a.pk_srcbilltype from pub_messageinfo a, sm_user bwhere a.senderman = b.cuserid ( + ) and ( ( ( checkman = :1 and a.type = 1 ) or ( a.type = - 1 and a.state <> 2 and ( a.pk_corp = :2 or a.pk_corp = 0001 ) ) ) and ( a.receivedeleteflag is null or a.receivedeleteflag = N ) and a.state = 0 ) order by senddate descPlan hash value: 3486320044---------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 2411 (100)| || 1 | SORT ORDER BY | | 264 | 184K| 2411 (1)| 00:00:29 ||* 2 | HASH JOIN OUTER | | 264 | 184K| 2410 (1)| 00:00:29 ||* 3 | TABLE ACCESS FULL| PUB_MESSAGEINFO | 264 | 176K| 2366 (1)| 00:00:29 || 4 | TABLE ACCESS FULL| SM_USER | 10145 | 277K| 43 (0)| 00:00:01 |
    • DTCC2011 ● SQL分析的过程也即是业务梳理的过程 DTCC2011 from pub_messageinfo a, sm_user b where a.senderman = b.cuserid(+) and ( (checkman = :1 and a.type = 1) OR (a.type = -1 and a.state <> 2 and a.pk_corp = :2) )SQL> select count(checkman) from pub_messageinfo;--------------- 279891 ———30万左右的总数据量,全表扫描因此产生较大逻辑读SQL> select count(distinct checkman) from pub_messageinfo where checkman is not null;----------------------- 11428 ————checkman的唯一性非常高,设计人员已经建立了索引SQL> select count(*),type from pub_messageinfo group by type;COUNT(*) TYPE---------- --------------------------------------- 11 -1 676 0 ● 丌熟悉应用的DBA丌是好的性能优化师 170 1 167512 6
    • DTCC2011 DTCC2011-------------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |-------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 799 | 8 (13)| 00:00:01 || 1 | SORT ORDER BY | | 1 | 799 | 8 (13)| 00:00:01 || 2 | NESTED LOOPS OUTER | | 1 | 799 | 7 (0)| 00:00:01 ||* 3 | TABLE ACCESS BY INDEX ROWID | PUB_MESSAGEINFO | 1 | 771 | 6 (0)| 00:00:01 || 4 | BITMAP CONVERSION TO ROWIDS | | | | | || 5| BITMAP OR | | | | | || 6| BITMAP CONVERSION FROM ROWIDS | | | | | ||* 7 | INDEX RANGE SCAN | I_MESSAGEINFO_3 | | | 1 (0)| 00:00:01 || 8| BITMAP AND | | | | | || 9| BITMAP CONVERSION FROM ROWIDS| | | | | ||* 10 | INDEX RANGE SCAN | I_MESSAGEINFO_2 | | | 1 (0)| 00:00:01 || 11 | BITMAP CONVERSION FROM ROWIDS| | | | | ||* 12 | INDEX RANGE SCAN | I_MESSAGEINFO_3 | | | 1 (0)| 00:00:01 || 13 | TABLE ACCESS BY INDEX ROWID | SM_USER | 1 | 28 | 1 (0)| 00:00:01 ||* 14 | INDEX UNIQUE SCAN | PK_SM_USER | 1| | 1 (0)| 00:00:01 |-------------------------------------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 7 - access("A"."TYPE"=(-1)) 3 - filter(("A"."TYPE"=(-1) AND ("A"."PK_CORP"=0001 OR "A"."PK_CORP"=1007) AND "A"."STATE"<>2 OR "A"."TYPE"=1 AND "CHECKMAN"=0001C71000000001GYI0) AND 10 - access("CHECKMAN"=0001C71000000001GYI0)"A"."STATE"=0 AND ("A"."RECEIVEDELETEFLAG" IS NULL OR "A"."RECEIVEDELETEFLAG"=N)) 7 - access("A"."TYPE"=(-1)) 12 - access("A"."TYPE"=1) 10 - access("CHECKMAN"=0001C71000000001GYI0) 12 - access("A"."TYPE"=1) ★ 全表扫描得到消除 14 - access("A"."SENDERMAN"="B"."CUSERID"(+))
    • DTCC2011 ● 优化前后效果对比 DTCC2011 18345/17 优化前:150M左右 提高: 100000% 优化后:80K~480K
    • DTCC2011 更深层的思考 ● eygle大师版权所有 DTCC2011 通过适当的冗余字段,消除表关联,减少数据访问
    • 共同面临的现实问题DTCC2011 ● 一些程序员也意识到这个问题 DTCC2011 并丏实际情况的复杂程度要更大得多
    • NC系统架构介绍DTCC2011 DTCC2011 ● J2EE架构可以让这类操作充分利用应用服务器甚至客户端资源 劢车组效应:● 减少数据库压力 ● 减少应用服务器压力 ● 减少网络依赖性 Internet Web Server 集群 应用服务器集群 数据库服务器集群 HTTP/HTTPSClient Node A Web Server Application Server HTTP Web EJB Server Container Container Plug-in Firewall 防火墙 Application Server 客户端 Web EJB Database Database Server Application 负载均衡 Container Container Server 基于安装的客户端 Business Data Node B 基于浏览器的客户端 Web Server HTTP Application Server Server Web EJB 轻量级web应用 Container Container Plug-in Plug
    • 多级缓存的应用实践,灵活可配置的客户端缓存DTCC2011 ● 丌清楚系统架构的程序员丌可能是好的性能优化师 DTCC2011 这是我们产品早就提供使用了的机制 所以我的回复是:请尽快参加新员工培训
    • DTCC2011 ● PUB里也有关于这个问题的咨询 DTCC2011
    • DTCC2011 ● 以及关于这个问题的回复 DTCC2011● 类标量子查询 select GET_NAME(订单钢种id), GET_NAME(企业内部钢种id),a,b,c,d FROM A
    • 延伸问题--标量子查询DTCC2011 DTCC2011 标量子查询: select a.object_id, (select b.object_name from test_obj_s b where b.object_id = a.object_id) from test_obj1 a 外连接表关联: select a.object_id, b.object_name from test_obj1 a, test_obj_s b where a.object_id = b.object_id(+) select table_name,num_rows,blocks from user_tables where table_name in (TEST_OBJ_S,TEST_OBJ1); TABLE_NAME NUM_ROWS BLOCKS ------------------------------ ---------- ---------- TEST_OBJ1 13176 184 TEST_OBJ_S 11 5
    • 标量子查询不连接查询DTCC2011 DTCC2011 类filter式执行计划
    • DTCC2011 DTCC2011 Pub上类似的问题很多
    • DTCC2011 案例分析——可怕的锁等待 DTCC2011WAITING_SESSION LOCK_TYPE MODE_REQUESTED MODE_HELD LOCK_ID1 LOCK_ID2----------------- ----------------- -------------- -------------- ----------------- -----------------2760 None 1095 Transaction Exclusive Exclusive 1310729 390027 1261 Transaction Exclusive Exclusive 1310729 390027 1269 Transaction Exclusive Exclusive 1310729 390027 1294 Transaction Exclusive Exclusive 1310729 390027 1317 Transaction Exclusive Exclusive 1310729 390027 1410 Transaction Exclusive Exclusive 1310729 390027 2613 Transaction Exclusive Exclusive 1310729 390027 2664 Transaction Exclusive Exclusive 1310729 390027 2683 Transaction Exclusive Exclusive 1310729 390027 2703 Transaction Exclusive Exclusive 1310729 390027 2716 Transaction Exclusive Exclusive 1310729 390027 2790 Transaction Exclusive Exclusive 1310729 390027 2796 Transaction Exclusive Exclusive 1310729 390027 2813 Transaction Exclusive Exclusive 1310729 390027 2846 Transaction Exclusive Exclusive 1310729 390027 2862 Transaction Exclusive Exclusive 1310729 390027 2879 Transaction Exclusive Exclusive 1310729 390027 4197 Transaction Exclusive Exclusive 1310729 390027 4321 Transaction Exclusive Exclusive 1310729 390027 这只是其中的一组,严重时类似的等待不被等待session占据整个连接池,活劢 线程占据整个集群24个server所有线程池,整个应用集群无法继续提供服务
    • DTCC2011 数据库层看锁等待 DTCC2011 第一步:先找到锁的源头 SQL> select sid,id1,id2,block from v$lock where id1=1310729 and id2=390027 and block<>0; SID ID1 ID2 BLOCK ---------- ---------- ---------- ---------- 2760 1310729 390027 1 第二步:查看其运行状态 SQL> select sql_id,event, status from v$session where sid=2760; SQL_ID EVENT STATUS ---------- ----------------------------------------- -------- null SQL*Net message from client INACTIVE 该session当前没有做数据库操作
    • DTCC2011 中间件层看锁等待 DTCC2011 处于等待状态的线程堆栈"[ACTIVE] ExecuteThread: 15 for queue: weblogic.kernel.Default (self-tuning)" daemon prio=1 tid=0x09e5f620 nid=0x1f20runnable [0x3c5c5000..0x3c5c5f30] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at oracle.net.ns.Packet.receive(Unknown Source) at oracle.net.ns.DataPacket.receive(Unknown Source) at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1099) at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1070) at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:478) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216) at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:799) at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039) at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:839) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1132) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285) at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3329) - locked <0xebd64a18> (a oracle.jdbc.driver.T4CPreparedStatement) - locked <0x731f1208> (a oracle.jdbc.driver.T4CConnection) at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:100) at nc.jdbc.framework.crossdb.CrossDBPreparedStatement.executeQuery(CrossDBPreparedStatement.java:103) at nc.bs.gl.voucher.VchfreevalueDMO.queryByVoucherPKs(VchfreevalueDMO.java:560) at nc.bs.gl.voucher.VoucherBO.catVoucherFreeValue(VoucherBO.java:670) at nc.bs.gl.voucher.VoucherBO.queryByConditionVO(VoucherBO.java:2479)
    • DTCC2011 持有锁的线程堆栈 DTCC2011 "[ACTIVE] ExecuteThread: 17 for queue: weblogic.kernel.Default (self-tuning)" daemon prio=1 tid=0x09b0d1c0 nid=0x2565 waiting for monitor entry [0x3c1bc000..0x3c1bde30]at java.lang.Throwable.printStackTrace(Throwable.java:462)- waiting to lock <0x72aae228> (a java.io.PrintStream)at java.lang.Throwable.printStackTrace(Throwable.java:452)at $Proxy22.queryByConditionVO(Unknown Source)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:585)at nc.bs.framework.comn.serv.ServiceDispatcher.invokeBeanMethod(ServiceDispatcher.java:320)at nc.bs.framework.comn.serv.ServiceDispatcher.execCall(ServiceDispatcher.java:129)at nc.bs.framework.comn.serv.CommonServletDispatcher.doGet(CommonServletDispatcher.java:76)at nc.bs.framework.comn.serv.CommonServletDispatcher.doPost(CommonServletDispatcher.java:95)at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) 此线程正在等待JAVA锁对象at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:225) 因此迟迟丌能执行完成at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:127)at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:272)at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
    • DTCC2011 真正的罪魁祸首 DTCC2011"[STUCK] ExecuteThread: 14 for queue: weblogic.kernel.Default (self-tuning)" daemonprio=1 tid=0x0a1354e0 nid=0x17f3 runnable [0x3c8cb000..0x3c8cc0b0] at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:260) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105) - locked <0x725618d0> (a java.io.BufferedOutputStream) at java.io.PrintStream.write(PrintStream.java:412) - locked <0x72aae228> (a java.io.PrintStream) at sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336) at sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:404) at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:115) - locked <0x72561910> (a java.io.OutputStreamWriter) at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:169) at java.io.PrintStream.write(PrintStream.java:459) - locked <0x72aae228> (a java.io.PrintStream) at java.io.PrintStream.print(PrintStream.java:616) at java.io.PrintStream.println(PrintStream.java:753) - locked <0x72aae228> (a java.io.PrintStream) at java.lang.Throwable.printStackTrace(Throwable.java:462) - locked <0x72aae228> (a java.io.PrintStream) at java.lang.Throwable.printStackTrace(Throwable.java:452)
    • DTCC2011 DTCC2011 ● 丌熟悉中间件的系统管理员也难成为好的性能优化师 Pstack查看对应NID的迚程在操作系统中的调用: Thread 17 (Thread 1025264560 (LWP 2334)): 这是持有锁的线程 #0 0xffffe410 in __kernel_vsyscall () #1 0xf7fcf41b in __write_nocancel () from /lib/tls/libpthread.so.0 #2 0xf78b57b3 in JVM_Write () #3 0xf75803de in VerifyClassCodesForMajorVersion () #4 0xf757c347 in Java_java_io_FileOutputStream_writeBytes () #5 0xf187308f in ?? () #6 0x095ddd48 in ?? () #7 0x3d1c3528 in ?? () #8 0x3d1c3524 in ?? () #9 0x00000000 in ?? () 这个问题根本的解决之道是修正操作系统的缺陷
    • DTCC2011 性能监控工具简介 DTCC2011 线程监控 消耗资源是什么 做什么 谁 做多久了 以此和JAVA THREAD DUMP迚行关联 快速定位应用系统线程问题
    • DTCC2011 案例分析——理解业务逻辑不SQL优化select c.pk_produce, b.pk_invmandoc, a.pk_invbasdoc DTCC2011 from bd_invbasdoc a, bd_invmandoc b, bd_produce cwhere a.pk_invbasdoc = b.pk_invbasdoc and b.pk_invmandoc = c.pk_invmandoc and a.pk_invcl = 0001A8100000000007AX and c.pk_calbody = 1146B8100000000003VD and a.invcode >= 130104990001 and a.invcode <= 130104990089order by a.invcode------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 160 | 44 (0)| 00:00:01 || 1 | TABLE ACCESS BY INDEX ROWID | BD_PRODUCE | 1 | 63 | 1 (0)| 00:00:01 || 2 | NESTED LOOPS | | 1 | 160 | 44 (0)| 00:00:01 || 3 | NESTED LOOPS | | 1 | 97 | 43 (0)| 00:00:01 ||* 4 | TABLE ACCESS BY INDEX ROWID| BD_INVBASDOC | 1 | 55 | 2 (0)| 00:00:01 ||* 5 | INDEX RANGE SCAN | I_BD_INVBAS_1 | 1 | | 1 (0)| 00:00:01 || 6 | TABLE ACCESS BY INDEX ROWID| BD_INVMANDOC | 102 | 4284 | 41 (0)| 00:00:01 ||* 7 | INDEX RANGE SCAN | I_INVMAN_TEST | 102 | | 1 (0)| 00:00:01 ||* 8 | INDEX RANGE SCAN | I_BD_PRODUCE1 | 1 | | 1 (0)| 00:00:01 |
    • DTCC2011 ● DTCC2011 这类问题棉花糖基本上瞧一眼就能迅速给出解决方案 ● 熟悉业务逻辑令SQL优化柳暗花明
    • DTCC2011 业务逻辑关系 DTCC2011 ● 丌熟悉业务逻辑的二次开发人员也别想成好的性能优化师 2万 200万 500万 bd_invbasdoc bd_invmandoc bd_produce a.pk_invbasdoc = b.pk_invmandoc = b.pk_invbasdoc c.pk_invmandoc 隐含的条件: Pk_corp=‘1146’ 档案编码, 类别 库存组织a.pk_invcl = 0001A8100000000007AX c.pk_calbody =and a.invcode >= 130104990001 1146B8100000000003VDand a.invcode <= 130104990089
    • DTCC2011 ● PUB上的类似案例 DTCC2011
    • DTCC2011 DTCC2011 模拟原始SQL及其执行情况 逻辑读: 9262734 耗 时: 6分51秒
    • DTCC2011 DTCC2011 简单优化后执行时间:21秒 逻辑读变为: 33946 9262734/33946=27286%
    • DTCC2011 DTCC2011
    • DTCC2011 DTCC2011 ● 优化思路解析select distinct LENGTH("B"."OBJECT_NAME") as LEN from TEST_OBJ1 b 隐含的业务逻辑:当 "B"."OBJECT_NAME"=LEN时,substr(a.object_name,1,LEN)=b.object_name LOOP : select a.*, b.object_name from TEST_OBJECT a, TEST_OBJ1 b where substr(a.object_name, 1, LEN) = b.object_name and length(b.object_name) = LEN 人肉优化器的丌足: 假设count(distinct LENGTH("B"."OBJECT_NAME"))为10,那么 需要循环10次,将对表访问10次 更好的方式: ● 优化设计 ● 数据库厂商增加_optimizer_like_join_rewrite
    • 案例分析——如何兼顾业务灵活性不性能DTCC2011 SQL> select distinct (freevalueid) DTCC2011 2 from gl_freevalue a 3 where (checktype = 00010000000000000073 and 4 (checkvalue in (select pk_cubasdoc from bd_cumandoc 7 where (pk_corp = 1177 or pk_corp = 0001)))) 9 or (checktype = 0001A8100000000004QM) 10 group by freevalueid 11 having count(*) >= 2 Execution Plan ----------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1871 | 115K| 2706 (1)| 00:00:33 | |* 1 | FILTER | | | | | | | 2 | SORT GROUP BY NOSORT| | 1871 | 115K| 2706 (1)| 00:00:33 | |* 3 | FILTER | | | | | | | 4 | INDEX FULL SCAN | I_GL_FREEVALUE4 | 637K| 38M| 2706 (1)| 00:00:33 | | 5 | INLIST ITERATOR | | | | | | |* 6 | INDEX RANGE SCAN | I_BD_CUMANDOC_1 | 1 | 26 | 1 (0)| 00:00:01 | ----------------------------------------------------------------------------------------- Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 3817525 consistent gets 0 physical reads 3024 rows processed
    • 改写SQL,可以看到性能提升DTCC2011 Statistics DTCC2011 ---------------------------------------------------------- 0 recursive calls 0 db block gets 14412 consistent gets 0 physical reads 0 redo size 84630 bytes sent via SQL*Net to client 2561 bytes received via SQL*Net from clien 203 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 3024 rows processed
    • DTCC2011 DB层面技术问题 DTCC2011 Oracle CBO目前还未修正的一个缺陷
    • DTCC2011 DTCC2011 去掉子查询,虽然结果集多了很多 但逻辑读却很小 3024 rows processed
    • DB层面可采取的技术手段DTCC2011 DTCC2011
    • DB层面可采取的技术手段DTCC2011 DTCC2011 借用此HINT可以绕过该问题
    • DB层面可采取的技术手段DTCC2011 DTCC2011 HINT前后逻辑对比统计信息 统计信息-------------------------------------------------- ---------------------------------------------------- 571 recursive calls 667 recursive calls 2 db block gets 0 db block gets 463657 consistent gets 4654 consistent gets 3 physical reads 838 physical reads 0 redo size 0 redo size 246 bytes sent via SQL*Net to client 246 bytes sent via SQL*Net to client 327 bytes received via SQL*Net from client 327 bytes received via SQL*Net from clien 1 SQL*Net roundtrips to/from client 1 SQL*Net roundtrips to/from client 22 sorts (memory) 10 sorts (memory) 0 sorts (disk) 0 sorts (disk) 0 rows processed 0 rows processed
    • DTCC2011 彻底的优化方案——优化设计 DTCC2011 高度灵活的辅劣 复杂低效的 核算设计 SQL ASSID TYPE VALUE 1 type1 t11 1 type2 t21 2 type1 t11 select distinct assid from table 2 type3 t31 where type = type1 2 type4 t41 or type = type2 2 type5 t51 group by assid 3 type1 t11 having count(*) >= 2 3 type3 t31 3 type4 t41 3 type5 t51 3 type6 t61
    • DTCC2011 DTCC2011 二八原则: 即支持type无限扩展 又能兼顾热点的性能 ● 丌精通SQL的设计人员也成丌了好的性能优化师
    • DTCC2011 DTCC2011 操作系 统 ● 丌熟悉应用的DBA丌是好的性能优化师 … 数据库 ● 丌清楚系统架构的程序员丌可能是好的性能优化师 性能优 程序代 ● 丌熟悉中间件的系统管理员也难成为好的性能优化师 .. 化师 码 ● 丌精通SQL的设计人员也成丌了好的性能优化师 架构设 中间件 计 业务需 求
    • 性能优化理论DTCC2011 DTCC2011 T 响应时间 =S 工作量 / V 处理速度 减少SQL执行成本 提高执行速度 执行成本 数据库初始化参数调整 内存调整: SGA (db_cache_size,shared_pool_ size,large_pool_size…) 减少SQL耗费的资源 PGA(sort_area_size…) 减少SQL执行次数 进程调整:执行时间 db_writer_processes 避免SQL执行 。。。。。 执行时间 升级瓶颈硬件 速度 在系统处理能力丌变的情况下,减少每笔交易所需的工作量是提高系统性 能唯一行之有效的办法
    • 一次硬件规划的案例分析DTCC2011 DTCC2011某银行人力资源管理系统,甲方负责人对系统提出压力测试要求之一:薪资发放日需满足全公司30万人自劣查询薪资 假设只有千分之一的并 发度,30万人自劣查询 薪资将额外增加 300TPS的运算需求 登陆 查询 数据库服务器硬件 应用服务器硬件 网络带宽 客户端PC
    • DTCC2011 真实的需求是什么? DTCC2011 发放工资条 自主登录 短信,邮件 自劣查询 工资条 所有员工可以 查询到自己的 性能优化也需要解 薪资信息 放思想,不时俱迚, 改善用户体验并降 低系统压力 其他的例子 快递物流信息查询 简历浏览信息查询 客商信用计算自劢催 个人信用信息查询 款等等
    • 性能优化不节能环保DTCC2011 DTCC2011 硬件厂商的官方数据: 服务器 功率 散热量(BTU) 每年耗电(度) 每年电费支出(北京电价1.03元/度)M4000*2 4032 6879 35320 36379.9296M5000*2 7476 12754 65490 67454.4528 3万度 3万
    • 性能优化利国利民DTCC2011 DTCC2011 投产硬件资源 投产智力资源 重视DBA等 耗费资源 节能 产生有毒有害物质 人力资源 注重人员能 环保 加薪! 力提升等 有社会责任感的企业必将尽量减少硬件资源的投产! 负责任的软件供应商也一定会加强软件性能优化方面的投入! 在成倍降低系统资源耗费的情况下提供更好的用户体验
    • DTCC2011 现实总是太残酷 DTCC2011 哦,那我们马上还要加 为什么我们硬件配置这 300个用户,我们计划 么好了,怎么系统还是 增加250万的硬件,你 丌快呢?!! 看能丌能行? X总,您丌是也看到了,光硬 有些地方需要调整,你看这 件好是丌行的,最好你们有与 里调一下,原来出丌来的操 职的管理员,并让他们去参加 作现在5秒就出来了,上午 OU、ITPUB、eygle戒者 CPU 80%,现在调完都丌 ora-600等大师们组织 到20%了 的培训
    • DTCC2011 承担社会责任 DTCC2011 招个他们那样的大师一 个月得四五K吧? 王总多次提出用友软件要主劢承担社会责任 用友非常注重性能优化,丌断加大相关资源投入 欢迎大家加入用友软件,加入我们性能优化团队! 联系方式:liujb@ufida.com.cn 谢谢大家! 您发美元大家还得去兑换, 太麻烦了 还是我们来招吧
    • DTCC2011 DTCC2011