Es circuit breaker, the JVM heap memory is not enough to load data for the current query, so it will report data too large, and the request is blown.

1、 Cause of occurrence

There are too many batch import data or too many query data, which is more frequent  

When the cluster status is yellow or red, analyze the reason:

GET _ cluster/allocation/explain

2、 Periodically clean up the cache

The regular memory cleaning can not ensure the availability of the server. However, if the memory is not enough, the ES can increase the availability of the service.

Although the query may be slow, it is much better than directly reporting an error, unable to query and unsuccessful data saving

1. Clean cache method

delete   data acquisition   Indexes   Cache:   POST  / collect_ data*/_ cache/clear

monitor   Field cache: get  /_ stats/fielddata?fields=*

2. Restart cluster node

If the cleanup cache is invalid_ Cache/clear, then restart.

If it occurs frequently    The data too large is abnormal. I think it can be reduced again    indices.fielddata.cache.size   This setting. Let it clean up the cache as soon as possible.

Increase at the same time   The available memory of ES, and the limit size corresponding to the available memory: i.e   indices.breaker..limit

Through monitoring, find the cause of the problem: get  /_ cluster/stats?pretty

3、 Optimize query

1. Increase server memory and ES cluster

When there is too much index data and the server memory is too small, even if the cache is cleaned regularly, the  _ In cache/clear, there is still an exception that triggers the fuse. At this time, we can only consider upgrading the memory and expanding the ES cluster.

2. Avoid using   Index name*

This method is similar to select * from table

For example, I generate an index every year or every month   user_ 2020, and user_ two thousand and nineteen

When querying, I use the index as follows:   user*   This will definitely affect the query performance,

If a complex aggregation statement, es will aggregate all indexes beginning with user, which must occupy a lot of memory.

At this time, you can consider whether it is the query statement usage of ES?Check and optimize

More tuning References:    https://blog.csdn.net/andy_ only/article/details/98172044

3. JVM configuration uses G1 garbage collector