Linux中大内存页Oracle数据库优化的方法

前言

PC Server发展到今天，在性能方面有着长足的进步。64位的CPU在数年前都已经进入到寻常的家用PC之中，更别说是更高端的PC Server；在Intel和AMD两大处理器巨头的努力下，x86 CPU在处理能力上不断提升；同时随着制造工艺的发展，在PC Server上能够安装的内存容量也越来越大，现在随处可见数十G内存的PC Server。正是硬件的发展，使得PC Server的处理能力越来越强大，性能越来越高。而在稳定性方面，搭配PCServer和Linux操作系统，同样能够满重要业务系统所需要的稳定性和可靠性。当然在成本方面，引用一位在行业软件厂商的网友的话来说，“如果不用PC Server改用小型机，那我们赚什么钱啊？”。不管从初期的购买，运行期的能耗和维护成本，PC Server都比相同处理能力的小型机便宜很多。正是在性能和成本这两个重要因素的影响下，运行在PC Server上的数据库越来越多。笔者所服务的一些客户，甚至把高端的PCServer虚拟化成多台机器，在每台虚拟机上跑一套Oracle数据库，这些数据库不乏承载着重要的生产系统。

毫无疑问，在PC Server上运行Oracle数据库，最适合的操作系统无疑是Linux。作为与UNIX极为类似的操作系统，在稳定性、可靠性和性能方面有着与UNIX同样优异的表现。但是Linux在内存分页处理机制上与AIX、HP-UX等操作系统相比有一个明显的缺陷，而这个缺陷在使用较大SGA的Oracle数据库上体现尤为明显，严重时对数据库性能有着显著的负面影响，甚至会导致数据库完全停止响应。而本文就将从一个案例来详述这种缺陷，并使用Linux下的大内存页来解决这一问题。

一、案例的引入

客户的一套系统，出现了严重的性能问题。在问题出现时，系统基本不可使用，应用上所有的业务操作完全失去响应。系统的数据库是运行在RHEL 5.2 (Red Hat Enterprise Linux Server release 5 (Tikanga))下的Oracle 10.2.0.4 Oracle Database，CPU为4颗4核至强处理器（Intel(R)Xeon(R) CPU E7430 @ 2.13GHz），也就是逻辑CPU为16，内存32GB。故障期间，数据库服务器的CPU长期保持在100%。甚至将应用的所有Weblogic Server都关闭之后，数据库服务器的CPU利用率在数分钟之内都一直是100%，然后逐渐下降，大约需要经过20分钟才会下降到正常的空闲状态，因为这个时候所有的应用都已经关闭，只有非常低的CPU利用率才是正常的状态。据这套系统的数据库维护人员反映，这种情况已经出现多次，就算是重启数据库之后，过不了一两天，这样的故障同样会出现。同时这套系统最近也没做过大的变动。

笔者在接到接到故障报告后，通过SSH连接到数据库数据库都非常慢，需要差不多1分钟才能连接上去。先简单的看一下服务器的性能状况，发展IO极低、内存剩余还比较多，至少还有1GB以上，也没有page in / page out。而最显著的现象就是CPU利用率相当地高，一直保持在100%，同时CPU利用率的SYS部分，均在95%以上。而操作系统运行队列也一直在200以上。服务器内存的使用情况如下：

$cat/proc/meminfoMemTotal: 32999792 kBMemFree: 1438672 kBBuffers: 112304 kBCached: 23471680 kBSwapCached: 1296 kBActive: 19571024 kBInactive: 6085396 kBHighTotal: 0 kBHighFree: 0 kBLowTotal: 32999792 kBLowFree: 1438672 kBSwapTotal: 38371320 kBSwapFree: 38260796 kBDirty: 280 kBWriteback: 0kBAnonPages: 2071192 kBMapped: 12455324 kBSlab: 340140 kBPageTables: 4749076 kBNFS_Unstable: 0 kBBounce: 0 kBCommitLimit: 54871216kBCommitted_AS: 17226744 kBVmallocTotal:34359738367 kBVmallocUsed: 22016 kBVmallocChunk:34359716303 kB