A merge requires reading 100% of two or more segments, and writing all the non-deleted docs into a brand-new segment. So generally, a whole bunch of sequential reads and writes.
This Mike McCandless post from 2011 has lovely visualizations of merge behavior, plus some info about the number of writes needed. http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html wunder On Mar 26, 2014, at 9:29 AM, Otis Gospodnetic <otis.gospodne...@gmail.com> wrote: > Lucene segment merges cause both reads and writes. If you look at SPM, > you'll see the number of index files and the number of segments, which will > give you an idea what's going on at that level. > > Otis > -- > Performance Monitoring * Log Analytics * Search Analytics > Solr & Elasticsearch Support * http://sematext.com/ > > > On Tue, Mar 25, 2014 at 8:12 PM, Software Dev > <static.void....@gmail.com>wrote: > >> What are the main contributing factors for Solr Cloud generating a lot >> of disk IO? >> >> A lot of reads? Writes? Insufficient RAM? >> >> I would think if there was enough disk cache available for the whole >> index there would be little to no disk IO. >> -- Walter Underwood wun...@wunderwood.org
