我有 RHEL 5.4 内核 2.6.18-164.el5，并且在使用 Oracle 期间随机发生磁盘性能非常差的情况。
日志中没有显示任何内容。
当这种情况发生时，我看到一个 CPU 核心卡在 100% 系统时间top：
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 1.0%us, 0.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu8 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu9 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu10 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu11 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu12 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu13 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu14 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu15 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8097368k total, 5761028k used, 2336340k free, 602024k buffers
Swap: 2088440k total, 0k used, 2088440k free, 3070188k cached
检查磁盘写入，dd我在上面得到相同的结果，它显示：
time dd if=/dev/zero of=1000 bs=2M count=500 conv=fdatasync
79+0 records in
79+0 records out
165675008 bytes (166 MB) copied, 279.746 seconds, 592 kB/s
real 4m40.565s
user 0m0.000s
sys 4m40.521s
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8557 root 25 0 65212 2640 2548 R 99.8 0.0 3:02.99 dd
在正常操作期间我得到：
500+0 records in
500+0 records out
1048576000 bytes (1.0 GB) copied, 9.24778 seconds, 113 MB/s
real 0m9.249s
user 0m0.001s
sys 0m1.772s
这些磁盘是采用 RAID1 配置的两个 15k RPM SAS，由 MegaRAID SAS9261-8i 控制器管理。
我已经升级了控制器的驱动程序和固件。
奇怪的问题是系统可以正常工作数周，并且所有磁盘基准测试都显示出良好的结果。
如何调试这种糟糕的磁盘性能？
对于 Patrick 请求，这是 100%sy 期间的输出
top - 14:12:57 up 13 days, 15:49, 3 users, load average: 1.28, 1.48, 1.17
Tasks: 424 total, 2 running, 422 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu8 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu9 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu10 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu11 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu12 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu13 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu14 : 0.0%us,100.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu15 : 0.0%us, 1.0%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8097368k total, 6167440k used, 1929928k free, 306644k buffers
Swap: 2088440k total, 4k used, 2088436k free, 3638216k cached
mpstat -P 全部 3 1
02:13:19 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
02:13:22 PM all 0.06 0.00 6.50 0.00 0.02 0.00 0.00 93.42 1077.00
02:13:22 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1001.33
02:13:22 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
02:13:22 PM 2 0.00 0.00 0.00 0.00 0.33 0.00 0.00 99.67 43.67
02:13:22 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
02:13:22 PM 4 0.00 0.00 0.00 0.33 0.00 0.00 0.00 99.67 16.33
02:13:22 PM 5 0.33 0.00 2.99 0.00 0.00 0.00 0.00 96.68 0.00
02:13:22 PM 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.33
02:13:22 PM 7 0.33 0.00 0.00 0.00 0.00 0.00 0.00 99.67 0.00
02:13:22 PM 8 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
02:13:22 PM 9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
02:13:22 PM 10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
02:13:22 PM 11 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
02:13:22 PM 12 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
02:13:22 PM 13 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
02:13:22 PM 14 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00 14.33
02:13:22 PM 15 0.66 0.00 1.00 0.00 0.00 0.00 0.00 98.34 0.00
Average: CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
Average: all 0.06 0.00 6.50 0.00 0.02 0.00 0.00 93.42 1077.00
Average: 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 1001.33
Average: 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
Average: 2 0.00 0.00 0.00 0.00 0.33 0.00 0.00 99.67 43.67
Average: 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
Average: 4 0.00 0.00 0.00 0.33 0.00 0.00 0.00 99.67 16.33
Average: 5 0.33 0.00 2.99 0.00 0.00 0.00 0.00 96.68 0.00
Average: 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.33
Average: 7 0.33 0.00 0.00 0.00 0.00 0.00 0.00 99.67 0.00
Average: 8 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
Average: 9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
Average: 10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
Average: 11 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
Average: 12 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
Average: 13 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 0.00
Average: 14 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00 14.33
Average: 15 0.66 0.00 1.00 0.00 0.00 0.00 0.00 98.34 0.00
sar -I XALL 3 1 中断高于0
Average: INTR intr/s
Average: 0 1000.33
Average: 51 7.33
Average: 59 1.00
Average: 75 23.33
Average: 218 61.67
Average: 233 0.33
似乎没有中断问题
答案1
我们发现了问题。vm.zone_reclaim_mode默认设置为 1。
我们通过 sysctl 禁用了它vm.zone_reclaim_mode=0，之后就没有再发生过。有几个地方有相关信息：
- http://blog.fastmail.fm/2010/09/15/default-zone_reclaim_mode-1-on-numa-kernel-is-bad-for-fileemailweb-servers/
- http://www.centos.org/docs/5/html/5.5/Technical_Notes/Known_Issues-kernel.html
- http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5079940
- http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
- http://kevinclosson.wordpress.com/2009/05/14/you-buy-a-numa-system-oracle-says-disable-numa-what-gives-part-ii/
- http://www.pythian.com/news/1324/oracle-performance-issue-high-kernel-mode-cpu-usage/
答案2
时间 dd if=/dev/zero of=1000 bs=2M count=500 conv=fdatasync
...
真实4米40.565秒
用户0m0.000s
系统4分40秒521秒
嗯，这当然与您通常运行 Oracle 的事实无关（注意，虽然 /dev/zero 会快速生成输出，但由于稀疏文件支持，向 Unix 文件系统写入大量空字节并不是一个很好的基准 -在这种情况下，性能非常糟糕，以至于问题仍然很明显）。
即使你的“正常”计时看起来也相当慢 - 但这些与糟糕的表现之间仍然存在巨大的鸿沟。
在老式的 2 核单 SATA 盒子上，我得到：
real 0m6.961s
user 0m0.001s
sys 0m1.459s
你可以轻松地切换你的磁盘配置（例如绕过megaRAID控制器并使用mdadm（软件）raid吗？（注意，我之前在md设备上运行MySQL时遇到了一些严重的问题 - 虽然这可能只是我/老的问题）错误现已修复，我建议在测试时计划最坏情况的结果）。
偶尔出现的性能不佳表明磁盘可能会脱机然后重建 - 报告任何错误吗？