全部博文（1015）
分类： LINUX
2014-05-21 22:34:48
今天客户反映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———————————————-