Reloading an index
I have an index that is frequently updated. When indexing is completed, an event triggers a new Searcher to be opened. When the new Searcher is opened, incoming searches are redirected to the new Searcher, the old Searcher is closed and nulled, but I still see about twice the amount of memory in use well after the original searcher has been closed. Is there something else I can do to get this memory reclaimed? Should I explicitly call garbarge collection? Any ideas? Thanks. Greg Gershman __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reloading an index
Make sure that the older searcher is not referenced elsewhere otherwise the garbage collector should delete it. Just remember that the Garbage collector runs when memory is needed but not immediatly after changing a reference to null. -Message d'origine- De : Greg Gershman [mailto:[EMAIL PROTECTED] Envoyé : jeudi 27 janvier 2005 17:29 À : lucene-user@jakarta.apache.org Objet : Reloading an index I have an index that is frequently updated. When indexing is completed, an event triggers a new Searcher to be opened. When the new Searcher is opened, incoming searches are redirected to the new Searcher, the old Searcher is closed and nulled, but I still see about twice the amount of memory in use well after the original searcher has been closed. Is there something else I can do to get this memory reclaimed? Should I explicitly call garbarge collection? Any ideas? Thanks. Greg Gershman __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reloading an index
I just ran into a similar issue. When you close an IndexSearcher, it doesn't necessarily close the underlying IndexReader. It depends which constructor you used to create the IndexSearcher. See the constructors javadocs or source for the details. In my case, we were updating and optimizing the index from another process, and reopening IndexSearchers. We would eventually run out of disk space because it was leaving open file handles to deleted files, so the disk space was never being made available, until the JVM processes ended. If you're under linux, try running the 'lsof' command to see if there are any handles to files marked (deleted). -Chris On Thu, 27 Jan 2005 08:28:30 -0800 (PST), Greg Gershman [EMAIL PROTECTED] wrote: I have an index that is frequently updated. When indexing is completed, an event triggers a new Searcher to be opened. When the new Searcher is opened, incoming searches are redirected to the new Searcher, the old Searcher is closed and nulled, but I still see about twice the amount of memory in use well after the original searcher has been closed. Is there something else I can do to get this memory reclaimed? Should I explicitly call garbarge collection? Any ideas? Thanks. Greg Gershman __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reloading an index
: processes ended. If you're under linux, try running the 'lsof' : command to see if there are any handles to files marked (deleted). : Searcher, the old Searcher is closed and nulled, but I : still see about twice the amount of memory in use well : after the original searcher has been closed. Is : there something else I can do to get this memory : reclaimed? Should I explicitly call garbarge : collection? Any ideas? In addition to the previous advice, keep in mind that depending on the implimentation of your JVM, it may never actually free memory back to the OS. And even the JVMs that can, only do it after a GC which results in a ratio of unused/used memory that they deem worthy of freeing (usually based on tunning parameters) assuming you are using a Sun JVM, take a look at... http://java.sun.com/docs/hotspot/gc1.4.2/index.html ...and search for MinHeapFreeRatio and MaxHeapFreeRatio -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
