Don't expect this to run quickly...
cd to a directory where you suspect there might be a subdirectory with lots of inodes. If this script takes a huge amount of time, you've likely found where in the filesystem to look. /var is a good start...
Otherwise, if you change to the top directory in that filesystem and run this and wait for it to finish, you'll find the directory with all the inodes.
find . -type d |
while
read line
do
echo "$( find "$line" -maxdepth 1 | wc -l) $line"
done |
sort -rn | less
I'm not worried about the cost of sorting. I ran a test and sorting through the unsorted output of that against 350,000 directories took 8 seconds. The initial find took . The real cost is opening all these directories in the while loop. (the loop itself takes 22 seconds). (The test data was run on a subdirectory with 350,000 directories, one of which had a million files, the rest had between 1 and 15 directories).
Various people had pointed out that ls is not great at that because it sorts the output. I had tried echo, but that is also not great. Someone else had pointed out that stat gives this info (number of directory entries) but that it isn't portable. It turns out that find -maxdepth is really fast at opening directories and counts .files, so... here it is.. points for everyone!
Old user accounts - use the user profiles from the system properties to delete them so you wipe any cruft from the registry as well.
Log files shouldn't be an issue to delete as long as they're not open.
Compression can help. Slows a little, especially if short on RAM, but can help.
Turn on "show hidden files" and in the Windows (or windows system) folder there should be a huge bunch of hidden compressed files used to roll back changes to updates. I usually don't have a problem "deleting" them as long as I have a backup in place and don't think I'll be rolling back any system updates in the future.
Suggestion - get your hands on an external hard disk and instead of deleting things, move them to the other storage. If there's an issue where the server goes kaplooey in the next day or two, you can restore it rather easily. Just don't use FAT on the external storage as large files can have issues with it.
I usually use 7zip to compress things I'm not sure that I'll need for awhile and archive it. Free, fast, can create self-extracting executables and tends to be better than ZIP.
Double check your windows components have just what you need installed. No need to have games if you don't use them (on a server??)
Double check that your program files subdir has just the programs you currently run in there. I have deleted old subdir cruft that was left behind from uninstalls.
Check that there aren't multiple versions of Java installed if you don't need them.
Check for caching of crud. Temp internet files, temp folders used for downloads, and cache directories in user subdirs are candidates for checking. I use "bytecount" (freeware) to get a good estimate on sizes of subdirectories because it's uber-tiny and simple to use.
Best Answer
Using this tip, I edited
/etc/init.d/atopAs the manual page says "four weeks", it was clearly there this command:
find $LOGPATH -name 'atop_*' -mtime +28 -exec rm {} \;So, 28 days old files will be kept...
I changed it to
find $LOGPATH -name 'atop_*' -mtime +1 -exec rm {} \;And ran this command:
sudo service atop _cronNow the logs are only at most for yesterday, that is what I need.