- Cleanup IBM JVM javacore and heapdump files
- IBM javacore and heapdumps might be automatically created due to OutOfMemory errors or when jvm crashes due to certain conditions, or it can be user initiated to debug certain problems like hanging threads, high cpu utilization and memory leaks. Javacore ( javacore.20080306.020447.11544.txt ) and heapdumps ( heapdump.20080128.195700.20399.phd ) files can be found under WAS_HOME/profiles/Portal01 directory usually in sizes of several mega bytes depending on your applications and when several of them gets created you might easily run into disk space problems. Clean up or move these files as and when necessary and work with IBM support to debug this issue and prevent these files from getting generated.
- JCR Search Indexes might get huge in size
- JCR Search indexes that are created under WPS_HOME/jcr/search can sometimes be large in size particularly docsdata.dat in terms of several GB's more than the actual content size itself, so whenever you think the size is large than what your content size itself , then it's safe to delete all the contents under WPS_HOME/jcr/ directory and restart WebSphere Portal to recreate the indexes.
- Archived Portlet Applications .ear files
- Archived Portlet Applications .ear files are created under the WPS_HOME/deployed directory everytime you install a portlet application, the number of files will get increased particulary when you do several deployments, particulary this can happen during your development cycles. As long as you are not required to locally archive these files on that specific system, then they can be safely removed (i.e., deleted or moved to another storage location.)
- Rotate SystemErr.log, trace.log and SystemOut.log
- By default WebSphere Portal keeps upto 5 historical files with sizes of 5 MB each and will start rotating the logs. Sometimes it seems low because log files gets huge quickly when you enable additional tracing and u that yodon't want to loose the trace information during the problem recreation if it start rotating the logs. so choose the size of a file and the number of historical files wisely and not overrun your disk space. Also native_stderr.log and native_stdout.log don't get rotated , hence you need to periodically clean the files or zero the file size, as i have seen problems that WebSphere process would hung if native_stdout.log file get to 4GB in size and it won't come up until you clean and restart, particularly in linux environment.
- Use disk usage (du) command to determine huge directory size
- After checking all the above you might still run into unknown large files like applicaton logs, core dumps , etc. so in order to find them, run this command ls -d * | xargs -i bash -c 'echo {};du -ch $PWD/{}/| grep total' | grep G -B 1 which will list you directory and files who sizes that are in GB, based on the results you should be able to make discussion with the respective team and delete them if they are not needed.
I will keep them updated when i find some more.
