We have recently upgraded our EV/CA/DA environment to 9.0.2 from 8.5, and new highly specd 2008 64bit VMs. We are not finding an improvement in DA search speed (not sure about CA).
I am reviewing the DA 9 Best Practices guide (http://tinyurl.com/c7kkbks) and need advice please. Our "Number of Vault search Threads" is currently set to 5. I am wondering if we should set this much higher given our 64bit hardware and new powerful VMs. I understand we also need to set "ThresholdIndexServers" and "MaxIndexServers" on the EV servers as per page 47 of the guide?
I realise there is a lot in that guide but I am specifically interested in quick tweaks that may have significant speed increases for searching. We are reviewing our SQL builds, but we do the database maintenance best practices already.
Any other speed increase advice would be greatly appreciated!
Recommended steps to optimize performance on Enterprise Vault (EV), Compliance Accelerator (CA), Discovery Accelerator (DA), and SQL Servers in an EV environment - http://www.symantec.com/docs/TECH56172
Routine monitoring and maintenance for the Accelerator environment - http://www.symantec.com/docs/TECH63230
How many other dBs also reside on the SQL server? How much of RAM are in these servers? If you followed all the recommendations of these 2 docs, you could try and Set Maximum Number of consecutive searches on same index to 0 back from 1. Exactly how long does a search for 1 day take?
The CA/DA SQL VM server is 2008 R2, 8GB RAM 4 CPU quad core.
The EV SQL VM server is 2008 R2, 32GB RAM 4 CPU dual quad core.
CA/DA has the CA/DA config databases (2.5GB and 0.5GB), the CA/DA customers databases (85GB and 112GB) and the SSRS database (0.5GB, not used much). So 5 databases in total.
I would recommend setting the Number of Vault search Threads to the default of 10. I believe the Best Practices Guide recommend throttling it back to lower the resource hit on the EV servers that hold the searchable indexes. You really do not need to do this unless an Accelerator search starts throwing errors. As well with setting Maximum Number of consecutive searches on same index to 0 ( 0 actually means infinite, which is why the technote recommends throttling it back to 1 thread per index), you would leave the settings as they are out of the box, only throttling them back if you experienced the resource hit on the DA and EV servers, which manifests itself as errors in the search and slow vault performance to end users retrieving items etc while the search ran. Hope this helps.
Even though it is comparing apples to oranges, in that each environment is different, I just ran a wide-open date range search across 375 archives, gathering 4,893,003 hits in 22 minutes.Hope this helps give you some perspective.