linux 分区使用率过高又查询不到被哪些文件占用的问题
May212014
今天客户反映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———————————————-
—
【上一篇】sculkget failed to lock oracle10gdbdbslkinstB1ACDB2 exclusive lock held by PID
【下一篇】传输表空间(TTS transport tablespace)传输多个表空间
【下一篇】传输表空间(TTS transport tablespace)传输多个表空间
linux 分区使用率过高又查询不到被哪些文件占用的问题：等您坐沙发呢！
发表评论
