Unsolved
This post is more than 5 years old
27 Posts
0
1631
March 29th, 2012 03:00
SourceOne Search Performance - tips!
Other than throwing hardware at the S1 servers and storage which I have done (cannot think of anything else I can upgrade/replace to make faster other than putting indexes on SSD disks) what tweaking tips do you all have for making searches run as fast as possible. I have my index drives defragging once a week and have memory allocated to search set at max of 500MB. My DBAs spend some time working on the SQL server and have it tweaked as much as possible to help increase its performance.
Has anyone out there really made the system run really quickly for searches? Specificlly searches that use the indexes as these just appear maginally faster that the legacy Emailxtender searches.
Thanks!
Gary_Reardon
2 Intern
•
272 Posts
0
March 29th, 2012 11:00
Storage performance is really the key factor here and the #1 bottleneck I run into.
What does you index storage look like today?
How many IOPS is Index storage capable of delivering?
Is it exclusive to this purpose or shared storage?
Throwing more spindles at it is usually the answer unless you've gotten past the point of the storage I/O being the bottleneck.
damibu
27 Posts
0
April 4th, 2012 11:00
When creating an archive you can specify multiple index locations and it seems that the system will split the indexes between the two locations. Will spreading my indexes over several logical drives help with search performance and can I split this up after the fact?
The archive I have most performance issues has an index size of over 600GB for email from 2003 to 2010. Can I now after the fact break this up to 4 x 150GB chunks on 4 separate drives?
broy_ici
18 Posts
0
April 4th, 2012 12:00
This following onto my colleague Gary's comments. Storage is the key factor on on the performance of the searches. What RAID configuration are the indexes on? Indexes should be on a RAID 1+0 as this will maximize performance and redundancy. What type of disks are they? They should be a minimum of 15k speed if you want good performance. You also want to run the maintenance scripts provided by EMC with the SourceOne download. The ES1Archive and ES1Search database indexes can become severely fragmented which will also cause performance delays. Chapter 13 of the SourceOne Admin Guide covers SQL database maintenance. I hope this helps.
damibu
27 Posts
0
April 4th, 2012 12:00
Thanks Broy_ici
I have everything in your post taken into account! As said the only thing I have not done is put the indexes on SSD disks which I am sure will help but not something I want to do. I really think if I can spead this specific index over multiple logical drives it will help so searches are over multiple concurrent disk i/o threads. Question now is can I break up my indexes after the fact over multiple locations.
tmrskos
3 Posts
0
May 10th, 2012 07:00
I've moved indexes with the assistance of support before on 6.6 SP1. The key factor is having everything processed, shutdown during the moves, and keeping the directory structure. Here's what we did:
With the system up, create new index storage locations and let it populate with new data
Stop all archive jobs and let indexing completely finish
Shutdown servers accessing your indexes
Move your existing indexes to the new location, keeping the same directory structure
\\Server1\IndexShare\Archive1\201203\002 gets moved to \\Server2\IndexShare\Archive1\201203\002
This works becuase the indexer does not store what volume sets reside where (down to the 002 level). I would test your version/environment and also get the blessing from support before doing this.