See our article: Improving Indexing Performance By Adding Threads And Cores
See our article: Understanding Disk I/O in Relation to Retain Performance
RAM / Swap Space
Memory is the biggest key. The indexer creates a MemoryMap on disk and caches the entire index into it. It will want to put as much of that MemoryMap into RAM as possible. When it doesn't have enough RAM, we've seen systems become unresponsive. On Linux systems, we'll see the load average skyrocket to 112. Bottom line: Increase your system's RAM. Depending on the size of your indexes ([base storage directory]/index/solrhome/retaincore/data/index), 32 GB of RAM may not be enough. Give it as much as you can.
If you can't increase RAM, we have found that increasing the swap space available to the server can help prevent the issue where tomcat becomes unresponsive, but cannot guarantee that. The following virtual (swap) memory size recommendations are preliminary, as we have not isolated all variables but this will improve matters in many cases. In Linux, we've seen in /var/log/messages the following statement when swap was the issue:
Apr 2 13:23:26 wapvo-retain01 nagios: SERVICE ALERT: localhost;Swap Usage;CRITICAL;SOFT;1;SWAP CRITICAL - 0% free (0 MB out of 4094 MB)
Dedicate 50-100GB of swap space.
VM Resource Limits
See "Retain Tomcat becomes unresponsive after several mailbox searches" for a VMware resource limitation setting that could cause tomcat to become unresponsive.