营销业务系统系统级优化方案.docx

营销业务系统系统级优化方案.docx

《营销业务系统系统级优化方案.docx》由会员分享，可在线阅读，更多相关《营销业务系统系统级优化方案.docx（25页珍藏版）》请在冰豆网上搜索。

营销业务系统系统级优化方案

1.项目简介

国网黑龙江电力公司营销业务系统随着业务量与数据量的增大，系统压力越来越大，系统可靠性与高效性降低，影响了对业务支持的质量.

为此，北京中电普华信息技术有限公司、国网黑龙江电力公司及该软件的开发公司东软公司一起合作，对营销业务系统通过先进、标准、可控的技术、工具和方法，监控系统的运行状况,评估系统现状，定位系统运行瓶颈，制定具体的优化实施及操作方案，并对优化实施结果进行评估。

实现优化系统性能、提升系统运行质量、挖掘系统潜力、创建系统建设良性循环模式的目的，并有助于提高维护人员的技术水平。

本项目分为四个阶段:

第一阶段为优化小组在哈尔滨市对国网黑龙江电力公司营销业务系统进行现场调研和性能分析，形成性能分析报告，并提出初步优化建议。

第二阶段，优化小组和开发厂家在国网公司相关部门的领导下,在哈尔滨市成立联合测试小组，对主要问题的优化方案进行验证。

第三阶段,优化小组在哈尔滨市实施现场优化实施工作，并在实施完成后进行性能评估.

第四阶段，开发厂商完成应用优化的代码调整工作,发布新的版本;与开发厂商协商，该部分工作在2013年12月完成。

2.项目定义

2.1.系统架构图

黑龙江省营销业务系统采用B/S架构，由用户登录浏览器进行操作,连接到中间件服务器，中间件服务器连接数据库底层,中间件服务器使用8台AIX服务器搭建的weblogic服务器，数据库为2台HP-unix服务器搭建的10gRAC数据库。

整体架构如以下图：

2.2.项目范围

本次优化的对象为国网黑龙江电力公司营销业务应用系统。

咨询的技术范围包括以下内容：

Ø对营销业务应用系统的运行情况进行分析

Ø建立一个性能基线，供调整前后对比

Ø根据分析结果,给出优化建议

Ø根据优化建议,做相应调整

2.3.项目目标

对营销业务应用系统的实际运行情况进行科学严谨的分析论证，提出相应的优化建议,各方配合组织实施。

优化建议包括系统级优化建议、表碎片整理、索引碎片整理、索引清理等几个方面。

2.4.成功要素

Ø公司领导和项目负责人的支持及帮助;

Ø普华内部充分的准备，数据库、操作系统、存储等各方面专家的共同努力;

Ø与应用开发维护专家积极有效的配合；

Ø整个调优团队积极高效的合作。

2.5.项目交付物

《国网黑龙江电力公司_营销业务_系统级优化方案》

《黑龙江电力公司营销系统索引清理方案》

《黑龙江电力公司营销系统索引碎片整理方案》

《黑龙江电力公司营销系统表碎片整理方案》

2.6.实施内容及风险防范措施

2.6.1.优化实施内容

根据前期进行的系统性能评估制订了优化实施方案，具体实施内容见后续章节。

2.6.2.风险防范措施

Ø确保数据库备份完整可用；

Ø所有操作和检查环节都使用事前完成并预演通过的脚本，避免临时修改脚本;

Ø每部分完成，通过检查确认无误，再进行其它部分，避免互相干扰。

Ø普华工程师和应用系统专家现场支持，及时处理突发问题.

2.7.优化策略概述

针对营销业务系统的持续跟踪,根据AWR详细信息，从操作系统参数，中间件等几个关键点的分析和测试,我们将从以下几个方面进行本次优化工作:

Ø数据库参数优化,db_keep_cache_size，可以将经常访问的小表放入keep池中,减少解析次数和等待时间.

Ø数据库发生大量死锁：

开发商进行逻辑调整，避免死锁发生。

Ø碎片整理：

查找碎片严重的表和索引，消除碎片，节约空间，让执行计划更准确,防止索引行迁移和行连接，避免过多的物理读.

Ø中间件优化:

