In addition to Paul's note about TCP Chimney, check the network cards on the EV, CA and SQL Servers for any Offload or Receive Side Scaling and disable these features. Access the properties of the network card, then click on the Advanced button to access the tabs that have these features.
The error you received is also indicative of possible issues between the index volume's physical size and the complexity of the CA search. First, check the physical size of the index volumes being searched. The error is associated with a particular archive, so you can do a quick check of all of the index volumes for that archive (unless there are over 10 or so). Any index volume that has its physical folder size over 3 GB can cause this error when the search criteria is even slightly complex.
When CA performs a search, it sends a request to the search engine to load into memory the index volumes for the archives selected to be searched. Each IndexServer process that is used to search the index volumes is allowed a maximum of 2 GB of memory (physical and virtual). If the physical size of the index volume is larger than 2 - 3 GB, then the entire index volume cannot be loaded into memory and must be swapped out. This swapping can cause issues with the search, which can throw the error you received.
If you have more than 10 or so index volumes for the archive, then you can use the volume number referenced to find the actual physical index volume folder.
Look in the CA customer database for the table tblIndexVolumeSet. Look in the right-most column of this table for the volume number (328). Look in the row that contains that volume number for the column named FirstIndexSequenceNumber. This is the number at the beginning of the numbers shown for each index volume in the archive's properties. Note the physical path for that volume and use Windows Explorer to access that path. Then take that FirstIndexSequenceNumber and add it with an underscore to the end of the ArchiveID to find the physical folder in that location.
For example, you have ArchiveID 1C8A2E6A8DBEC064D9A1B2F03A7D5286D1110000journalingJrn shown in your posts. Let's presume the FirstIndexSequenceNumber of Volume 328 is 153982. Putting these together would give you the folder name of 1C8A2E6A8DBEC064D9A1B2F03A7D5286D1110000journalingJrn_153982.
One of the things we've found to help releave the error you received is to perform a major compaction of the index volume. To do that, create an empty file named Compact.task in the physical folder, then run the 'Update Index Volume' action through the Vault Admin Console (right click on the index volume and selec this option). Note that no search can be run against the archive by CA while the major compaction is running. The EV Event Log should provide informational events to let you know the update has started and completed. Once the completion event is thrown, the archive can be searched by CA.
Now, the complexity of the search terms may need to be broken into multiple searches. If the search terms have lots of wild cards, then the complexity can easily exceed the available resources for the index volume in memory. Remember that the search criteria must also fit into the 2 GB memory limitation of the IndexServer process, so the more complex the search criteria, the less memory available to the actual index data at any given time.
The ultimate 'fix' to the error would be to rebuild the index volume with the AVSMaxLoc registry setting configured with the value 500000000 (500 million decimal). This value will keep the physical index volume folder size to between 2 and 3 GB. We don't recommend rebuilding an index volume unless it's the last thing to do to resolve an issue as this operation can take a long time, especially if you're rebuilding multiple index volumes for the same archive.
I hope this helps you resolve the issue.
TonySterling
