So I was able to secure for our security team a rack server that was destined for the scrap heap (it’s CPUs have just fallen off the supported list for ESXi as of 7u3). It has 768GB of ram. So, from what I’ve read you shouldn’t set the Solr memory above 20GB, but what about the regular JVM memory settings? Is there too much?
When ingesting a data source the entire machine will be dedicated to the task so I don’t have to worry about sharing resources with other VMs so I can go ham with everything. (I wish that Autopsy let me use more than 8 threads because I have 32 logical processors on this machine) Everything here has been switched over to SSDs so the biggest image I’d have to deal with is 256GB and that’s raw, so we don’t have to take into account disk access as I can create ramdisks to max that out.
So is there a point where I would be seeing diminishing returns with JVM size?
I’d like to follow this topic too as Ive found it hard to know the best way to optimise my set up.
@Nebular @fancy_flare All systems are different and there are a lot of variables aside from CPU & RAM & disk but I’ll do my best to answer your questions.
First thing first - are you using single user Autopsy cases or multi-user? Is the case output directory stored on machine’s local drive or on a network share? If it is on a network share, it will be a huge bottle neck which will set the upper limit for your performance. How big are the cases and data sources that you are processing? It also matters which ingest modules you’re running, some of them are single threaded.
So, from what I’ve read you shouldn’t set the Solr memory above 20GB
Apache Solr recommends not setting heap size above 32GB. At that point the garbage collection starts to take too long which can fatally affect Solr’s performance.
but what about the regular JVM memory settings? Is there too much?
I don’t know that there’s too much heap for Autopsy as it is less sensitive to GC pauses than Solr. That said, I think past a certain point you just don’t get any benefit. In our production deployments we typically set Autopsy JVM somewhere between 20-30GB. The only way to know for sure how much heap the application actually requires is to attach VisualVM and watch the heap usage.
I wish that Autopsy let me use more than 8 threads because I have 32 logical processors on this machine
We have experimented with that and you get diminishing returns quickly as you increase number of Autopsy threads. In fact, on many systems 6 threads will complete ingest faster than 8 threads. That’s because eventually the threads start competing for the same resources and run into bottlenecks like database access and Solr. Solr will almost certainly be the biggest bottleneck by far because a higher number of Autopsy threads will be throwing data at it for indexing, and it won’t be able to keep up, thus holding up Autopsy threads. If you do not need keyword search, you should definitely disable the keyword search module.
Hope this helps.
Well I did some testing. Autopsy in windows crashes with a JVM setting any higher than 64GB. And while watching I didn’t see it ever go above 30GB.