保险投保系统常规压力（并发）测试，响应时间翻倍

wengtf

保险投保系统常规压力（并发）测试，响应时间翻倍，CPU压力确始终在50%

awr 和系统监控记录见附件。

godspeed

基本上都在耗CPU啊，你服务器有没有开着超线程？
如果不能优化语句减少CPU消耗的话，貌似只能提升CPU主频，增加CPU数量来提升性能了。
你说的“响应时间翻倍”我不是很理解，响应时间相对什么翻倍了？

godspeed

从AWR里面看有24个处理器，应该是两颗6核心处理器，12个核心，24个线程，所以你应该是开了超线程。如果关闭超线程，估计CPU就是100%了。
CPU应该是在内存中倒腾数据呢，如果你的内存带宽跟不上，也会有问题，对于你这种机器，每颗CPU配备4条内存带宽才能达到理想状态，不知道你的实际情况是什么样子的，32GB内存是4GB*8呢？还是8GB*4？

Maclean Liu(刘相兵

Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
CPU time                  12,926                  99.6         
log file sync         207,381         323         2         2.5        Commit
log file parallel write         193,160         222         1         1.7        System I/O
SQL*Net more data from client         345,720         46         0         .4        Network
SQL*Net more data to client         211,972         5         0         .0        Network


top 5 主要是cpu time ， cpu敏感的系统


Statistic Name        Time (s)        % of DB Time
DB CPU        12,926.30        99.58
sql execute elapsed time        12,305.42        94.79
parse time elapsed        23.64        0.18
% Non-Parse CPU:         99.85



解析花的 cpu很少


所以不是解析cpu敏感


PU Time (s)        Elapsed Time (s)        Executions        CPU per Exec (s)        % Total        % Total DB Time         SQL Id        SQL Module        SQL Text
3,957        3,874        18,345        0.22        30.61        29.84        2ax73suj5nyka         JDBC Thin Client        SELECT SUM(PL.GROSSPREMIUM) FR...
2,533        2,480        24,573        0.10        19.60        19.11        3r1uzmbwxhw3p         JDBC Thin Client        select insureinfo0_.POLICYSERI...
1,849        1,816        73,018        0.03        14.31        13.99        6hhyacc5t6kmk         JDBC Thin Client        select this_.SERIALNO as SERIA...
1,244        1,218        24,368        0.05        9.62        9.38        3rm6gtwn27uq4         JDBC Thin Client        select beneficiar0_.PARENTSERI...
765        754        122,799        0.01        5.92        5.81        151jmjtarcvs8         JDBC Thin Client        select this_.SERIALNO as SERIA...


SQL ordered by Gets
Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
Total Buffer Gets: 2,463,735,633
Captured SQL account for 88.8% of Total
Buffer Gets        Executions        Gets per Exec        %Total        CPU Time (s)        Elapsed Time (s)         SQL Id        SQL Module        SQL Text
1,156,601,314        18,345        63,047.22        46.95        3956.90        3873.94        2ax73suj5nyka         JDBC Thin Client        SELECT SUM(PL.GROSSPREMIUM) FR...
395,316,269        24,573        16,087.42        16.05        2533.44        2480.47        3r1uzmbwxhw3p         JDBC Thin Client        select insureinfo0_.POLICYSERI...
325,621,329        73,018        4,459.47        13.22        1849.32        1816.29        6hhyacc5t6kmk         JDBC Thin Client        select this_.SERIALNO as SERIA...



cpu time高的语句可以和 buffer gets高的语句对应， 说明是 逻辑读造成的 cpu



SELECT SUM(PL.GROSSPREMIUM)
  FROM INSURANCEPOLICY PL
INNER JOIN PARTYROLEINPOLICY APPLICANT
    ON PL.SERIALNO = APPLICANT.POLICYSERIALNO
   AND APPLICANT.ROLEKIND = 'InsuranceApplicant'
WHERE APPLICANT.FULLNAME = :1
   AND APPLICANT.GENDER = :2
   AND APPLICANT.IDTYPE = :3
   AND APPLICANT.IDNUMBER = :4
   AND APPLICANT.BIRTHDATE = :5
   AND PL.POLICYSTATUS = :6
   AND PL.SUBMISSIONDATE = :7



这个语句执行较多 18,345 次， 每次 63,047.22  ， 感觉优化潜力较大

Maclean Liu(刘相兵

如果你要对比 前后， 则给出 前后2个快照的awrddrpt 报告

godspeed

另外，VM_IN_BYTES和VM_OUT_BYTES也有一些，我很奇怪你这个系统上是不是还跑了别的服务在消耗内存？

wengtf

@godspeed,该dagtabase server 没有其他service 在跑。

wengtf

Maclean Liu(刘相兵 发表于 2013-8-7 12:43
如果你要对比 前后， 则给出 前后2个快照的awrddrpt 报告

好，这个我跟用户要一下。