标签：style blog http os java io ar 文件 数据
今天现场实施反馈系统整体慢，已经接到用户非常多的投诉，要求现场发回weblogic日志和Oracle 数据库报告。简要说下系统的架构：典型的B/S三层架构，开发语言是java，中间件用的是weblogic，数据库用的是Oracle，用的都是pc server。
1.分析weblogic日志和数据库报告。weblogic日志里面没有stuck的请求，也没有连接池方面的问题，也没有OS方面的报错，非常正常。数据库报告看了下，没有压力。
2.要求现场拿回httpwatch的监控结果，发现有一个大的功能请求里面包含的三个小请求等待超过799s，这三个小请求有一个是下载一个图片，其他两个理论上不可能存在慢的可能性，且造成后面的请求超时(ERROR_INTERNET_TIMEOUT)。重新梳理一下思路：
客户端浏览器 <=======> 中间件(weblogic) <=======> 数据库(Oracle)
中间件到数据库的这条链路上没有问题，如果有问题是可以从中间件日志中捕获到的。客户端浏览器到中间件这段链接出问题了，有两种可能性，一是网络出了问题，二是应用服务器不响应。
3.到底是那种问题，询问现场实施，其他的系统是否有问题，得到的答案是其他系统没有问题。那网络出问题的可能性较小。要想知道应用服务器是否出问题，只能通过监控应用服务器的OS的一些指标。
应用服务器上的操作系统是恰好有监控，如何配置，请参考http://blog.csdn.net/stevendbaguo/article/details/8737743 。无非是查看CPU、MEMORY、PhysicalDisk三样指标，把监控的数据用Excel生成图片，终于发现PhysicalDisk这项指标在21日上午极不正常，一直是处于高峰，最高值达到80M/s。根据我浅显的存储的知识，5400转的硬盘是54M/s,7200转的硬盘是72M/s，IBM的小机存储可达到200M/s，SSD可达400M/s--500M/s。现场不是小机，也不是SSD，我想80M/s已经非常高了，会产生大量的IO等待。
4.把分析结果告诉实施同事后，得到反馈是上午在做磁盘备份，在copy大量的文件。貌似原因找到了，告诫他以后这种事情要在下班时间弄。
标签：style blog http os java io ar 文件 数据
原文地址：http://blog.csdn.net/stevendbaguo/article/details/38870507
