oracle数据库所在主机内存耗尽

大体上就是不断的告警，主机内存基本使用完了，swap使用90%。这个时候就开始着手处理。详细经过就不写了，这里只写一些事后总结。

总结一下，
1，要精确厘清到底哪些进程使用的内存是合理的，哪些是不合理的，合理的进程使用的内存大点也没关系，不合理的才是出问题的关键。
top -d 1 可以看一个整体，里面有几个指标,RSS、SHR、VIRT;其中RSS表示进程驻留在物理内存中的内存大小，但并不是指进程的私有内存空间，也可以是共享内存。%MEM指标就是使用"RSS/物理内存" 计算出来的。我一开始使用%MEM这个指标从高到低排序，找出来的全部是oracle的进程，并且排在前面的每个都使用3G以上内存，这个值与通过v$process查出来的pga内存大小不符合。这个一度误导了我，使我猜测是否主机出现问题，导致oracle统计的pga内存使用与实际不符。这中间绕了我几个小时，我还试着kill了几个sessioin。惭愧！
在top -d 1的基础上，使用f键可以选择显示的列，这里增加显示DATA、SWAP两个列，接着再使用h键看了一下帮助文档，使用F键选择排序字段，这里选择了SWAP进行排序。这里就能明显的看出来，是由两个java进程使用了过多的内存，并占用了过多的swap空间。

2，另外两个命令也是比较重要的，可以与上面的结论进行相互佐证：
ipcs -m ，这个命令和参数就直接看整个系统上的共享段，可以看到oracle的主进程相关的三个共享段，其中一个较大20G，另外两个较小。较大的这个就是SGA的共享内存段；
pmap -x "pid" ,这个就可以选一个oracle进程，检查这个oracle进程的内存空间分配，与v$process中的pga大小进行佐证。需要注意的是，这个这个命令显示的结果包含了sga共享段和一些共享的so代码库，这些应该不需要算在此进程的私有空间中，需要排除掉，然后将剩下的结果相加，与v$process比较一下，这个时候就基本确定了不是oracle进程的问题了。