Limiting the index volume folder size

[Chris_Scott_3]

I am initerested in limiting the folder size. There have been discussions about using a registery key call "AVSMaxloc". Where in the registery is this key located? Is this a new key? Are there some best practice rules In sizing this value?

[Lee_Allison]

Chris, MaxLoc will determine how large the index can get before a new index is spawned off. When you're dealing with journaling archives the index can get too large for the Alta Vista engine to handle. When the index approaches the number in the registry you should see EV spawn a new archive, and with it a new index.

[TonySterling]

That is almost correct, but not quite. EV 6 sp1 and above uses IndexVolumes, so a new index folder will be created, but not a new archive.

[Chris_Scott_3]

Thank you, this sounds like what I am trying to accomplish. Is this a new key that has to be added? Where is the key found in the registery?

[TonySterling]

You will add it here.


AVSMaxLoc DWORD to 500,000,000

[Chris_Scott_3]

One last question, is this limit value in bytes or item count?

[TonySterling]

I forgot to mention to restart Indexing after setting the key.

What is does is limit the number of locations for an index. A location can be described as the numeric count of the position of the term within the document within the index.

Not the easiest thing to describe with a whiteboard, 30 minutes of time, and a few beers! :)

[Lee_Allison]

Beers? Sweet!

Oh, Tony, tell Jacob I still haven't forgotten about those beers he owes me, lol.

[Chris_Scott_3]

Is there a way to check the size of an existing index to compare them to the limit that AVSMaxLoc would impose? If they exceed this limit currently, could you forcae a rebuild of each index once the AVSMaxLoc setting has been applied to increase their performance?

[Michael_Bilsbor]

using
IndexServer/Summary on the index will show you current number of words in the index.

yes if you rebuild indexes after setting this key then it will make the new indexes smaller.

Why do you want to set this? What problem are you trying to solve.

Depending upon how you are using EV (e.g. end user or CA/DA type searches) there are different ways to improve performance.

[Michael_Bilsbor]

using
IndexServer/Summary on the index will show you current number of words in the index.

yes if you rebuild indexes after setting this key then it will make the new indexes smaller.

Why do you want to set this? What problem are you trying to solve.

Depending upon how you are using EV (e.g. end user or CA/DA type searches) there are different ways to improve performance.

[Michael_Bilsbor]

using
IndexServer/Summary on the index will show you current number of words in the index.

yes if you rebuild indexes after setting this key then it will make the new indexes smaller.

Why do you want to set this? What problem are you trying to solve.

Depending upon how you are using EV (e.g. end user or CA/DA type searches) there are different ways to improve performance.

[Michael_Bilsbor]

Hi,

If you set AVSMaxLoc and rebuild the indexes then yes they will be limited to the new size.

Why are you doing this? What problem are you trying to solve?
How are you using EV searches. Is this end user or CA/DA type searches?

[Chris_Scott_3]

The Indexes that I have today have grown very large quickly since our implentation. We have seen a number of corrupt indexes and the rebuild time is getting longer and longer as time goes on. One of them took 5 days to rebuild. So, by setting a limit on the index size the hope would be to make this quicker as well as increase the performance and managebility.

Half of our indexes are used for CA/DA and the other half is for the Archive users

[Michael_Bilsbor]

Hi Chris,

So why are you indexes becoming corrupted is the question to anser.
There are some tech notes on support.veritas.com which now talk about common causes of corruption so you can help yourself by trying to reduce some of the causes.

Also, is there a reason why you're not backing up the indexes?

[Micah_Wyenn]

Chris,
The only time I've seen index corruption is when OpLocks were enabled when the index was on a Netapp (or nfs like) device. Check to see if that's the case...maybe that's the root of your problem?

micah

[Chris_Scott_3]

The reason that some of the indexes are becoming corrupt is still an unknown. I have followed a few threads discussing this subject. Virus scanning has been ruled out due to the entire drive hosting the indexes being excluded. We don't use NetApp for storage of our archives, we use Centerra.

The indexes are being backed up nightly during a scripted read-only mode session. A script runs to put all EV servers in read-only mode restarting services. Following this is a SQL backup of all EV databases. The Indexes are backed up by centralized Legato system on a timed basis. With that being said, there is definitely a possibility that the indexes are being backed up while the EV server is in write mode. Could this be a problem?

In the event of an index corruption, is it possible to restore the index from backup instead of rebuilding? If so how would that be done without loosing data when it is backed up only once a day?

Sorry for the long winded response. :)

[Lee_Allison]

Chris, check these two articles:

http://seer.support.veritas.com/docs/280895.htm

http://seer.support.veritas.com/docs/280922.htm

Might help some.

[TonySterling]

The MS kb referenced from the tech note has to keys. You want to set

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters OplocksDisabled REG_DWORD 1

On your EV servers. This keeps the lock from being requested from the ev server.

If your index is corrupt and you restore a good back up of it, one with an avtrace.log file that is 0kb, using the IndexReplay tool you can choose to update it as opposed to rebuild. That way it just has to add new additions and not start from scratch.

cheers,

[Lee_Allison]

Tony if the old backup of the index files are restored EV should update on it's own without any prompting from the admins. Has there been a change to that section of code to prevent this?