Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

EV 10.0.4 FSA Indexing consuming lots of disk space

Created: 02 Apr 2014 • Updated: 02 May 2014 | 7 comments
This issue has been solved. See solution.

After upgrading to 10.0.4 CHF2, I have a particular subdirectory to a share (90GB in size) that had an EV FSA index of 800GB .  I have tried rebuilding it, and it is now at 600GB and growing.   Anyone else see a filesystem index grow insanely after upgrading, and do you have any suggestions?

This has been going on for almost 2 months, and I do have a ticket open.  But today I had to shutdown the indexing service as it eats up all the memory on the box.  So the situation is getting worse.

2 - dual core, 24 MB physical host.

 

Thanks,

Linda

Operating Systems:

Comments 7 CommentsJump to latest comment

plaudone's picture

What type of data is being archived from the source location?  Office docs, compressed files, images?

Also, the recommended number of cores is 8 on the EV server with EV 10 indexing.  Should not be cause of issue here, but may affect performance. 

 

lindaloo3's picture

Still reviewing the filesystems, but mostly looks like gz, pdf and data files.   Someone had told me pgp files can cause issues but I haven't seen any yet.

plaudone's picture

It could be possible that the gz files are causing an issue.  PGP files can cause issues as well with the wilcard dictionary file.  How large is the log.sqlt file in the live folder of the index volume?  

lindaloo3's picture

The log.sqlt file is 148GB  right now.   There are a ton of gzip files and I found two *.gpg encrypted files.  There was a wide array of filetypes under one subdirectory.  Maybe I work on cleaning up the *.gpg files, and see how it goes.

plaudone's picture

You may want to add .gz and .gpg (is that correct) not pgp, to the registry to be excluded from conversion?  

http://www.symantec.com/docs/TECH62810 

SOLUTION
lindaloo3's picture

So still not sure what is wrong with this filesystem but it is large over 3TB archived.  I think prior to upgrading to 10.0.4 the indexing was broken.  In any case, my fix was to make the source read-only and stop archiving this particular filesystem after talking to the users of it.

But thanks for the tips on excluding filesystem types, I did implement that as that seemed like a good idea.

 

Linda