要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
分享到
产品运维中的性能优化
 

作者:tianlincao ,发布于:2012-12-26,来源:CSDN

 

一、问题的提出

随着系统业务数据量的不断增长, 使用用户的不断增加, 项目组越来越频繁收到用户特别是中研用户反馈的性能问题, 主要是以下几个方面的问题:

1. 系统使用高峰期比如周一和月初, 用户反馈系统登陆不了, 菜单响应和操作缓慢等问题;

2. 客户查询功能响应缓慢, 一个4000条数据的查询时间超过N分钟;

3. 客户增量保存功能操作失败,有些时候增量保存的线程跑了1个小时还没成功保存,结果是用户数据丢失(后台同步处理);

4. 客户操作后死机

5. 管理员反馈报表查询响应不了甚至报系统错误

经过对系统的监测和分析, 监测到的问题如下:

1. 数据库连接占满, 事务等待超时或死锁

2. 数据库服务器停止, 事务日志占满, 报磁盘空间不足的错误

3. 后台日志显示数据库语句堆, 排序堆不足

4. 后台日志显示缓冲池中无页面可用

5. 通过连续监测发现每周一上午9:30-10:30这个时间段数据库CPU使用率接近100%高居不下

二、解决思路

系统的核心业务数据是百万级别的数据, 以及千万级别的日志数据:

既是一个OLTP系统, 又是一个OLAP系统; 任务流程处理这块都是一些大事务和并发多的事务, 而任务分析这块是实时进行大数据量超复杂的统计运算; 这些地方就是系统的性能瓶颈;

鉴于此, 我们从SQL语句, 应用程序逻辑, 数据库, 数据归档, 部署方式等多个层面进行系统的性能优化, 优化的重点是减少事务并发, 保证稀有资源的合理利用;

2.1. SQL语句优化

a) 系统存在很多树结构数据, 比如项目树, WBS, 对这些数据进行查询的SQL进行优化, 分析发现很多递归SQL在递归层次深,数据量大的情况下, 性能问题突出, 我们采取的办法是:

尽量使用视图;

将查询条件从SQL语句的最外层移到内层子查询, 减少数据查询量;

报表SQL允许脏读, 以防大面积的关键数据表行锁升级为表锁;

b) 系统有很多一对多特别是多对多的表关联查询, 比如任务表和日志填报表; 分析发现很多地方就用一个超大的SQL查询任务和日志数据, 这样查询的结果冗余量大,我们采取的办法是:

拆分成多个SQL进行查询;

c) 很多SQL中包含in函数, 而且in的子查询语句的结果集不确定, 可能上千上万, 这种SQL导致数据库后台报语句堆不足的错误, 我们采取的优化办法是:

用关联查询替代in函数;

用or语句替代in函数;

d)整理出大数据量查询的SQL语句, 找出关联查询的条件, 根据索引原则, 增加数据库索引;

e) 有不少报表统计SQL语句直接处理的大数据量的复杂运算, 导致占用大量的数据库资源,我们采取的优化办法是:

SQL语句用来查询数据, 而运算统计的部分交给应用服务器处理;

采用静态报表, 晚上统计出数据, 白天就可以查询统计后的结果数据;

f) 分析发现有些SQL语句类似 ”select * … ” , 这些地方全部将*号替换成具体的列;

还有些SQL返回的结果集数量是可知的,这些地方使用FETCH FIRST n ROWS ONLY参数

2.2.应用程序逻辑优化

a) 一个最大的问题就是循环里面取数据库连接, 这种情况很普遍, 所有地方全部进行了改正;

还有些功能点需要多次存取数据, 考虑使用一个数据库连接;

取连接的语句在需要的时候执行, 而不是在方法一开始就执行;

b) 另一个问题是程序中, 有些数据库连接释放的部分代码在try子句里面, 有些在catch子句里面,现在全部改为在finally中执行连接释放的操作, 这也是一个普遍的问题;

c) 程序忽略了异常处理或者对异常处理不够正确, 特别是一些无法测试的异常, 一旦发生这里异常可能导致事务不一致, 重复任务数据的BUG就是这样产生的,我们采取的处理办法是:

这些地方都进行了异常捕捉处理;

发生异常的地方都进行了事务的回滚;

d) 另一个是事务一致性和并发性能的取舍问题, 在关键功能上进行了利弊权衡;

e) 有些大事务功能点, 比如客户端下达, 任务反馈日志填报等程序逻辑上,对数据表的更新顺序不一致,这些地方都调整成一致; 以防并发出现互相锁等待的问题;

f) 及时的释放大对象内存, 比如客户端项目列表,WBS列表等;

g) 有些大事务处理的程序导致DB后台日志满, 磁盘空间不足的情况, 我们除了及时的清理备份事务日志, 还对这些大事务程序进行优化, 拆分成多个小事务进行处理;

