When we execute batch execution, if the primary shard is indexed, we are increasing the replica shard at that time, But at that time, the search engine creates replica shards, and as you can see from the metrix, a large amount of data is indexed, so the segment count rises rapidly.
So merge, flush, refresh spike...
@warkolm
once again
Our batch job increments the replica shard when the index on the primary shard is complete, but then the problem is that the replica shard is created too quickly.
Even if the time zone of the image above and the image below are different, the problem is the same, so you can ignore the time zone
Sorry, it's really not clear to me where this timeout you reference is coming from, nor what the problem you are seeing is. I understand you are showing us some graphs, but there's no context as to why you think these are causing issues, and where those issues are showing up.
@warkolm
Readtimeout occurs every time the i/o operation is high.
The reason why the i/o operation is high is when creating a replica shard...
When creating a replica shard, merge, refresh, and flush all increase, which causes readtimeout.
There are spikes in activity and other things, but if you are increasing replicas then that is to be expected.
However none of what you have provided shows a timeout.
So, where is this "search readtimeout" coming from if it's not in any of the metrics you have?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.