由8台IBM小机搭建的集群,但是分发不平均，出现内存溢出现象,JDK优化，建议使用相同的内存大小的机器配置，配置相同的参数.

3.系统瓶颈总结

3.1.系统瓶颈简介

营销业务系统系统瓶颈:

集中在系统资源瓶颈。

Ø系统规模较大，达到了3T以上的数据量，每天5000的并发数目，传统的HP-UNIX双机已经出现主机瓶颈，top语句中请求已经大于cpu的数量，并且block数较request数量更多，系统内存使用量超过90%,空闲数量不足5%，系统每天24小时处于繁忙状态，大量的等待进程.

Ø中间件服务器配置不相同，没有配置集群管理,分发不平均，负载不均衡.

进度状况：

针对营销系统，采购IBMp750双机已经纳入今年的采购计划，明年采购完成会更换操作系统,解决系统瓶颈

4.数据库缺陷消除

4.1.死锁现象

优化理由：

通过对数据库日志分析，发现数据库日志出现大量的GESDeadlock死锁，如下所示：

MonOct2916：

30：

39GMT+08:

122013GlobalEnqueueServicesDeadlockdetected.Moreinfoinfile

/oracle/admin/pmdb/bdump/pmdb1_lmd1_5789710.trc.

优化依据：

通过对日志的分析，截取了近期的死锁类型为TX的5类排他锁。

最近一次：

GlobalWait—For—Graph（WFG）atddTS［0。

5de]:

BLOCKED700001389ac88c05wq2cvtopsx1[0x1c001a］[0x2e3197］,[TX］［1021-021C-000000B6]0

BLOCKER700001389ac87705wq1cvtopsx28［0x1c001a]［0x2e3197］,［TX]［101F—01FD—0000026D]0

BLOCKED70000138fb0d4705wq2cvtopsx1［0x14001a]［0x151d3c8］,［TX］[101F-01FD—0000026D］0

BLOCKER70000138a98e4f05wq2cvtopsx1[0x14001a]［0x151d3c8]，［TX]［2029-0295-00000AC1]1

BLOCKED70000138a98e4f05wq2cvtopsx1[0x14001a]［0x151d3c8］,[TX］［2029-0295—00000AC1]1

BLOCKER70000138a98e3a05wq1cvtopsx28［0x14001a］［0x151d3c8]，［TX］[2029-0297—000019E5］1

BLOCKED70000138ef031285wq2cvtopsx1［0x1c001a］［0x2e3197］,[TX][2029-0297—000019E5]1

BLOCKER700001389ac88c05wq2cvtopsx1［0x1c001a][0x2e3197]，[TX][1021—021C—000000B6]0

触发死锁的SQL语句有：

sid3065:

70000138db4c318UPDATEWF_ASSIGNMENTSETREAD_MARK=:

1WHEREACTIVITY_ID=：

2ANDPROCESS_ID=:

3ANDUSER_ID=:

4

sid:

2423：

70000138be9ce18UPDATEWF_ASSIGNMENTSETREAD_MARK=：

1WHEREACTIVITY_ID=:

2ANDPROCESS_ID=:

3ANDUSER_ID=：

4

sid：

2290：

70000138aaa76c8UPDATEWF_ASSIGNMENTSETREAD_MARK=:

1WHEREACTIVITY_ID=:

2ANDPROCESS_ID=：

3ANDUSER_ID=：

4

sid：

2874:

700001389ac88c0UPDATEWF_ASSIGNMENTSETREAD_MARK=:

1WHEREACTIVITY_ID=:

2ANDPROCESS_ID=：

3ANDUSER_ID=：

4

sid:

3114:

700001389ac8770UPDATEWF_ASSIGNMENTSETREAD_MARK=:

1WHEREACTIVITY_ID=：

2ANDPROCESS_ID=:

3ANDUSER_ID=:

4

sid：

3114:

70000138abc4038updatewf_assignmentsetRESOURCE_TYPE=’HUMAN’,STATUS_ID=’TASK_DELEGATED',READ_MARK=’0'whereactivity_id=’2013027760755211’andUSER_ID!

='29011918’andRESOURCE_TYPE！

=’ROLE’

sid：

2377：

7000013881e6d68UPDATEWF_ASSIGNMENTSETREAD_MARK=：