h) 递归查询的地方采取了数据校验, 防止递归的父和子的ID一致, 死循环查询, 导致最终数据库临时表空间占满, 内存溢出等问题;

2.3.数据库调优

a) 定制一个runstats计划, 将需要进行runstats的数据进行分类, 哪些是按月,哪些是按周统计 runstats实用程序用于更新系统目录表中的统计信息,以帮助查询优化过程

b) 对一些排序, 分组的字段或者关联查询的字段比如名称, 日期等, 根据索引原则, 建立了索引;

c) 定期进行数据库日志归档和清理;

d) 利用性能测试工具和监控工具, 进行了数据库的参数调优;

主要参数是缓冲池大小,locklist大小, 排序堆阀值和大小, 查询堆语句堆大小等;

LockTimeout的时间需要指定, 但不能太大;

使用snapshot监视缓冲池, 调整bufferpool参数, 保证缓冲池命中率到95%+;

使用snapshot跟踪排序活动, 并发测试大型排序的报表功能, 调整sortheap参数, 同时调整sheapthres参数;。

2.4.数据归档

以项目为单位, 以计划任务数据为依据, 统计出一定时间内没有活动的项目; 经过用户的确认, 将这些项目进行归档处理;

a) 第一步, 按照项目导出这些数据到本地, 包括项目, 计划任务, 日志, 项目成员等数据

b) 第二步, 删除生产环境上的这些项目数据;

c) 第三步, 这些项目数据转移到备份数据库, 用户可以从备份数据库上查询到历史数据

数据归档的时候总结出了一些问题

a) 删除语句和导入语句有先后顺序的;

b) 没有主键的表,导入的时候不能用insert_update操作;

确认数据删除没错的话,可直接用insert取代insert_update操作;

c) 导出的数据量比较大的情况, 建议分段导出

d) 执行export和import命令需要在装有DB2 Server的环境中执行,否则会报程序包未找到的错误;

e) 考虑到删除数据量的问题,采用单个项目单个项目数据迁移的方式;

f) 跑脚本的时候,需要停止其他所有应用,否则很容易引起事务等待;

g) 回滚数据库日志的时候比较消耗内存, 回滚前重启机器

2.5.部署方式

将数据库服务器拆分为执行数据库和报表数据库:

执行数据库主要进行OLTP操作,报表服务器用作各类报表的查询,执行OLAP操作

报表服务器的数据定期从执行数据库中同步;

具体方案有2种:

a) 使用同一个应用服务器

在已有的AppServer上加上报表数据库的数据源,报表查询都调用报表数据源即可

b) 使用2个应用服务器独立部署

用户通过执行服务器登陆界面登陆,当查询报表时,自动跳转到报表服务器

报表切换方案

a) 修改 执行AppServer应用程序的报表管理菜单的链接,

让其重定向到 报表AppServer应用上

b)修改 报表AppServer应用程序,增加redirect.jsp文件。

主要是在报表AppServer上自动重建session,包括:

界面语言,是否统一登陆,用户信息,用户类型,菜单列表,当前菜单;

重建完session后,自动定位到报表管理菜单

c)配置 报表AppServer菜单

禁用报表App除了报表管理相关菜单以外的所有菜单,已防止用户误操作;

比如:用户切换到报表管理菜单后登陆客户端操作,会发生没有权限问题;

d) 报表AppServer一些不相关的业务线程考虑关闭。

报表AppServer的组织切换跳转考虑不跳转

数据同步方案

a) DB2远程SQL复制

参考以上部署图,DB2的SQL复制主要有2个程序,一个是Capture程序,通过数据库日志从源数据库中获取变化,并把数据放到一个中间表中。

另一个是Apply程序,在设定的时间间隔将中间表的数据同步到目标数据库,从而到达DB2数据复制的目的。

(步骤略)

b) ETL工具同步

报表需要同步的表和Mapping方式如下, ETL工具配置步骤略;

总结:

目前系统有10几个节点在用, 这些节点都是独立部署, 独立的应用服务器和数据库服务器,后续用户希望能进行跨体系,跨部门的项目管理, 这就要求我们的系统需要进行多节点的合并处理, 业务数据也需要合并, 这种数据几何级的增长, 必然会对系统有更高的要求, 所以后续工作还需要考虑在集群, 磁盘阵列, OLTP&OLAP分离, 表分区, 树型报表分页, 数据同步等等多个方面进行系统的部署调整


 
分享到
 
 


正视研发管理才是高水平竞争
需求是如何变成产品原型的
产品经理能力模型解说—把控
产品经理的正确定位
谁是合格的产品经理?
产品管理与产品营销的区别
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行

相关咨询服务
基于CMMI2-3过程改进咨询
软件工程体系与平台构建
软件开发过程


某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号