公司的一个项目内的数据库经过重装后,通过我一段时间的观察,发现从某一特定时间起,根目录的占用情况每秒钟都会增长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会怎样呢?呵呵。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。