1WHEREACTIVITY_ID=：

2ANDPROCESS_ID=：

3ANDUSER_ID=:

4

优化方法：

建议开发商对该业务逻辑进行调整,避免死锁的发生.

4.2.ORA-7445现象

优化理由：

营销系统数据库每天都会在日志中生成以下报错：

ORA—07445：

出现异常错误:

核心转储[kksxsccmp+0428]［SIGSEGV］[Addressnotmappedtoobject］[0xE86300987C7B03DA］[]［］

MonJul2916：

04:

56GMT+08:

002013Tracedumpingisperformingid=[cdmp_20130729160456］

优化依据：

从数据库层面来看,目前该报错对业务系统没有造成影响。

根据我们以往的类似的日志判断该报错一般由无效的数据库对象（如包，过程）在应用程序中被调用所造成。

从目前生成的trace来看,只发现了一些递归的系统SQL以及该问题是由weblogic创建的session所触发，没有看到其他有价值的信息。

优化方法：

我们将持续对问题的跟踪,并建议业务系统开发商对现有的无效对象进行编译和清理。

5.中间件优化

5.1.中间件基本配置

机器配置:

序号

硬件型号

安装软件

IP

用途说明

1

AIX5

AIX5.3，8CPU

，8G内存

，Weblogic9.2.2

，SUN—1。

5.0_06

Weblogic应用服务器

2

AIX5

AIX5。

3,8CPU

，8G内存

，Weblogic9.2。

2

，SUN—1.5.0_06

Weblogic应用服务器

3

AIX5

AIX5。

3，8CPU

，8G内存

，Weblogic9.2。

2

，SUN—1.5.0_06

Weblogic应用服务器

4

AIX5

AIX5.3，8CPU

，8G内存

，Weblogic9。

2.2

，SUN-1。

5。

0_06

Weblogic应用服务器

5

AIX5

AIX5.3，8CPU

，8G内存

，Weblogic9.2.2

，SUN-1.5。

0_06

Weblogic应用服务器

6

AIX5

AIX5.3，8CPU

，8G内存

，Weblogic9。

2.2

SUN-1.5。

0_06

Weblogic应用服务器

7

AIX5

AIX5。

3,8CPU

，8G内存

，Weblogic9。

2.2

SUN-1。

5。

0_06

Weblogic应用服务器

8

AIX5

AIX5.3,8CPU

，8G内存

，Weblogic9。

2。

2

，SUN-1。

5。

0_06

Weblogic应用服务器

Weblogic优化设置：

服务器类型

系统软件

参数类型

参数值

备注

数据库服务器

Oracle

最大连接数

500

默认值150

应用服务器

Weblogic

数据库连接池

初始连接数:

20

最大连接数：

50

Weblogic

数据库连接池

积压数

登录超时时间

步长：

5

默认:

1

300

默认:

15

5000mS

默认：

1

JDK内存设置

最小内存：

2048M

采用默认值

登录超时时间

最大内存：

2048M

采用默认值

JDK内存设置

最小内存：

2048M

默认为256M～512M

最大内存：

2048M

采用默认的连接数，如果业务量突然加大则会造成大量的用户等待，同时JDK采用默认的内存设置不利于充分的利用资源.

5.2.JDK优化

优化理由和依据：

采用sun的JDK没有采用经过优化的jrocket,不利于从硬件上优化硬件资源

优化方法：

在JDK1。

4以后，BEAJROCKIT在CLASSLOAD速度进行了明显的优化,其中同一方法在第一次编译后，就驻留在内存里，而IBMJDK同一方法编译后，只有当调用的时候才进入到内存中，JROCKIT大大的加快了编译的速度,在其他方面JROCKIT的反应性能也超过了传统的IBMJDK在对于营销这样的生产负荷繁重的系统，使用JROCKITJDK可以大大降低程序在中间件层运行的速度。

5.3.堆栈优化

优化理由和依据：

在生产过程中尤其是业务高峰期，中间件服务器经常报内存溢出错误.如下

优化方法：

JVM的栈堆优化，建议将现有的数值1610612736扩大1.5倍,这样可以增加程序的吞吐量，避免内存溢出等错误的发生。

5.4.负载均衡优化

优化理由和依据：

1。

连接数过小

2.JVM参数不一致

3。

每个集群内存数不一样，造成相同的配置配置不同的机器或者不同的配置配置相同的机器，导致程序分发不平均，负载不均衡。

4.整个中间件系统由8台adminserver和8台managedsever组成，每台物理机器上都存在一个主管和一个受管服务器.未配置集群管理，无法进行负载均衡。

性能，安全都不能得到最好的效果。

优化方案:

1。

使用相应的机器配置。

2.配置相同的内存大小.

6.系统及数据库优化

6.1.数据库参数优化

6.1.1.db_keep_cache_size调整

对于数据库服务器来讲，CPU、内存资源是我们需要重点关注并进行有效控制的资源，黑龙江公司数据库服务器目前CPU负载不大，但内存消耗也不是很大。

但通过将频繁访问的表和索引放入KEEP池,可以确保这些对象不会被交换出缓冲池，从而减少了物理读，提升了性能，所以建议：

对db_keep_cache_size参数进行适当调整。

优化前db_keep_cache_size1504M，而SGA64G,为了可以keep更多的表和索引结合BufferPoolAdvisory,建议将db_keep_cache_size增加到5G。

6.2.数据库对象优化

6.2.1.KEEP池调整

优化理由:

ORACLE对SGA中的DBBuffer做了细分，分为普通池、KEEP池和回收池。

将频繁访问的表和索引放入KEEP池，可以确保这些对象不会被交换出缓冲池,从而减少了物理读，提升了性能。

因此，充分利用ORACLE的这一机制，是优化工作的一个重要内容。

当然，内存是有限的，不能把所有的表和索引都放入KEEP池中,因此我们需要精心挑选候选对象，主要是从热点表和索引着手，综合考虑对象的大小,把尽量多的中小型表和索引纳入其中。

优化方案:

通过分析表的统计信息找访问频繁表和索引

Selectdecode（pd.bp_id，1,’KEEP’，2，'RECYCLE’，3，'DEFAULT'，4,

'2KSUBCACHE’,5，'4KSUBCACHE’,6,’8KSUBCACHE’，7,

’16KSUBCACHE'，8，’32KSUBCACHE'，’UNKNOWN'）subcache,

bh。

object_nameobject_name，bh。

blocks,tch

fromx$kcbwdsds，x$kcbwbpdpd，

（selectset_ds,

o.nameobject_name,count（＊）BLOCKS,sum（tch）tch

fromsys.obj$o，sys。

x＄bhx

whereo。

dataobj#=x。

obj

andx。

state!

=0ando.owner#！

=0

groupbyset_ds，o.name）bh

whereds.set_id>=pd。

bp_lo_sid

andds.set_id<=pd.bp_hi_sid

andpd。

bp_size！

=0

andds。

addr=bh.set_ds

ANDTCH〉2000

orderbysubcache，object_name；

部分结果如下：

对象名

对象大小Mb

表被调用的次数

K_S_BATCH__S_APP_S_B_S_APP

224

6843336

S_APP

238

5618453

S_PS_CHG_SCHEME

248

553209

E_RS_PQ

264

2552777

R_PLAN

296

10182

操作方法：

AlterindexEPM_HLJ.K_S_BATCH__S_APP_S_B_S_APPstorage（buffer_poolkeep）;

AltertableEPM_HLJ.S_APPstorage（buffer_poolkeep）；

AltertableEPM_HLJ.S_PS_CHG_SCHEMEstorage（buffer_poolkeep）；

AltertableEPM_HLJ。

E_RS_PQstorage（buffer_poolkeep）;

AltertableEPM_HLJ.R_PLANstorage（buffer_poolkeep）;

详细信息参见

6.2.2.无用索引清理

优化理由:

创建合适的索引,对提升数据库性能非常重要。

但无用的索引不但占有大量的存储空间，而且还占有CPU、IO的系统资源，所以必须对无用索引进行清理。

黑龙江电力公司营销系统已经上线多年系统，通过对营销系统索引状况进行分析，发现由于大量的不使用的索引,这些索引占有大量存储空间，增加索引维护成本，将会降低数据库性能,所以需要清理.

通过对营销系统数据库索引监控，黑龙江电力公司营销系统索引共有3147条，索引数据量共1045688。

56MB,占数据总量的61.41％，共有754条索引未使用，未使用索引数据量共223199.63MB，占索引总量的21.34%，占数据库总量的11.61%,预计清除无用索引可以节约220G的空间,并且能很大程度提高数据库性能。

优化方案:

索引具体清理过程详见《黑龙江公司营销系统索引清理方案》.

6.2.3.索引层次过高

优化理由：

索引层次过高导致通过索引进行检索的时候会产生大量的IO，严重影响系统性能。

索引层次过高可能是由于所以出现倾斜。

一般处理方法：

找到索引超过4层的索引，进行重建。

对于数据量巨大的表考虑对索引进行分区处理.

select＊fromdba_indexeswhereblevel〉=4;

通过对营销系统分析，未发现索引层次过高的表。

6.2.4.索引碎片清理

优化理由：

营销系统已经上线多年,大量的数据更新和删除操作均会给索引带来碎片问题，导致索引过大，碎片较多，通过在线重建索引可以提高索引访问效率，减少系统开销。

优化方案:

下表列出了部分索引碎片的例子，详细的索引碎片优化方案请参考《黑龙江公司营销系统索引碎片整理方案》。

索引名

索引大小（MB）

释放空间（MB）

IND_ARC_E_KWH_AMT_PRCAMTID

6433

744

IND_ARC_E_PLAMT_PLCOD_PRCTSCOD

19113

3389

IND_ARC_E_PL_AMT_PRCAMTID

15730

3779

PK_ARC_E_PL_AMT

15008

3562

IND_ARC_E_PL_AMT_ORG_YM

14162

3391

FK_A_ACCT_E_DTL_VOUCH_A_VOUCHE

15082

4797

FK_A_RCVBL__DTL_VOUCH_A_VOUCHE

33306

10602

IND_A_RCVBL_ENTRY_OM

28097

9530

PK_A_ACCT_ENTRY

9598

1530

PK_A_RCVBL_PL_FLOW

11164

1913

PK_A_RCVED_PL_FLOW

8362

2609

IND_A_ACCT_ENTRY_ACCT_ID

15448

3500

IND_A_ACCT_ENTRY_CONSNO

7294

1731

IND_A_PAY_FLOW_IDEMPTYPE

6082

1502

IND_A_RCVBL_ENTRY_ACCTID

30826

6581

IND_A_RCVBL_ENTRY_CONSNO

15160

3994

IND_A_RCVBL_PL_FLOW_ACCT_NO

14061

4567

IND_A_RCVBL_PL_FLOW_RCVBLAMTID

11219

2482

IND_A_RCVED_PL_FLOW_ACCT_NO

9756

3343

IND_A_RCVED_PL_FLOW_AMT_ID

8634

2730

IND_PUB_E_PQ_AMT_CALC_ID

6304

970

PK_WF_ASSIGNMENT_END

6075

730

6.2.5.表碎片清理

优化理由：

由于部分表的数据经常进行插入删除，并且长期未进行整理，因此存在较为严重的碎片问题。

从而导致了少量的数据占用了大量的数据库空间。

通过表碎片整理可以提高系统的总体性能。

对于表碎片整理有两种方法：

1.表整理的方法是在线altertable<表名〉move，不建议move时进行索引重建,要在move后可以并行进行索引重建。

2.在有条件的情况下可以停应用后进行整理，采用RENAME后重建表的方式，这种方式风险最小。

基于现场环境限制，我采用第一种方法进行表碎片清理。

通过分析表的统计信息找到碎片率最高的表，然后进行move操作，来消除碎片.

优化方案:

以下列出分析得到碎片率靠前的表，详细信息请参考《黑龙江公司营销系统表碎片整理方案》.

OWNER

TABLE_NAME

total

used

fragment_per

frag_sizeMb

1

EPM_HLJ

A_RCVBL_ENTRY

71776

38822

46％

32954

2

EPM_HLJ

PUB_E_PQ_AMT

59048

33619

43％

25429

3

EPM_HLJ

A_ACCT_ENTRY

43945

20885

52％

23060

4

EPM_HLJ

A_RCVED_PL_FLOW

16282

6953

57%

9329

5

EPM_HLJ

PUB_A_CARD_POWER_BUY