Note that this can require substantial temporary free space in the Directory (see LUCENE-764 for details):
If no readers/searchers are open against the index, then free space required is up to 1X the total size of the starting index. For example, if the starting index is 10 GB, then you must have up to 10 GB of free space before calling optimize.
If readers/searchers are using the index, then free space required is up to 2X the size of the starting index. This is because in addition to the 1X used by optimize, the original 1X of the starting index is still consuming space in the Directory as the readers are holding the segments files open. Even on Unix, where it will appear as if the files are gone ("ls" won't list them), they still consume storage due to "delete on last close" semantics.
Furthermore, if some but not all readers re-open while the optimize is underway, this will cause > 2X temporary space to be consumed as those new readers will then hold open the partially optimized segments at that time. It is best not to re-open readers while optimize is running.
The actual temporary usage could be much less than these figures (it depends on many factors).
In general, once the optimize completes, the total size of the index will be less than the size of the starting index. It could be quite a bit smaller (if there were many pending deletes) or just slightly smaller.
If an Exception is hit during optimize(), for example due to disk full, the index will not be corrupt and no documents will have been lost. However, it may have been partially optimized (some segments were merged but not all), and it's possible that one of the segments in the index will be in non-compound format even when using compound file format. This will occur when the Exception is hit during conversion of the segment into compound format.
This call will optimize those segments present in the index when the call started. If other threads are still adding documents and flushing segments, those newly created segments will not be optimized unless you call optimize again.
@throws CorruptIndexException if the index is corrupt @throws IOException if there is a low-level IO error | |