Re: Lucene Indexing out of memory

Erick, I did get some hint for my problem. There was a bug in the code which was eating up the memory which I figured out after lot of effort. Thanks All of you for your suggestions. But I still feel it takes lot of time to index documents. Its taking around an hour or more for indexing 330 MB f

Re: Lucene Indexing out of memory

Hi Michale and others, I did get some hint for my problem. There was a bug in the code which was eating up the memory which I figured out after lot of effort. Thanks All of you for your suggestions. Regards Ajay Michael McCandless-2 wrote: > > I agree, memory profiler or heap dump or small

Re: 答复: about lucene in action 2

sync (fsync to the OS) tells the OS to make sure everything associated with that file is moved to stable storage in the IO system. (It doesn't read anything back). On flush we write the files to disk, which is usually very fast since it writes into the OS's RAM write cache, but we do not sync. s

答复: about lucene in action 2

Thanks very much for your patience! Nor are the files "sync"'d.?It means something like reading disk file to RAM,so reader can see it? And why flushing(reopen) is much faster than commit? flushing means writing stuff to disk, commit means writing stuff to disk and then reading the new created di

Re: about lucene in action 2

Flushing means stuff (added docs, deletions) buffered in RAM are moved to disk, ie, written as new segment files. But the new segments_N file, referencing these new segments, is not written. Nor are the files "sync"'d. This means a newly opened or reopened reader will not see the changes. In or