博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
一次Linux、Tomcat和Oracle数据库优化过程
阅读量:5879 次
发布时间:2019-06-19

本文共 2296 字,大约阅读时间需要 7 分钟。

因受公司保密协定,相关系统、中间件名称由系统A、系统B、TomcatA、TomcatB、ORACLE-1、ORACLE-2所代替。涉及到的地区、实际业务均为代号,请知晓

  • 系统A的初始需求:

系统A的使用用户,在系统A上进行导出功能的时候,经常会引发系统A宕机,经过简单评估,判定系统硬件不足,需要扩容并迁移到云端用X86机器替代原有小型机。

接到这个case的时候,我先登上服务器上看了一下,是一台windows server 2003服务器。

里面跑了一个Tomcat应用程序,就是这个应用程序经常内存溢出。

看了一下服务器的位数,为64位,该服务器物理内存为16G,实际使用6.87G,剩余将近10g空闲物理内存未使用,查询系统注册表,发现Tomcat实际启动内存为1G,明显不正常。。

于是向用户申请重启,尝试增加Tomcat实际启动内存的操作。

实际操作后添加内存失败,原因为目前部署的tomcat版本为32位,只能识别1g内存,超过1g内存在java虚拟机内就会报错。配置高内存后,无法启动tomcat服务。

下图为用命令添加内存数测试java虚拟机是否可以正常运行,可以看到2048m的时候是报错的。

图片描述

实际用DOS下查看tomcat的版本信息:为x86 32位版本。

图片描述

看到这里我就有点崩溃了。。64位的机器,用32位的中间件,内存不溢出都有鬼。。。

  • 系统A的上云之路

系统A的上云之路可以说是一波三折,中间经历各种各样的问题,历时近小1个半月,终于迁移成功了。本以为这下终于可以牛B了,结果噩梦刚刚开始。

地区A用户用系统A,是为了监控他们想要的业务的,但当实际业务发生时,系统A超过了它的承载能力,并且当时上云的时候,x86机器硬件评估也没做好(不过事后想想,也多亏了这块,得到了优化这个系统,不然问题一直就被高配置给掩盖了。)

具体问题场景

受实际业务影响,系统A与系统B之间的交互超过了系统A的最大承载能力,系统A先出问题,然后导致系统B跟随出问题,两个系统瞬间宕机。

看这个Case的时候,历时很久,也经历了好几个步骤才从一团杂乱无章的现象中缕清头绪,整理如下:

系统A报错:

java.sql.SQLException: Couldn't perform the operation setAutoCommit: You can't perform any operations on this connection. It has been automatically closed by Proxool for some reason (see logs).

当时上网查询了一些相关文档,找到一篇:

参考文档:

文档中明确指出:

simultaneousBuildThrottle参数设置过小会引发这个问题

图片描述

知道问题点在这了,于是调整了一下应用程序内的配置文件:

调整simultaneousBuildThrottle参数为1000,增大数据池并发处理量。

  • 系统A与系统B之间的无情纠纷

调整好了上个case不到半个月,又接到新case,用户反映系统A非常卡,几乎不能用。

刚开始我还有点不相信,结果自己上去操作了一下,点一下操作要等5分钟左右,并且之前说过了,系统A有问题会连带系统B也跟着有问题,这样两个系统的维护负责人的矛盾就开始慢慢激发了。。

研发也在跟进这方面的问题,并且做了相当一部分工作,把TOMCAT层面的连接池、Session数得到了控制,至少发生卡慢问题的时候,不会回收不了了,只是效率的问题。

到这里开始想到了之前系统A上云的时候,数据库服务器ORACLE-1的系统idle%值很低,当时判定为x86的性能不够,还特意申请了高配服务器。

但是作为一名技术人员,对系统A的了解来看,现在的配置给系统A用也应该绰绰有余。

于是开始着手查看AWR报告,分析TOP SQL

分析了一晚上,真发现了3个会导致CPU处理异常高的SQL语句。

单独执行它们,一个都在1秒钟左右,看似不会对CPU造成影响,但是关联到业务,可能就不行了,这些SQL执行的频率相当之高,千里之堤溃于蚁穴,看来这些SQL的优化势在必行。

继续分析SQL语句,它们的共性是,查询的时候都用了like关键字。

再查看对应的表结构,发现like查询的字段正好是索引列。
再看一眼like里写的东西,到数据库表里一看,like里写的东西本身就能够确定唯一性。。不知道为什么用like。。。谁能告诉我,怎么想的??对于这个实在不能忍受。。

优化这部分,实际没用多长时间,找研发同事修改了一上午就搞定了。

结果观察效果,一下数据库服务器的idle%上升了50%,之前是可怜的0%。

优化到50%,很显然不是咱们的最终目的,最终目的是让系统A变成正常的系统,cpu占用率在20%以下。

于是继续在TOP SQL中找,发现一张表的数据量级已经到了900W,并且没有索引。

真的好醉。。。who can help me?

900w的表,delete基本是不用想了,问了下相关负责同事,直接执行truncate操作。

执行完毕后,cpu利用率一下跌落到7%!! 系统IDLE值上升到了95%!!

附一张对比图,数据从AWR报告中取的。

现在再也没有用户说卡慢了,因为idle值上去了,哈哈。

图片描述

  • 后续系统A还有没有可优化空间

答案是肯定有,经过观察,系统A有好几个大表,并没有分区,这块肯定对查询有影响。

并且几个业务功能的逻辑也有可优化空间,但是因为上面的优化做完了,这块就可以正常排期,没有那么紧急了。

转载地址:http://ljcix.baihongyu.com/

你可能感兴趣的文章
学员会诊之03:你那惨不忍睹的三层架构
查看>>
vue-04-组件
查看>>
Golang协程与通道整理
查看>>
解决win7远程桌面连接时发生身份验证错误的方法
查看>>
C/C++ 多线程机制
查看>>
js - object.assign 以及浅、深拷贝
查看>>
python mysql Connect Pool mysql连接池 (201
查看>>
Boost在vs2010下的配置
查看>>
一起谈.NET技术,ASP.NET伪静态的实现及伪静态的意义
查看>>
20款绝佳的HTML5应用程序示例
查看>>
string::c_str()、string::c_data()及string与char *的正确转换
查看>>
11G数据的hive初测试
查看>>
如何使用Core Text计算一段文本绘制在屏幕上之后的高度
查看>>
==和equals区别
查看>>
2010技术应用计划
查看>>
XML 节点类型
查看>>
驯服 Tiger: 并发集合 超越 Map、Collection、List 和 Set
查看>>
Winform开发框架之权限管理系统改进的经验总结(3)-系统登录黑白名单的实现...
查看>>
Template Method Design Pattern in Java
查看>>
MVC输出字符串常用四个方式
查看>>