Performance Tips

It is highly recommended to configure indexTemp folder on a SSD disk, if possible different from your operating system partition or disk, free of antivirus scanning, system indexing or shadow copy services.

Use different disks for temp folder, output directory and forensic images. If possible, put your forensic images in a non parity RAID disk array.

Use java 8 64bits version. You need a very minimum of 8GB of RAM, do not expect fast processing with that, 16GB or more is recommended. Do not allocate all your memory to IPED processing with java -Xms/-Xmx options, IPED often just uses some gigabytes. IPED needs free memory to run external tools (imagemagick, mplayer, tesseract, python modules...) and to use as IO cache for your images and case index, so it is very important to have free memory. IPED will need more free memory if you turn on the advanced options 'enableExternalParsing' or 'robustImageReading'.

IPED used memory increases at processing time if you have dozens of CPU cores (1GB per logical CPU core is a rule of thumb) and at analysis time if your case is huge (for dozens of millions of files you will need a few dozens of GBs). Generally, it is best to let the JVM allocate memory by itself (by default it takes 1/4 of your physical RAM) instead setting it with -Xms/-Xmx, although setting half of your physical RAM is another good rule of thumb (if you don't enable robustImageReading and mainly enableExternalParsing). Increasing the heap manually might also workaround some OOME errors (see https://github.com/sepinf-inc/IPED/wiki/Troubleshooting). Never allocate more than 32GB of heap, pointers will double in size and you will end with less heap to use.

If you are processing E01 images and have more free memory available (don't forget you need free memory for IO cache), enable robustImageReading in conf/AdvancedConfig.txt. It will uncompress data from E01 images in parallel using your multiple CPU cores and can result in great speed ups, up to 3x depending on your dataset and hardware. Without that, just one item is uncompressed at a time by sleuthkit because libewf library is not thread safe and it will synchronize reads and will bottleneck.

If you enable OCR module, processing time can increase from hours to days if you have lots of scanned documents, currently that is the slowest module of the tool and the only thing you can try to do is using the -ocr option to limit the OCR to some subset of your files (https://github.com/sepinf-inc/IPED/wiki/User-Manual#ocr) or disabling OCR completely.