# GC occurred in the Elasticsearch cluster

**URL:** <https://discuss.elastic.co/t/gc-occurred-in-the-elasticsearch-cluster/390606>\
**Category:** Elastic Search\
**Created:** [September 23, 2026, 12:30pm UTC](https://discuss.elastic.co/t/gc-occurred-in-the-elasticsearch-cluster/390606 "2026-09-23T12:30:35Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Siva\_Karan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/siva_karan/32/54688_2.png) [@Siva\_Karan](https://discuss.elastic.co/u/Siva_Karan)\
**Post date:** [September 23, 2026, 12:30pm UTC](https://discuss.elastic.co/t/gc-occurred-in-the-elasticsearch-cluster/390606/1 "2026-09-23T12:30:35Z")

</div>

Hi Team,

[2026-09-22T22:20:13,448][WARN][o.e.m.j.JvmGcMonitorService] [node2] [gc][435482] overhead, spent [4s] collecting in the last [4.6s].

we are faced the GC issue with low heap usage and also we are unable to access the cluster, there is no slowlogs and No abnormal in our cluster

we are using 7.17.x this is our configuration and we are using CMS GC,may i know the reason  
````  
cluster.name: cluster3  
node.name: node3  
network.host: ip  
http.port: 9201  
transport.port: 9301  
path.logs: /u01/elasticsearch/logs/es717/${cluster.name}/${node.name}  
path.data: /u01/elasticsearch/ESEARCH\_DATA/${cluster.name}/${node.name}  
http.max\_content\_length: 300mb  
discovery.seed\_providers: file  
cluster.initial\_master\_nodes: node1, node2, node3  
xpack.security.enabled: true  
xpack.security.transport.ssl.enabled: true  
xpack.security.transport.ssl.verification\_mode: certificate  
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12  
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12  
indices.memory.index\_buffer\_size: 20%  
indices.fielddata.cache.size: 30%  
indices.breaker.fielddata.limit: 20%  
indices.recovery.max\_bytes\_per\_sec: 25mb  
indices.breaker.total.use\_real\_memory: true  
bootstrap.memory\_lock: true  
action.destructive\_requires\_name: true  
node.roles: [data]  
cluster.remote.connect: false  
gateway.expected\_nodes: 6  
cluster.routing.allocation.disk.threshold\_enabled: false

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/9/3/9324cb10a0bf0e705d85209f8eba112d1775a3dd.jpeg)

---

<div class="post-metadata">

**Author:** ![Tortoise](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/tortoise/32/147587_2.png) [@Tortoise](https://discuss.elastic.co/u/Tortoise)\
**Post date:** [September 28, 2026, 12:00pm UTC](https://discuss.elastic.co/t/gc-occurred-in-the-elasticsearch-cluster/390606/2 "2026-09-28T12:00:23Z")

</div>

Hello @Siva_Karan

The settings and the heap graph alone aren't enough to pinpoint the root cause. The graph shows heap staying below ~46% on all nodes, so this doesn't look like heap pressure. A node spending 4s of 4.6s in GC with low heap usually means the JVM was stalled by the host (swap, CPU contention if several ES nodes share a machine or VM steal time) rather than by garbage.

Could you share:

- Elasticsearch logs from all nodes for that window, especially the elected master
- node2's `elasticsearch.yml` and which nodes are master-eligible (_GET \_cat/nodes?v&h=name,node.role,master,heap.percent,ram.percent_)

7.17 no longer receives fixes, so it's worth planning an upgrade to 9.x

Thanks!!