公司的一个项目内的数据库经过重装后,通过我一段时间的观察,发现从某一特定时间起,根目录的占用情况每秒钟都会增长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会怎样呢?呵呵。


少放香菜
56 声望3 粉丝