linux java占用199%,linux分区使用率过高又查询不到被哪些文件占用的问题

今天客户反映RAC的一个节点/tmp目录空间使用率较高，昨天已经100%，我连上服务器检查的时候，使用率也超过80%。

[root@p3rac1 ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda6 19G 8.5G 9.6G 47% /

/dev/sda7 9.5G 7.3G 1.7G 82% /tmp

/dev/sda5 29G 665M 27G 3% /var

/dev/sda8 76G 18G 55G 24% /home

/dev/sda3 76G 4.4G 68G 6% /usr

/dev/sda2 487M 17M 445M 4% /boot

tmpfs 32G 0 32G 0% /dev/shm

可是无论是用ls -l命令还是du命令去查，/tmp只用了190M，那7G多的空间哪去了？

[root@p3rac1 ~]# du -sh /tmp

190M /tmp/

[root@p3rac1 ~]# du -ah /tmp/*

36K /tmp/9014/libwddapi.so

128K /tmp/9014/libcmdll.so

168K /tmp/9014

40K /tmp/9201/libwddapi.so

172K /tmp/9201/libcmdll.so

216K /tmp/9201

48K /tmp/9204/lsnodes

16K /tmp/9204/libwddapi.so

88K /tmp/9204/libskgxn2.so

88K /tmp/9204/libcmdll.so

244K /tmp/9204

3.7M /tmp/CVU_10.2.0.1.0.1_oinstall/libnnz10.so

4.0K /tmp/CVU_10.2.0.1.0.1_oinstall/exectask.sh

236K /tmp/CVU_10.2.0.1.0.1_oinstall/exectask

4.0K /tmp/CVU_10.2.0.1.0.1_oinstall/scratch

20M /tmp/CVU_10.2.0.1.0.1_oinstall/libclntsh.so.10.1

24M /tmp/CVU_10.2.0.1.0.1_oinstall

972K /tmp/fileDae3Xy

0 /tmp/fileFjcmvw.dmp

4.0K /tmp/gconfd-root/lock/ior

8.0K /tmp/gconfd-root/lock

12K /tmp/gconfd-root

4.0K /tmp/hsperfdata_oracle

0 /tmp/keyring-1YczYD/socket

4.0K /tmp/keyring-1YczYD

0 /tmp/locks/mutex_UXService.fifo

4.0K /tmp/locks

16K /tmp/lost+found

4.0K /tmp/lsnodes_get.sh

4.0K /tmp/lsnodes.sh

4.0K /tmp/mapping-oracle

0 /tmp/mapping-root

0 /tmp/orbit-root/linc-3c64-0-72175301b50b2

0 /tmp/orbit-root/linc-3c27-0-20bf15beeef2a

0 /tmp/orbit-root/linc-3ca6-0-5c363a05bd69f

0 /tmp/orbit-root/linc-3c0c-0-20bf15be4bdbc

0 /tmp/orbit-root/linc-3c83-0-6f9097ac25493

0 /tmp/orbit-root/linc-3c45-0-630f1bff15aa9

0 /tmp/orbit-root/linc-3c2b-0-20bf15bef0a69

0 /tmp/orbit-root/linc-3c2f-0-7217530115c92

0 /tmp/orbit-root/linc-3c22-0-2080e2bfd31b4

0 /tmp/orbit-root/bonobo-activation-register.lock

0 /tmp/orbit-root/linc-3c3b-0-5aafc763d81f

0 /tmp/orbit-root/linc-3c07-0-13e85db7ce88a

0 /tmp/orbit-root/linc-3c2d-0-4d5ba473807be

0 /tmp/orbit-root/linc-3caa-0-f8a2ea2467d7

4.0K /tmp/orbit-root/bonobo-activation-server-ior

0 /tmp/orbit-root/linc-3c62-0-72175301adc79

0 /tmp/orbit-root/linc-3c35-0-72175301172a8

0 /tmp/orbit-root/linc-3c37-0-766f4d3f1dea

0 /tmp/orbit-root/linc-3c81-0-6f9097ac15c71

0 /tmp/orbit-root/linc-3c41-0-4d70b75c496c8

0 /tmp/orbit-root/linc-3c85-0-6f9097ac1618a

0 /tmp/orbit-root/linc-3bbb-0-299318e9f0236

0 /tmp/orbit-root/linc-3c29-0-20bf15bef05f6

8.0K /tmp/orbit-root

4.0K /tmp/scim-bridge-0.3.0.lockfile-0@localhost:0.0

0 /tmp/scim-bridge-0.3.0.socket-0@localhost:0.0

0 /tmp/scim-helper-manager-socket-root

4.0K /tmp/scim-panel-socket:0-oracle

0 /tmp/scim-panel-socket:0-root

0 /tmp/scim-socket-frontend-root

0 /tmp/ssh-CdvTo15291/agent.15291

4.0K /tmp/ssh-CdvTo15291

0 /tmp/stack0H9tvH

0 /tmp/stack2V9pZw

0 /tmp/stack3vIEJu

0 /tmp/stack4c9Mhl

0 /tmp/stack6fpipH

0 /tmp/stack6QLU6o

0 /tmp/stackaT58u0

0 /tmp/stackBSGfND

0 /tmp/stackFJvqPW

0 /tmp/stackfRfCEV

0 /tmp/stackfv5Zre

0 /tmp/stackguGp5c

0 /tmp/stackitIx6G

0 /tmp/stackJoORJO

0 /tmp/stackKubNLI

0 /tmp/stackM3TKSK

0 /tmp/stackM6eVmN

0 /tmp/stackqVHmMY

0 /tmp/stacksel3SO

0 /tmp/stackthvbVa

0 /tmp/stackUylEss

0 /tmp/stackxclQGA

0 /tmp/stackz21ThD

0 /tmp/stackZBVsXd

0 /tmp/stackznTGY3

4.0K /tmp/vi

4.0K /tmp/virtual-root.vXWqJm

这个问题我首先想到的就是肯定有文件被删除了但是空间没有释放，也就是调用这个文件的进程没有关闭，虽然文件被删除，但是由于句柄没有释放，这个文件还占用磁盘空间，此时使用ls -l命令和du命令就不会看到这些被删除的文件。猜想只是猜想，需要证明到底是不是这个问题。

[root@p3rac1 proc]# lsof | grep /tmp | grep delete

gconfd-2 15367 root 13wW REG 8,7 610 2074627 /tmp/gconfd-root/lock/0t1400320933ut950632u0p15367r1455985852k2632666984 (deleted)

oracle 24456 oracle 22u REG 8,7 21474844672 97266 /tmp/undo2.dbf (deleted)

通过lsof命令可以查到，/tmp/undo2.dbf还占用磁盘空间，这个文件大小有20G左右，可是从上文可以看到，/tmp目录一共不到10G的可用空间，这个20G的文件肯定是存不下的，查下这个文件是被什么进程占用的。

[oracle@p3rac1 ~]$ ps -ef | grep 24456

oracle 1306 716 0 11:38 pts/11 00:00:00 grep 24456

oracle 24456 11246 0 May17 ? 00:00:43 oracleheaddb21 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

通常LOCAL=YES的进程都是sqlplus或rman等工具在本地连接数据库的进程。到数据库里查询下这个进程在干什么。

SQL> select ADDR,PID,SPID,USERNAME,SERIAL#,TERMINAL,PROGRAM from v$process where sPID=24456;

ADDR PID SPID USERNAME SERIAL# TERMINAL PROGRAM

---------------- --- ----- -------- ------- -------- -------------------------

00000007DF1B9000 77 24456 oracle 51 pts/5 oracle@p3rac1 (TNS V1-V3)

SQL> select sid,serial#,sql_id,USERNAME,STATUS,OSUSER,MACHINE,TERMINAL,PROGRAM,LOGON_TIME from v$session where paddr='00000007DF1B9000';

SID SERIAL# SQL_ID USERNAME STATUS OSUSER MACHINE TERMINAL PROGRAM LOGON_TIME

--- -------- ------ -------- -------- ------ ------- -------- ----------------------- -------------------

439 45 SYS INACTIVE oracle p3rac1 pts/5 rman@p3rac1 (TNS V1-V3) 2014-05-17 23:49:35

从查询可以看出，是一个rman的进程在占用这个文件，在操作系统上也可以查看到，当前真有个RMAN在连接数据库。

[oracle@p3rac1 ~]$ ps -ef | grep rman

oracle 11246 30267 0 May17 pts/5 00:00:02 rman target /

oracle 26851 19970 0 12:19 pts/11 00:00:00 grep rman

打电话给维护人员确认，在5月17号晚上他们的确用RMAN备份undo2.dbf到/tmp目录下，后来因为空间不足中断了，他们也关闭了那个操作窗口，但是后天进程可能没有随之关闭。既然确认这个进程是个类僵死进程，而且对数据库没有影响，那就kill吧。

[oracle@p3rac1 ~]$ kill -9 24456

杀掉这个进程后，/tmp目录的磁盘使用率瞬间下将到正常值。

[oracle@p3rac1 ~]$ df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda6 19G 8.5G 9.6G 47% /

/dev/sda7 9.5G 190M 8.8G 3% /tmp

/dev/sda5 29G 665M 27G 3% /var

/dev/sda8 76G 18G 55G 24% /home

/dev/sda3 76G 4.4G 68G 6% /usr

/dev/sda2 487M 17M 445M 4% /boot

tmpfs 32G 0 32G 0% /dev/shm

问题解决。

————————————————————–end———————————————-