0

The disk is nearly full,how to investigate which files are occupying most space?

EDIT

I found most space are taken by mysql bin log:

/var/lib/mysql/jiaoyou-slow.log: 53M
/var/lib/mysql/mysql-bin.000005: 68M
/var/lib/mysql/mysql-bin.000003: 1.1G
/var/lib/mysql/mysql-bin.000007: 34M
/var/lib/mysql/mysql-bin.000004: 225M

Are these files safe to delete?

1
  • 1
    Don't touch those logs. There is a strong possibility that those log files can be truncated by merely performing a database backup. I'm not a MySQL expert, but you should at least look into it.
    – djangofan
    Jun 30, 2011 at 16:39

7 Answers 7

3

Something like this should do the trick for you:

find / -type f -size +20000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }' 

This looks for any file under / (root) that is roughly over 20mbs in size. You may need to adjust the $9/$5 variables but in most cases you won't have to. I also recommend changing / to /var/log/ if you simply want to look under your default log folder.

2
  • It only output file size but not the file names...
    – Mask
    Nov 6, 2009 at 4:22
  • As I said, you may need to fidget with the variables. Try changing $9 to $8 and so forth. On my OSX system, that outputs file names and sizes but it may be different on yours.
    – Bartek
    Nov 6, 2009 at 4:25
3

If you are using a graphical environment, you could use something like Disk Usage Analyser (aka Baobab) that can produce a nice ringschart as shown below:

alt text
(source: marzocca.net)

The command line is still your best weapon but I find it very handy. There are some alternatives here.

1
  • I'm using command line.
    – Mask
    Nov 6, 2009 at 4:40
2

Its a good idea to use logrotate(8) to compress and remove old log files, so that some chatty daemon doesn't fill up the entire disk.

EDIT: Also, most logs will be located in /var/log. A simple ls -lh will list which ones are getting too big.

0

The du command, at a command-line, will tell you which directories/folders are occupying the most space. You can infer from this where the biggest files are.

$ du -h /

The -h tells du to list the sizes in 'human readable terms: kb, Mb, Gb, and so on.

If you try this as an ordinary user, you'll see error messages about directories you don't have permission to examine.

If you do it as root, there should be no error messages.

# du -h /

pipe the output through sort -n so that the last lines show the biggest directories (or reverse sort and use head).

# du -h | sort -n 

Another approach would be to use find with options which specify 'find files bigger than a certain size' but this method requires some practice to get it right.

# find / -size +10M

will list files bigger than 10Mbyte

1
  • It's listing too much information.How to target the biggest files at once?
    – Mask
    Nov 6, 2009 at 4:21
0

If you have reasonably-sized partitions, You should search for large files outside the log directory. Logs are unlikely to be your problem, they seldom reach more than 200 MiB on the average system.

You should refrain from deleting logs as long as you are not sure what you actually do. Many daemons react pretty erratic if their logfiles are gone suddenly - the results can be anything from no-longer-working services up to being unable to restart that particulary service.

You should be save if you remove the files under /var/log/* that are archived (e.g. have the ending .gz). Again, I doubt that actually solves your main problem (e.g. harddisk too full)

0

Top 25 directories and/or files:

du -m / | sort -rn | head -25
0

OK, so I cheated and looked over at DBA.... :)

https://dba.stackexchange.com/questions/41050/is-it-safe-to-delete-mysql-bin-files

(The top two answers from 'RolandoMySQLDBA' and 'Derek Downey' are relevant and insightful.)

There are two types of 'log files' here, sadly. One is the logs of transactions applied to your MySQL databases. These files can be used to synchronize a MySQL slave to a MySQL master, or restore a database. As the top answer linked to in the page above shows, you should use only the MySQL commands (or meta-tools, such as Percona Toolkit) to "purge" these logs.

The other file, 'jaioyou-slow.log', is likely just a Slow Query Log, logging queries that take longer than a defined time to complete. This is a log file most similar to a typical *NIX log file, and therefore, can be truncated if needed (though you'll lose the performance statistics available in that file, obviously.)

You could use a useful tool like 'logrotate' to handle this (and only this) file, or, in an emergency, just do:

$ echo "" > /var/log/jaioyou-slow.log

Some observations:

  • Your mysql configuration should put the MySQL Slow Query Log into a more appropriate *NIX log location, like /var/log/mysql/, rather than the /var/lib tree, to avoid confusion, and, perhaps, increase performance, if those directories are on separate disks.
  • You'll need to have some kind of automation to purge thebinary logs from within MySQL (or third-party tools). I do not reccomend just deleting them with the operating system commands.

References:

1
  • : > /var/log/jaioyou-slow.log is enough
    – Kondybas
    Oct 15, 2016 at 8:15

You must log in to answer this question.