# Kibana memory consumption growing linearly until it crashes

**URL:** <https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618>\
**Category:** Kibana\
**Created:** [November 24, 2025, 1:21pm UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618 "2025-11-24T13:21:56Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Fabio\_Hecht](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fabio_hecht/32/145873_2.png) [@Fabio\_Hecht](https://discuss.elastic.co/u/Fabio_Hecht)\
**Post date:** [November 24, 2025, 1:21pm UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/1 "2025-11-24T13:21:56Z")

</div>

Hi there! I have an issue with a simple Elastic / Kibana deployment on OpenShift. Even with no data being ingested in Elastic and virtually no users (just me testing), Kibana’s memory consumption grows linearly until the container is OOM Killed. My configuration is quite minimalist and I use the official containers version 9.1.4. I have one Elastic pod and one Kibana pod.

This is what I tried so far:

- Give the container more memory. I tried from 2 GiB up to 6 GiB but it just keeps taking up memory until it crashes, it never seems to stop.
- Set NODE\_OPTIONS with `--max-old-space-size=1024`, also tried 2048, 512.
- Disabled some plugins and features:

```auto
telemetry.enabled: false
xpack.reporting.enabled: false
xpack.canvas.enabled: false
xpack.fleet.enabled: false
xpack.indicesMetadata.enabled: false
xpack.screenshotting.enabled: false

```

The logs don’t show anything that I find interesting.

Using the `/api/status` endpoint, I can see that the heap usage is constant, but `resident_set_size_in_bytes` keeps growing very fast.

```auto
λ oc exec -it deploy/kibana -- curl -k https://localhost:5601/api/status -k |jq .metrics.process.memory; date
{
  "heap": {
    "total_in_bytes": 396181504,
    "used_in_bytes": 379005328,
    "size_limit": 562036736
  },
  "resident_set_size_in_bytes": 706420736,
  "array_buffers_in_bytes": 492831,
  "external_in_bytes": 4514730
}
Mon Nov 24 13:38:06 2025
λ oc exec -it deploy/kibana -- curl -k https://localhost:5601/api/status -k |jq .metrics.process.memory; date
{
  "heap": {
    "total_in_bytes": 408502272,
    "used_in_bytes": 388229616,
    "size_limit": 562036736
  },
  "resident_set_size_in_bytes": 808656896,
  "array_buffers_in_bytes": 566169,
  "external_in_bytes": 4588012
}
Mon Nov 24 13:45:15 2025
λ oc exec -it deploy/kibana -- curl -k https://localhost:5601/api/status -k |jq .metrics.process.memory; date
{
  "heap": {
    "total_in_bytes": 413745152,
    "used_in_bytes": 397290256,
    "size_limit": 562036736
  },
  "resident_set_size_in_bytes": 901521408,
  "array_buffers_in_bytes": 638061,
  "external_in_bytes": 4659680
}
Mon Nov 24 13:52:15 2025
λ oc exec -it deploy/kibana -- curl -k https://localhost:5601/api/status -k |jq .metrics.process.memory; date
{
  "heap": {
    "total_in_bytes": 447463424,
    "used_in_bytes": 430677584,
    "size_limit": 562036736
  },
  "resident_set_size_in_bytes": 1174245376,
  "array_buffers_in_bytes": 846778,
  "external_in_bytes": 4868845
}
Mon Nov 24 14:11:28 2025

```

I would appreciate any pointers towards investigating the root cause of this issue.

Cheers,

Fabio

---

<div class="post-metadata">

**Author:** ![Fabio\_Hecht](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fabio_hecht/32/145873_2.png) [@Fabio\_Hecht](https://discuss.elastic.co/u/Fabio_Hecht)\
**Post date:** [December 1, 2025, 10:57am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/2 "2025-12-01T10:57:43Z")

</div>

So far I could observe the following:

1. Kibana memory allocation growing linearly until container crashed (OOMKilled).
2. Heap dump shows large retention of the following objects: ServerHttp2Session, Http2Session, TLSSocket, TLSWrap.
3. When OpenShift route is deleted, then memory allocation stops increasing. When OpenShift route is recreated, then memory allocation grows again until container crashed. It does not matter if the route is being actively invoked.
4. Looking at `/proc/net/tcp` I don’t see stale connections, it seems the connections get closed properly, but the sessions are not properly purged from memory.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 1, 2025, 11:18am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/3 "2025-12-01T11:18:55Z")

</div>

Welcome to the forum. And sorry that no-one answered your post first time.

> [@Fabio\_Hecht](#):
>
> it **seems** the connections get closed properly

Did you double check with eg tcpdump ?

Before it crashes, is Kibana operable and properly connected to elasticsearch ? any interesting logs from elasticsearch side ?

---

<div class="post-metadata">

**Author:** ![Fabio\_Hecht](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fabio_hecht/32/145873_2.png) [@Fabio\_Hecht](https://discuss.elastic.co/u/Fabio_Hecht)\
**Post date:** [December 2, 2025, 10:12am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/4 "2025-12-02T10:12:42Z")

</div>

Hey, thanks for having a look.

So far I could confirm the following facts.

The memory leak only happens when TLS is enabled for the Kibana server and the OpenShift router is enabled. The router performs 4 health checks per second (2 routers, every 500ms) by establishing a TCP connection and terminating it. It’s an HA Proxy with `check inter 500`. When that happens, I see the memory consumption going up until container crashes.

When memory leak does not happen:

- Kibana service with TLS enabled and no OpenShift route.
- Kibana service with TLS disabled, with or without OpenShift route (`termination: edge`).
- Kibana service with TLS enabled but with `server.protocol: http1` .

For now, we’ll go with `server.protocol: http1`. But you may want to have a look at why the ServerHttp2Session are never getting released in this case.

Unfortunately, I’m not able to attach images here, I always get an error message.

Cheers,

Fabio

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 2, 2025, 1:34pm UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/5 "2025-12-02T13:34:49Z")

</div>

Can you share the haproxy config please?

---

<div class="post-metadata">

**Author:** ![Fabio\_Hecht](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fabio_hecht/32/145873_2.png) [@Fabio\_Hecht](https://discuss.elastic.co/u/Fabio_Hecht)\
**Post date:** [December 3, 2025, 8:13am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/6 "2025-12-03T08:13:28Z")

</div>

the team responsible for the openshift cluster informed me that `check inter 500` is the relevant part, haproxy is therefore making the connections

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 3, 2025, 10:05am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/7 "2025-12-03T10:05:59Z")

</div>

> [@Fabio\_Hecht](#):
>
> the team responsible for the openshift cluster informed me that `check inter 500` is the relevant part, haproxy is therefore making the connections

Respectfully, that’s not helpful.

If I were flippant, I’d say “ask the team responsible for the openshift cluster” to figure it out then 🙂

More seriously, on the face of it you _could_ have uncovered a kibana bug. That would be useful to confirm/find/fix. Kibana should not leak memory, certainly not to point of OOM. But, if I’ve understood correctly, the leak only happens with haproxy in a TLS-enabled flow, and seems related to the checks performed every 500ms, right? What’s performing those checks, and how is it configured? The answer is haproxy, and the configuration is, IMO, more than just `check inter 500`. I also suggested you _validate_ that the connections are correctly closed with tcpdump. Did you do that?

EDIT: Not sure if it helps, but enable the debugger by sending SIGUSR1 to the node process with kill, which will log something like:

Debugger listening on ws://127.0.0.1:9229/b818ce57-315e-4110-bd83-9b72a17fc3d1

You can then attach with (eg) Chrome DevTools and monitor the creation/deletion of sockets, sessions, etc.

---

<div class="post-metadata">

**Author:** ![Fabio\_Hecht](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fabio_hecht/32/145873_2.png) [@Fabio\_Hecht](https://discuss.elastic.co/u/Fabio_Hecht)\
**Post date:** [December 4, 2025, 7:28am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/8 "2025-12-04T07:28:20Z")

</div>

I’m in a corporate environment where things are not so simple. They claim they use this configuration for many services since many years and no one ever complained, so the problem must be at Kibana. So far I have no arguments to disagree with them.

I don’t have permissions to tcpdump or port forward or anything else that requires privileged acccess, but I can look at /proc/net/tcp, where I can see:

```auto
sh-5.1$ cat /proc/net/tcp
  sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
   0: 00000000:15E1 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1000850000 0 350421419 1 0000000000000000 100 0 0 10 0
   1: 980213AC:A8DA A20111AC:23F0 01 00000000:00000000 02:00000012 00000000 1000850000 0 417975169 2 0000000000000000 20 4 28 10 -1
   2: 980213AC:A962 A20111AC:23F0 01 00000000:00000000 02:00000012 00000000 1000850000 0 350421457 2 0000000000000000 20 4 30 10 -1
   3: 980213AC:D6B0 A20111AC:23F0 01 00000000:00000000 02:0000004B 00000000 1000850000 0 418617447 3 0000000000000000 20 4 30 10 -1

```

The relevant part being the line with local\_address 00000000:15E1 (15E1 is hex for 5601) and st 0A (LISTEN).

When a connection is established (for example from the haproxy health checks), I can see for a very short time a connection with st 01 (ESTABLISHED) on that port. But even with many thousands sessions in Kibana’s memory, /proc/net/tcp shows 0 established (or time\_wait) connections.

The problem only happens with TLS enabled in Kibana and http2 mode (the default). As soon as I start Kibana with TLS and `server.protocol: http1` the leak is gone.

The haproxy config makes it establish a TCP connection and close it immediately, without performing a TLS handshake.

For us, the workaround with http1 is valid, but I’d glad to help you guys.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 4, 2025, 9:27am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/9 "2025-12-04T09:27:36Z")

</div>

@Fabio_Hecht also wished to share this screenshot:

> [@On another topic](https://discuss.elastic.co/t/383814/2):
>
> Hi, here is what I wanted to attach. The grafana chart show the pod memory allocation with haproxy check on and then off.

 ![Screenshot 2025-12-02 095727](https://us1.discourse-cdn.com/elastic/original/3X/3/2/3227d4ede5a95ef5c184b601ac758e3ba638b51e.png)

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 4, 2025, 9:47am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/10 "2025-12-04T09:47:48Z")

</div>

first of all, I understand your point on having limited access to in a corporate environment. Been there myself.

> [@Fabio\_Hecht](#):
>
> I’m in a corporate environment where things are not so simple. They claim they use this configuration for many services since many years and no one ever complained, so the problem must be at Kibana. So far I have no arguments to disagree with them.

Well, same works both ways, many people use kibana in conjunction with haproxy, did so myself in the past, and people have done so for many years. And AFAIK this (your experience) is not a known issue.

I don’t work for elastic, have no skin in the game, just trying to help. My take is that you _might_ have uncovered something in kibana which, if confirmed, should be found/fixed. You might just have an effectively broken haproxy config. Or indeed something else entirely.

You can open a GitHub bug on it.

I would not be the one working on that bug report, but usually someone attempts to reproduce the issue with the minimal configuration. In a parallel thread, soneone found a a bug in top hits aggregations, could not be reproduced easily by elastic staff, so same sonmeone sent Elastic a couple of GB of data to show how to reproduce it –\> bug was identified quickly (same day!). In your case, they are likely going to want/need to see the full haproxy and kibana config, since by your own report its only when haproxy is added to the mix that you have a problem.

One little thing - does the leak happen without any real/user traffic? i.e. I asked above is it actually just the every 500ms check which is enough to cause the leak?

---

<div class="post-metadata">

**Author:** ![Fabio\_Hecht](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fabio_hecht/32/145873_2.png) [@Fabio\_Hecht](https://discuss.elastic.co/u/Fabio_Hecht)\
**Post date:** [December 8, 2025, 11:29am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/11 "2025-12-08T11:29:47Z")

</div>

Thanks, I will try and open the issue on github this week.

I think someone can try and reproduce it with netcat or another tool that can open and immediately close TCP connections. If it does not work then try with a real haproxy.

Can you please attach the other screenshot I sent you, the one with the heap dump analysis? Thanks.

And yes, the memory is leaked day and night and only when the haproxy is sending the health checks.

Cheers,

Fabio

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 8, 2025, 1:03pm UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/12 "2025-12-08T13:03:38Z")

</div>

Here's other screenshot, sorry I missed it.

 ![Screenshot 2025-11-27_164837](https://us1.discourse-cdn.com/elastic/original/3X/6/b/6bde9f37e6fbcf014b787320f29f52a039961918.png)

> [@Fabio\_Hecht](#):
>
> If it does not work then try with a real haproxy.

IMO they will need your haproxy config to reproduce your issue, but maybe I am wrong.

```auto
#!/bin/sh
while true; do
  nc -z 127.0.0.1 5601
  sleep 1
done

```

(replace IP with your own)

Should reproduce the issue, no? Does it in your case?

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [December 15, 2025, 11:38am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/13 "2025-12-15T11:38:36Z")

</div>

> [@Fabio\_Hecht](#):
>
> Thanks, I will try and open the issue on github this week.

Did you? Any news/progress?

---

<div class="post-metadata">

**Author:** ![Fabio\_Hecht](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fabio_hecht/32/145873_2.png) [@Fabio\_Hecht](https://discuss.elastic.co/u/Fabio_Hecht)\
**Post date:** [December 15, 2025, 11:57am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/14 "2025-12-15T11:57:56Z")

</div>

So far I wasn’t able to reproduce the issue with `nc -z` in a loop. I will try and collect some traces to check what those health checks are doing and hopefully be able to reproduce the issue.

---

<div class="post-metadata">

**Author:** ![Fabio\_Hecht](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/fabio_hecht/32/145873_2.png) [@Fabio\_Hecht](https://discuss.elastic.co/u/Fabio_Hecht)\
**Post date:** [December 17, 2025, 7:23am UTC](https://discuss.elastic.co/t/kibana-memory-consumption-growing-linearly-until-it-crashes/383618/15 "2025-12-17T07:23:24Z")

</div>

here is is, thanks for the support:

[memory leak - http2 sessions with haproxy health check · Issue #246668 · elastic/kibana](https://github.com/elastic/kibana/issues/246668)