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.
Solved! Go to Solution.
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.
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?
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.
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.