On Tue, Apr 14, 2015 at 7:36 AM, Hajime <[email protected]> wrote:
> Possibly it is IO bound but I don't seem too many io wait on Cpu or write > activity on iostat.By the way,uses ssd and xfs as file system and default > Directory ( I think it becomes MMapDirectory). > Local SSD (not e.g. Amazon's EBS backed by SSD)? Is this dedicated hardware or virtual? Dedicated is better. > > each single bulk request to one index is done concurrently 5X so you > only need enough concurrent bulk requests to saturate the number of CPUs > I suppose that IndexWriter will lock at some point but will this strategy > work on the same index? > Yes, for one index ES creates 5 shards by default, so a single bulk request indexing N docs will effectively use 5 CPUs assuming docs are routed evenly. > However,setting *index.merge.async_interval* higher than default "1s" > seems better for the huge indexing (I'm still using 1.4.0).I found that it > was removed from recent release of 1.5.0.Do you know why?Will I see > better indexing performance just simply upgrade to >=1.5.0? > Please don't change that setting: it's a bad idea. By increasing it, you are delaying when Lucene gets a chance to kick off segment merging. I would recommend upgrading. Mike McCandless -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKHUQPgJ5Tt3cXX5O_F7JEr3XqAhaNSfb7x9QWoX5q8d4Z_PUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
