On Wednesday, May 1, 2002, at 10:16 PM, Dmitry Serebrennikov wrote: > "Less then a hundred" is definetely too many files for a Lucene index, > unless you have a very large number of stored fields!
Since changing indexing strategy, I have between 12 to 20 files per index (including deletable and segments). > An optimized index should have about a dozen. That what I see for small objects (eg with few fields). > So this either means that you have many stored fields My "richest" object has around a dozen fields. > or you are not calling optimize, or that, if you are, there are > unclosed IndexReader instances floating around that are still using > segments that existed before the optimization (which replaces all > segments with one new one). I guess I have this part under control now. > About file names: Thanks for the explanation :-) I mostly have <n>.f<m> type files as one may expect. > An index should have 2 + n * (7 + m) files, where n is the number of > segments and m is the number of stored fields. For an optimized index > with one stored field this gives 10 files (not a 100!). It seems that I'm getting there... ;-) > So, unless IndexReaders are closed explicitly, this might explain why > an application runs fine under Windows, but has problems under OSX, or > whatever. I decided to be much more "aggressive" with all the file handles... But I still rely heavely on the garbage collector as I'm using the reference api extensively... Seems to work fine so far... > I agree that a desktop application should not require changes to system > configuration, but it might resonably expect a default value to be > present and it might change the soft limit (which is usually set very > low) in the startup script. So far, my app seems to be doing fine without having to mess around with any system parameters... Also, it seems to be more responsive since I have more indexes... Go figure ;-) > Good luck. Thanks. PA. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
