Switch back to ConcurrentMergeScheduler as the default #5817
Labels
Comments
|
++ |
s1monw
added a commit
to s1monw/elasticsearch
that referenced
this issue
Apr 15, 2014
Load tests showed that SerialMS has problems to keep up with the merges under high load. We should switch back to CMS until we have a better story to balance merge threads / efforts across shards on a single node. Closes elastic#5817
s1monw
added a commit
that referenced
this issue
Apr 15, 2014
Load tests showed that SerialMS has problems to keep up with the merges under high load. We should switch back to CMS until we have a better story to balance merge threads / efforts across shards on a single node. Closes #5817
s1monw
added a commit
that referenced
this issue
Apr 15, 2014
Load tests showed that SerialMS has problems to keep up with the merges under high load. We should switch back to CMS until we have a better story to balance merge threads / efforts across shards on a single node. Closes #5817
jpountz
added a commit
that referenced
this issue
Apr 2, 2015
1.1.0 is affected by #5817 which prevents merges from keeping up with the indexing rate. As a consequence it generates lots of segments and makes bw compat tests slow. So I added a special case for this version to index fewer documents.
mute
pushed a commit
to mute/elasticsearch
that referenced
this issue
Jul 29, 2015
Load tests showed that SerialMS has problems to keep up with the merges under high load. We should switch back to CMS until we have a better story to balance merge threads / efforts across shards on a single node. Closes elastic#5817
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Load tests showed that
SerialMShas problems to keep up with the merges under high load. We should switch back toCMSuntil we have a better story to balance merge threads / efforts across shards on a single node.The text was updated successfully, but these errors were encountered: