公司的一个项目内的数据库经过重装后，通过我一段时间的观察，发现从某一特定时间起，根目录的占用情况每秒钟都会增长4个数据块大小，并且没有停止和系统回收的迹象：

以下是我分析并解决问题的思路及方法：
主机环境：CentOS 6.5
软件环境：Oracle 11g R2

• 手动在根目录下执行 du -ks *操作，并不能发现是哪个文件在缓慢增长，几个占用磁盘空间大的文件夹都已经划分成了独立文件系统，从而问题定位难度增大。

• 通过分析根目录增长的情况，每秒钟都有增长，说明该问题是实时存在的，可能不是某一个文件，所以考虑此种问题需要上升到操作系统层面。
• 通过观察/dev/shm目录下的文件，发现有很多ORA开头的二进制文件：
  

• 这些文件存在于/dev/shm中，并不是一个单独的物理文件系统，而是虚拟出来的，是在dev下面花了一个文件做swap空间用。

• 观察其中的某一个文件，印证想法是正确的，文件内的数据确实是二进制的，并且是实际业务中的信息：

观察到这里，联系Linux系统特性，只有在物理内存不够的时候，才会使用swap空间来分摊内存，也就是说物理内存很可能已经耗尽了。

• 执行free -g命令，查看当前内存情况：
  注：这里我也有一点不清楚的地方，貌似所有Linux虚拟机上的数据库，内存这块都会used到满，但是这个case里，buffers/cache明显不正常。

• 在服务器上执行top命令，发现一个异常进程占用了50多g的内存：

查询该进程名称nautilus，发现是该进程是图形化界面中文件管理器的进程，在安装完数据库后，并不用图形化界面来操作服务器了，直接kill掉。

• 再次使用free -g命令查看内存使用情况：目前内存已经到达正常状态。

使用df命令查看根目录增长情况：根目录的每秒自增长已经停止。

总结：数据库安装完毕后就不怎么用图形化了，可以都卸载了，然后把系统修改成3级，启动到命令界面就可以了，不同的环境可能存在不同的bug，需要注意观察。这个case看似很小，也许不注意观察的话很多人都不会去管它，但是根目录如果达到100%后，DB会怎样呢？呵呵。