以下情况发生了两次，使用不同的RAID控制器。 一个是运行RAID5的LSI MegaRAID，另一个是运行RAID1的HP Smart Array E200i。 起初服务器工作顺利几年。 然后人们开始抱怨表演。 然后，它不仅仅是“应用程序问题”，因为简单的磁盘操作（如20-30个文件目录中的ls）可能需要长达5秒。 以下是在繁重的工作负载中，vmstat报告的内容：
procs -----------memory------------ ---swap-- -----io---- -system-- ----cpu----- rb swpd free buff cache si so bi bo in cs us sy id wa 1 8 8944 126004 20 1597500 0 0 1666 5935 282 833 10 3 0 86 1 16 8944 122276 20 1599636 0 0 612 6300 314 615 10 3 0 87 1 12 8944 123740 20 1599332 0 0 811 5103 188 794 2 2 0 96 0 19 8944 121916 20 1600808 0 0 150 7299 163 858 1 1 0 97 0 16 8944 239244 20 1612256 0 0 647 2522 156 798 0 1 0 99 0 6 8944 215308 20 1643712 0 0 3030 3060 201 956 33 5 0 62 1 13 8944 186352 20 1672540 0 0 143 6173 166 931 14 8 0 78 8 2 8944 137368 20 1710432 0 0 111 6425 171 833 48 4 0 48 1 11 8944 122500 20 1725892 0 0 306 5222 153 746 69 4 0 27 24 13 8944 128444 20 1729680 0 0 380 5210 170 4484 16 6 8 70 0 4 8944 124956 20 1731228 0 0 389 4933 272 761 4 2 0 93 0 6 8944 123004 20 1735780 0 0 15 7856 209 682 1 2 7 90 所以服务器从生产使用中退出，并用bonnie ++进行testing，并用vmstat进行监控，这给出了几乎相同的结果。 所以这似乎是磁盘有问题。 但是，在查询RAID控制器时，看起来逻辑驱动器和物理磁盘都可以。 此外，内核日志不包含任何可能表明磁盘操作出现问题的消息。
所以我的问题是：如何进一步debugging这个问题？ 我必须更换控制器/磁盘，只是看到哪个更换情况好转后？ 或者也许可以执行一些命令并研究其结果，以确定问题的确切位置？
可以写cachingclosures吗？ 也许电池已经死了，它从回写切换到直写？
一些便宜的硬件RAID没有电池和默认caching启用caching只是为了读取 – 它可能是你把它设置为使用写caching也控制器“丢失”的设置？
此外 – 也许其中一个驱动器是错误的？ 尝试查看RAID日志[MegaCli命令行工具应该帮助]。