系统运行缓慢,某几个磁盘IO压力大?(技术交流)

问题背景描述:银行现有两台P780,两台机器做了rac,A节点的应用比较少,B节点的应用压力比较大,B节点应用压力是A节点的3倍左右。
1、现在B节点的系统出现性能问题,在工作日上午9点左右到下午6点左右出现系统卡慢现象。
通过iostat命令发现有三块磁盘的IO读写访问压力比较大,其他的都很正常,这三个磁盘(比如是hdisk10,hdisk11,hdisk12)被划分给一个LV,这个LV上的文件系统是一个存放应用的log的文件系统。
2、B节点上的应用是Tuxedo,且单个进程对应单个线程。通过收集B节点上的perfpmr给后线工程师分析后,后线给出的结论是应用有好多线程锁,同时对一个内存地址进行访问,而这个内存地址对应文件的正是这些应用的很多log文件。所有的log文件在内存中映射的内存地址都是相同的地址。
问题内容:
1、请问出现系统卡顿性能下降的情况,比如:运行一个topas命令很久才能输出结果;但是系统层面只是发现三个磁盘的IO访问压力大,别的指标都正常,请问系统层面还能做哪些方面的优化?
(首先,监控系统性能发现内存足够来高速缓存那些由正在运行进程使用的文件页面,换页空间使用也正常。
其次,存储方面不想做条带化,所以这点就不考虑了。
再者,也曾设想将现在压力大的盘除了center区域外的其他区域的数据分担到同一个VG的其他磁盘上,但是实际执行上有一定的难度,因为分担到其他盘的center区域上空闲的PPnumber都是不规律的,而且需要计算当前VG中目标盘center区域空间是否足够分担这三块盘的数据,所以不管数据量还是工作量都很大,另外手动迁移的话风险也很大,感觉效果也不会很明显,此方案不考虑了)
2、目前怀疑是应用侧开发使用的统一接口有问题,因为不同的服务输出Log在内存中对应的内存地址都相同。请问有什么方法能更清晰的定位应用程序中哪个函数的调用造成对内存访问不断的加线程锁?

71回答

kanter2008kanter2008  系统工程师 , 上海***
可以用排除法,确认你怀疑的事情。应用的LOG能否暂时停掉,停掉看现象。慢慢缩小范围。应用不能惯他们,啥都不干等结果的活儿 只有 俩腿一摊。。显示全部
可以用排除法,确认你怀疑的事情。

应用的LOG能否暂时停掉,停掉看现象。

慢慢缩小范围。

应用不能惯他们,啥都不干等结果的活儿 只有 俩腿一摊。。收起
 2015-03-13
浏览1394
kanter2008kanter2008  系统工程师 , 上海***
flysky0802赞同了此回答
鄙视某些码农。代码垃圾的要死,还舔个脸让别人查,不是说数据库问题就是系统慢。人家两手一摊,请给我找出来哪块代码有问题。最好是两腿一摊,5分钟准保定位。显示全部
鄙视某些码农。代码垃圾的要死,还舔个脸让别人查,不是说数据库问题就是系统慢。
人家两手一摊,请给我找出来哪块代码有问题。
最好是两腿一摊,5分钟准保定位。收起
 2015-03-13
浏览1469
ss33205687ss33205687  数据库管理员 , 西安
下面建议不知道对不对 :看情况系统内存和CPU不存在瓶颈,P780的性能应该是可以的;主要 日志问题在redo日志上,说明存储I/O还是可以满足的数据库需要的;现在判断redo的问题,大家都肯定会放在SSD盘上,但现在已经有存储了,所以只能正对现有系统,redo的切换频率先查一下,做AWR查看数据性...显示全部
下面建议不知道对不对 :看情况系统内存和CPU不存在瓶颈,P780的性能应该是可以的;主要 日志问题在redo日志上,说明存储I/O还是可以满足的数据库需要的;现在判断redo的问题,大家都肯定会放在SSD盘上,但现在已经有存储了,所以只能正对现有系统,redo的切换频率先查一下,做AWR查看数据性能同时坚持SQL找出应用有问题的SQL,增加redo数量和大小 ,经验值8个redo,先放在一个硬盘不考绿redo安全先,进行测试;既然怀疑应用了,就搞清应用类型和存数机制收起
 2015-03-13
浏览1443
北京宝汇德北京宝汇德  副总经理/副总裁 , 北京宝汇德技术服务有限公司
贴一下 topas   iostat显示全部
贴一下 topas   iostat收起
 2015-03-13
浏览1411
caichaloucaichalou  系统工程师 , 中国邮政储蓄银行
回复 2# kanter2008 :handshake显示全部
回复 2# kanter2008


:handshake收起
 2015-03-13
浏览1371
caichaloucaichalou  系统工程师 , 中国邮政储蓄银行
回复 4# 北京宝汇德     等封网结束了,再看看吧,不过先谢谢了显示全部
回复 4# 北京宝汇德


    等封网结束了,再看看吧,不过先谢谢了收起
 2015-03-13
浏览1407
caichaloucaichalou  系统工程师 , 中国邮政储蓄银行
回复 3# ss33205687     这个问题不是ORACLE日志引起的,这点还是能确定的。上面说的log输出都是应用交易时输出的log,所以还是考虑一下其他方向比较好。不过还是谢谢您的答复!显示全部
回复 3# ss33205687


    这个问题不是ORACLE日志引起的,这点还是能确定的。上面说的log输出都是应用交易时输出的log,所以还是考虑一下其他方向比较好。不过还是谢谢您的答复!收起
 2015-03-13
浏览1389
jiaxu2000jiaxu2000  系统工程师 , 沈阳医学院附属中心医院
分析oracle性能的问题不能离开AWR显示全部
分析oracle性能的问题不能离开AWR收起
 2015-03-13
浏览1407
caichaloucaichalou  系统工程师 , 中国邮政储蓄银行
回复 1# caichalou     现在的动作是等封网结束后分别收集A节点和B节点的perfpmr数据,提交后线工程师分析,看看A节点的分析结果是不是也会定位到内存中的那个文件指针地址。如果是的话,就很有可能可以说明是应用侧在开发的时候调用的统一接口导致的问题产生,然后让...显示全部
回复 1# caichalou


    现在的动作是等封网结束后分别收集A节点和B节点的perfpmr数据,提交后线工程师分析,看看A节点的分析结果是不是也会定位到内存中的那个文件指针地址。如果是的话,就很有可能可以说明是应用侧在开发的时候调用的统一接口导致的问题产生,然后让他们继续查自己接口封装的有没有问题就行了。收起
 2015-03-13
浏览1386
caichaloucaichalou  系统工程师 , 中国邮政储蓄银行
回复 8# jiaxu2000     谢谢您的答复!:handshake显示全部
回复 8# jiaxu2000


    谢谢您的答复!:handshake收起
 2015-03-13
浏览1274

提问者

caichalou系统工程师, 中国邮政储蓄银行

问题状态

  • 发布时间:2015-03-13
  • 关注会员:3 人
  • 问题浏览:23371
  • 最近回答:2015-12-22
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30