Hello Ankit,
In case2, I assume you have slower query performance coming from 2
directions:
- indexing creates additional load
- indexing triggers merges, which invalidate caches
If there's a lot of load generated by indexing, I don't see a good option
to fix the issue, other than adding more/bigger nodes. Maybe increase the
refresh_interval. Also, 240 total shards sounds a little too much for 10
nodes.
If your indexing is relatively light, you might counter the cache
invalidation effect by using
warmershttp://www.elasticsearch.org/guide/reference/api/admin-indices-warmers/
.
Best regards,
Radu
http://sematext.com/ -- Elasticsearch -- Solr -- Lucene
On Fri, Apr 26, 2013 at 11:06 AM, Ankit Jain ankitjaincs06@gmail.comwrote:
Hi All,
We have setup 10 nodes ES cluster each has (16 cores and 32 GB RAM and 2
disk). We are using separate disk for each node.
We have around 24 indices (10 shards each), size of index is 10 GB.
Case1:
We are able to fetch 10000 records in 9 secs if indexing is not running in
parallel with query.
Case2:
When both indexing and query are running in parallel, then same query
takes 70 secs.
Thanks,
Ankit Jain
iLabs
--
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 elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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 elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.