昨天，一个用户打来了紧急求助电话，并且发了邮件，弄得我当时紧张了一下，以为他们那里又出了什么乱子。用户在电话里说：应用系统性能很差，运行很慢，几近“卡死”的感觉，而且重启了多次应用和数据库服务器，最终还是没解决，我们该怎么办。。。用户在电话里说的很急，有点糊里糊涂，我赶紧问：现在事故正发生吗？他说：不是。我更糊涂了，赶紧问：什么时候的事情？用户说：昨天的事情。我立刻放松下来，问用户：昨天的事情怎么才找我？用户说：昨天现场的工程师和维保人员，他们一开始很自信，一直在捣鼓，结果捣鼓了好几个小时也没查出结果，后来系统就自己好了。。。我笑着问用户：既然好了，你还给我打电话干嘛？而且还那么着急，弄得我都有点紧张了。。。用户还是很着急的说：我们现场人员和维保公司的人，到现在也没搞清楚当时怎么回事儿，怕今天和以后还发生，所以就找你给看看，昨天到底是咋回事儿，因为这个事情，昨天的系统好几个小时一直不能用，领导都已经不满意了。既然用户要求，那就得动工了，因为事故发生的时间比较久了，当时的系统状况都不了解，而且很多信息也许永远获取不到了。现在只能让用户取下能获取的信息，事故发生时的系统和数据库报告和日志等，发过来看了下，当时数据库系统的性能确实很差，尤其是IO性能，如下图：
那么，什么原因导致的IO性能如此之差呢？继续分析了下当时的IO负载，并不是很重，至少对用户的这款存储来说不会导致如此差的性能，如下图：
既然系统上的IO负载不重，那么就是存储设备出现了问题，但看了数据库和系统的运行日志，并未发现存储方面的报错信息，而且，我一再和用户现场人员核实，确认最近硬件没问题，也没人动数据库服务器的软硬件。。。
系统存储一段时间突然性能陡降，一段时间后又恢复了正常。。。忽然，灵光一现，我向用户提出看下存储运行日志，用户马上发给了我，我看了下，验证了我的判断，到这里，大家应该知道到底什么原因导致的事故了吧？如果有的同学还不清楚，那继续，如下图：
至此，真相大白，和用户的现场人员核实了当时的情况，虽然我们知道了事故的原因，但这件事儿警示我们运维人员在今后的工作中须更加勤快、认真和负责，以避免类似事故的发生，禁止转载。