/u01 is filling up -how to know the large files

UNIX Solaris
1

hi,
my /u01 size is filling up and now reached to 93% on node 1 and 91% on node 2. it is usually very easy to identify large files normally dumps files or audit files etcetra but in this case i am not getting it as i am giving the following command to find the 5 biggest files of the file system but it return files with low size and dont know what actually eating the space

-bash-3.00$du -a /u01/ | sort -n -r |head -n 5
47130586      /u01
45352902      /u01/app
23009666      /u01/app/11.2.0
2300964       /u01/app/11.2.0/grid
22335572      /u01/app/oracle

Now the largets file is 44.94 mb so how to find the largest file or where is my space

please guide

thanks

Regards

2

If you'd been deleting files which happened to still be open, they won't be truly removed from disk until whatever had them open, closes them. This is a common trap new administrators fall into.

3

Have a look at the manual page to fuser

There is usually a flag or combination (dependant on your OS version) that you can use against the filesystem to show up open/deleted files and the processes using them. If you can safely terminate those processes, then the space occupied by those files will become free again.

We've all been there.

Robin

4

@rbatte1 You might be confusing fuser with pfiles. The former is telling what users have a handler on a given file given its path while the latter gives information about files open by a given process.

Only the latter can be useful to identify big files that have been removed.

5

Your list shows directories first, as they usually are larger than files in du . To get at the files only, try

find . -type f -printf "%s %p\n" | sort -nr | head
6

Apologies, it is my history with AIX that clouds my judgement, AIX fuser

The lsof tool can also provide some information I think.

Robin

7

My preferred method of doing this is to "zoom in" into the filesystem: i use du -ks * | sort -n on a certain level to find out which file/directory is using most. Then i investigate directories high up on this list again by changing into them and repeating the procedure.

For instance:

# # du -ks /var/* | sort -n
0       /var/aacct
0       /var/cim
0       /var/empty
0       /var/ha
0       /var/lib
0       /var/lost+found
0       /var/msgs
0       /var/ncs
0       /var/news
0       /var/pconsole
0       /var/probevue
0       /var/security
0       /var/snapp
0       /var/symapi
0       /var/tss
0       /var/yp
4       /var/statmon
4       /var/suma
4       /var/websm
8       /var/locks
8       /var/run
8       /var/tivoli
24      /var/dt
36      /var/krb5
52      /var/ssl
120     /var/esa
160     /var/preserve
516     /var/tmp
9828    /var/ecc
15140   /var/log
16208   /var/ct
18008   /var/perf
22096   /var/spool
101360  /var/adm
513168  /var/opt

Therefore i try "/var/adm" and "/var/opt":

# du -ks /var/opt/* | sort -n
0       /var/opt/freeware
0       /var/opt/tivoli
112324  /var/opt/perf
400856  /var/opt/OV

# du -ks /var/adm/* | sort -n
0       /var/adm/acct
0       /var/adm/corrals
0       /var/adm/ffdc
0       /var/adm/nim
0       /var/adm/perfmgr
0       /var/adm/sa
0       /var/adm/streams
0       /var/adm/wpars
4       /var/adm/SUchecklog.chk
4       /var/adm/SUreport.chk
4       /var/adm/dev_pkg.fail
4       /var/adm/dev_pkg.success
4       /var/adm/pconsole
4       /var/adm/sulog
4       /var/adm/wtmp
8       /var/adm/SRC
8       /var/adm/esa
8       /var/adm/ml
12      /var/adm/ena_lg_send_virt_eth.log
12      /var/adm/sni
16      /var/adm/sw
40      /var/adm/hfi
448     /var/adm/config
1912    /var/adm/invscout
3884    /var/adm/ras
94980   /var/adm/cron

etc., etc.. This way i get a quick picture of where most of the space in /var is going to.

I hope this helps.

bakunin

8

You might want to include the -x flag for du to ensure that you don't read any sub-mounted filesystems.

Robin

9

Find files younger than 7 days and bigger than 10 blocks, and sort by size; stay on the /u01 file system:

find /u01 -xdev -type f -mtime -7 -size +10 -ls | sort -k7n
10

You should check to see if tracing is turned on in the database. Of the directories that you show, which directory has the diag directory and how large is the .../diag/rdbms/<sidname>/<sidname>/trace directory. If that is the directory that is growing, then you need to turn off tracing and clean up the old trace files. Another option would be if either the temp or undo table spaces can grow without limit. If so you should check the size of your temp and undo directories to see if they are way too large. Ultimately, this looks like a database issue.

Careful about deleting database files, unless you really want to practice your database recovery strategy. :wink: