今天现场实施反馈系统总体慢。已经接到用户许多的投诉，要求现场发回weblogic日志和Oracle 数据库报告。简要说下系统的架构：典型的B/S三层架构，开发语言是java，中间件用的是weblogic，数据库用的是Oracle，用的都是pc server。
1.分析weblogic日志和数据库报告。weblogic日志里面没有stuck的请求，也没有连接池方面的问题，也没有OS方面的报错，很正常。
数据库报告看了下。没有压力。
2.要求现场拿回httpwatch的监控结果，发现有一个大的功能请求里面包括的三个小请求等待超过799s。这三个小请求有一个是下载一个图片，其它两个理论上不可能存在慢的可能性，且造成后面的请求超时(ERROR_INTERNET_TIMEOUT)。又一次梳理一下思路：
client浏览器 <=======> 中间件(weblogic) <=======> 数据库(Oracle)
中间件到数据库的这条链路上没有问题。假设有问题是能够从中间件日志中捕获到的。client浏览器到中间件这段链接出问题了。有两种可能性，一是网络出了问题。二是应用server不响应。
3.究竟是那种问题，询问现场实施，其它的系统是否有问题，得到的答案是其它系统没有问题。那网络出问题的可能性较小。
要想知道应用server是否出问题，仅仅能通过监控应用server的OS的一些指标。
应用server上的操作系统是恰好有监控，怎样配置，请參考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大量的文件。貌似原因找到了。告诫他以后这样的事情要在下班时间弄。