# Possible memory leak - Kong 1.4 & KIC 0.6.1

**URL:** <https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800>\
**Category:** General\
**Tags:** kubernetes\
**Created:** [November 4, 2019, 8:00am UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800 "2019-11-04T08:00:01Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![niklasye](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/niklasye/32/857_2.png) [@niklasye](https://discuss.konghq.com/u/niklasye)\
**Post date:** [November 4, 2019, 8:00am UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800/1 "2019-11-04T08:00:01Z")

</div>

- We are running Kong and the ingress controller in Openshift 3.9.
- We are running in DB-less mode
- Even with kong running with 4GB of memory it doesn’t seem to stop increasing the memory usage.
- We have tried disabling all plugins, it’s still increasing it’s memory usage over time.
- Load seems to increase the rate of memory usage increase

Below shows a graph of memory usage.

- Yellow line=Proxy
- Green line=Ingress controller  
 ![Screenshot%20from%202019-11-04%2008-48-17](https://canada1.discourse-cdn.com/flex036/uploads/konghq/original/2X/f/fbc986c2c9e86c469c9d825d985d93d73b9ba679.png)

Shared dict sizes.

 ![Screenshot%20from%202019-11-04%2008-48-44](https://canada1.discourse-cdn.com/flex036/uploads/konghq/original/2X/d/db49590fe212a62d7667360788a0141678e1d0e1.png)

Lua VMs memory

 ![Screenshot%20from%202019-11-04%2008-48-53](https://canada1.discourse-cdn.com/flex036/uploads/konghq/original/2X/4/47150fbc6556db309419bbf87326ae2801187b3d.png)

These graphs were generated under almost no load at all. During tests with ~400 requests/s the memory increase rate is higher.

ENV from proxy:  
KONG\_DATABASE: off  
KONG\_NGINX\_HTTP\_CLIENT\_HEADER\_TIMEOUT: 5s  
KONG\_NGINX\_HTTP\_CLIENT\_BODY\_TIMEOUT: 5s  
KONG\_NGINX\_HTTP\_SEND\_TIMEOUT: 1m  
KONG\_NGINX\_WORKER\_PROCESSES: 1  
KONG\_ROUTER\_CONSISTENCY: eventual  
KONG\_MEM\_CACHE\_SIZE: 256m  
KONG\_NGINX\_HTTP\_INCLUDE: /kong/servers.conf  
KONG\_ADMIN\_ACCESS\_LOG: /dev/stdout  
KONG\_ADMIN\_ERROR\_LOG: /dev/stderr  
KONG\_PROXY\_ACCESS\_LOG: /dev/stdout  
KONG\_PROXY\_ERROR\_LOG: /dev/stderr  
KONG\_ADMIN\_LISTEN: 127.0.0.1:8444 ssl  
KONG\_LOG\_LEVEL: warn  
KONG\_PLUGINS: prometheus

Any tips on what the problem could be or how to further troubleshoot this?

---

<div class="post-metadata">

**Author:** ![goober](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/goober/32/1359_2.png) [@goober](https://discuss.konghq.com/u/goober)\
**Post date:** [November 6, 2019, 12:12pm UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800/2 "2019-11-06T12:12:41Z")

</div>

We have noticed the same.

We had another issue that was resolved by upgrading to kong 1.4 and KIC 0.6.1 but we are still seeing the constant increase of memory usage.

> <https://github.com/Kong/kong/issues/5203>
>
> \### Summary
> 
> We have recently started to recognize error events in our kong-pr…oxy (see logs below). First occurrence happens a couple of minutes after startup. 
> 
> \### Additional Details & Logs
> 
> \* \*Manifests:\* \[kong-ingress-controller dbless\](https://github.com/Kong/kubernetes-ingress-controller/tree/0.6.0/deploy/manifests)
> \* \*Kong version:\* 1.3
> \* \*kong-ingress-controller:\* 0.6.0
> \* Openshift 3.10
> \`\`\`
> 2019/11/04 22:24:21 \[notice\] 39#0: \*50122 \[lua\] cache.lua:321: purge(): \[DB cache\] purging (local) cache, client: 127.0.0.1, server: kong\_admin, request: "POST /config?check\_hash=1 HTTP/1.1", host: "localhost:8444"
> \--
>   | 2019/11/04 22:24:21 \[warn\] 39#0: \*50122 \[lua\] events.lua:155: post\_event(): worker-events: could not write to shm after 6 tries (no memory), it is either fragmented or cannot allocate more memory, consider increasing 'opts.shm\_retries' or increasing the shm size, client: 127.0.0.1, server: kong\_admin, request: "POST /config?check\_hash=1 HTTP/1.1", host: "localhost:8444"
>   | 2019/11/04 22:24:21 \[error\] 39#0: \*50122 \[lua\] events.lua:273: post(): worker-events: failed posting event "upstreams" by "crud"; no memory, client: 127.0.0.1, server: kong\_admin, request: "POST /config?check\_hash=1 HTTP/1.1", host: "localhost:8444"
>   | 2019/11/04 22:24:21 \[error\] 39#0: \*50122 \[kong\] init.lua:331 failed posting crud event for upstreams nil, client: 127.0.0.1, server: kong\_admin, request: "POST /config?check\_hash=1 HTTP/1.1", host: "localhost:8444"
>   | 2019/11/04 22:24:21 \[warn\] 39#0: \*50122 \[lua\] events.lua:155: post\_event(): worker-events: could not write to shm after 6 tries (no memory), it is either fragmented or cannot allocate more memory, consider increasing 'opts.shm\_retries' or increasing the shm size, client: 127.0.0.1, server: kong\_admin, request: "POST /config?check\_hash=1 HTTP/1.1", host: "localhost:8444"
>   | 2019/11/04 22:24:21 \[error\] 39#0: \*50122 \[lua\] events.lua:273: post(): worker-events: failed posting event "upstreams" by "crud"; no memory, client: 127.0.0.1, server: kong\_admin, request: "POST /config?check\_hash=1 HTTP/1.1", host: "localhost:8444"
>   | 2019/11/04 22:24:21 \[error\] 39#0: \*50122 \[kong\] init.lua:331 failed posting crud event for upstreams nil, client: 127.0.0.1, server: kong\_admin, request: "POST /config?check\_hash=1 HTTP/1.1", host: "localhost:8444"
>   | 2019/11/04 22:24:21 \[error\] 39#0: \*50122 \[lua\] events.lua:364: post(): worker-events: dropping event; waiting for event data timed out, id: 103004, client: 127.0.0.1, server: kong\_admin, request: "POST /config?check\_hash=1 HTTP/1.1", host: "localhost:8444"
> \`\`\`
> 
> Output from \`curl https://localhost:8444/status\`
> 
> \`\`\`
> {
> "database": {
> "reachable": true
> },
> "memory": {
> "workers\_lua\_vms": \[{
> "http\_allocated\_gc": "0.03 MiB",
> "pid": 32
> }, {
> "http\_allocated\_gc": "0.03 MiB",
> "pid": 33
> }, {
> "http\_allocated\_gc": "0.07 MiB",
> "pid": 34
> }, {
> "http\_allocated\_gc": "0.03 MiB",
> "pid": 35
> }, {
> "http\_allocated\_gc": "0.03 MiB",
> "pid": 36
> }, {
> "http\_allocated\_gc": "0.03 MiB",
> "pid": 37
> }, {
> "http\_allocated\_gc": "0.03 MiB",
> "pid": 38
> }, {
> "http\_allocated\_gc": "0.03 MiB",
> "pid": 39
> }\],
> "lua\_shared\_dicts": {
> "kong\_locks": {
> "allocated\_slabs": "0.06 MiB",
> "capacity": "8.00 MiB"
> },
> "kong\_db\_cache\_2": {
> "allocated\_slabs": "2.12 MiB",
> "capacity": "128.00 MiB"
> },
> "kong": {
> "allocated\_slabs": "0.04 MiB",
> "capacity": "5.00 MiB"
> },
> "kong\_db\_cache\_miss\_2": {
> "allocated\_slabs": "0.09 MiB",
> "capacity": "12.00 MiB"
> },
> "kong\_db\_cache": {
> "allocated\_slabs": "0.76 MiB",
> "capacity": "128.00 MiB"
> },
> "kong\_process\_events": {
> "allocated\_slabs": "5.00 MiB",
> "capacity": "5.00 MiB"
> },
> "kong\_db\_cache\_miss": {
> "allocated\_slabs": "0.08 MiB",
> "capacity": "12.00 MiB"
> },
> "kong\_cluster\_events": {
> "allocated\_slabs": "0.04 MiB",
> "capacity": "5.00 MiB"
> },
> "prometheus\_metrics": {
> "allocated\_slabs": "0.04 MiB",
> "capacity": "5.00 MiB"
> },
> "kong\_healthchecks": {
> "allocated\_slabs": "0.08 MiB",
> "capacity": "5.00 MiB"
> },
> "kong\_rate\_limiting\_counters": {
> "allocated\_slabs": "0.08 MiB",
> "capacity": "12.00 MiB"
> }
> }
> },
> "server": {
> "connections\_writing": 1,
> "total\_requests": 108,
> "connections\_handled": 108,
> "connections\_accepted": 108,
> "connections\_reading": 0,
> "connections\_active": 1,
> "connections\_waiting": 0
> }
> }
> \`\`\`
> 
> Kong configuration:
> \`\`\`
> {
> "plugins": {
> "enabled\_in\_cluster": \["prometheus", "zipkin", "request-transformer", "post-function"\],
> "available\_on\_server": {
> "correlation-id": true,
> "pre-function": true,
> "cors": true,
> "ldap-auth": true,
> "loggly": true,
> "hmac-auth": true,
> "zipkin": true,
> "request-size-limiting": true,
> "azure-functions": true,
> "request-transformer": true,
> "oauth2": true,
> "response-transformer": true,
> "ip-restriction": true,
> "statsd": true,
> "jwt": true,
> "proxy-cache": true,
> "basic-auth": true,
> "key-auth": true,
> "http-log": true,
> "datadog": true,
> "tcp-log": true,
> "rate-limiting": true,
> "post-function": true,
> "prometheus": true,
> "acl": true,
> "kubernetes-sidecar-injector": true,
> "syslog": true,
> "file-log": true,
> "udp-log": true,
> "response-ratelimiting": true,
> "aws-lambda": true,
> "session": true,
> "bot-detection": true,
> "request-termination": true
> }
> },
> "tagline": "Welcome to kong",
> "configuration": {
> "plugins": \["bundled"\],
> "admin\_ssl\_enabled": true,
> "lua\_ssl\_verify\_depth": 1,
> "trusted\_ips": {},
> "prefix": "\\/usr\\/local\\/kong",
> "loaded\_plugins": {
> "session": true,
> "pre-function": true,
> "cors": true,
> "ldap-auth": true,
> "loggly": true,
> "hmac-auth": true,
> "zipkin": true,
> "request-size-limiting": true,
> "azure-functions": true,
> "request-transformer": true,
> "oauth2": true,
> "response-transformer": true,
> "syslog": true,
> "statsd": true,
> "jwt": true,
> "proxy-cache": true,
> "basic-auth": true,
> "key-auth": true,
> "http-log": true,
> "datadog": true,
> "tcp-log": true,
> "correlation-id": true,
> "post-function": true,
> "bot-detection": true,
> "acl": true,
> "kubernetes-sidecar-injector": true,
> "ip-restriction": true,
> "file-log": true,
> "udp-log": true,
> "response-ratelimiting": true,
> "aws-lambda": true,
> "rate-limiting": true,
> "prometheus": true,
> "request-termination": true
> },
> "cassandra\_username": "kong",
> "ssl\_cert\_key": "\\/usr\\/local\\/kong\\/ssl\\/kong-default.key",
> "admin\_ssl\_cert\_key": "\\/usr\\/local\\/kong\\/ssl\\/admin-kong-default.key",
> "dns\_resolver": {},
> "pg\_user": "kong",
> "mem\_cache\_size": "128m",
> "nginx\_admin\_directives": {},
> "nginx\_http\_upstream\_directives": \[{
> "value": "60s",
> "name": "keepalive\_timeout"
> }, {
> "value": "100",
> "name": "keepalive\_requests"
> }, {
> "value": "60",
> "name": "keepalive"
> }\],
> "nginx\_http\_directives": \[{
> "value": "TLSv1.1 TLSv1.2 TLSv1.3",
> "name": "ssl\_protocols"
> }, {
> "value": "\\/kong\\/servers.conf",
> "name": "include"
> }, {
> "value": "prometheus\_metrics 5m",
> "name": "lua\_shared\_dict"
> }\],
> "pg\_host": "127.0.0.1",
> "nginx\_acc\_logs": "\\/usr\\/local\\/kong\\/logs\\/access.log",
> "pg\_semaphore\_timeout": 60000,
> "proxy\_listen": \["0.0.0.0:8000", "0.0.0.0:8443 ssl"\],
> "client\_ssl\_cert\_default": "\\/usr\\/local\\/kong\\/ssl\\/kong-default.crt",
> "cassandra\_ssl": false,
> "db\_update\_frequency": 5,
> "db\_update\_propagation": 0,
> "stream\_listen": \["off"\],
> "nginx\_err\_logs": "\\/usr\\/local\\/kong\\/logs\\/error.log",
> "cassandra\_port": 9042,
> "dns\_order": \["LAST", "SRV", "A", "CNAME"\],
> "dns\_error\_ttl": 1,
> "headers": \["server\_tokens", "latency\_tokens"\],
> "cassandra\_lb\_policy": "RequestRoundRobin",
> "nginx\_optimizations": true,
> "nginx\_http\_upstream\_keepalive\_timeout": "60s",
> "pg\_timeout": 5000,
> "nginx\_http\_upstream\_keepalive\_requests": "100",
> "database": "off",
> "proxy\_access\_log": "logs\\/access.log",
> "pg\_database": "kong",
> "nginx\_worker\_processes": "auto",
> "client\_ssl": false,
> "lua\_package\_cpath": "",
> "ssl\_cert\_key\_default": "\\/usr\\/local\\/kong\\/ssl\\/kong-default.key",
> "admin\_acc\_logs": "\\/usr\\/local\\/kong\\/logs\\/admin\_access.log",
> "cassandra\_contact\_points": \["127.0.0.1"\],
> "cassandra\_repl\_factor": 1,
> "lua\_package\_path": ".\\/?.lua;.\\/?\\/init.lua;",
> "nginx\_pid": "\\/usr\\/local\\/kong\\/pids\\/nginx.pid",
> "upstream\_keepalive": 60,
> "dns\_stale\_ttl": 4,
> "origins": {},
> "nginx\_kong\_stream\_conf": "\\/usr\\/local\\/kong\\/nginx-kong-stream.conf",
> "error\_default\_type": "text\\/plain",
> "admin\_access\_log": "\\/dev\\/stdout",
> "stream\_listeners": {},
> "nginx\_daemon": "off",
> "proxy\_listeners": \[{
> "listener": "0.0.0.0:8000",
> "proxy\_protocol": false,
> "reuseport": false,
> "transparent": false,
> "ssl": false,
> "ip": "0.0.0.0",
> "deferred": false,
> "http2": false,
> "port": 8000,
> "bind": false
> }, {
> "listener": "0.0.0.0:8443 ssl",
> "proxy\_protocol": false,
> "reuseport": false,
> "transparent": false,
> "ssl": true,
> "ip": "0.0.0.0",
> "deferred": false,
> "http2": false,
> "port": 8443,
> "bind": false
> }\],
> "proxy\_ssl\_enabled": true,
> "nginx\_http\_upstream\_keepalive": "60",
> "db\_cache\_warmup\_entities": \["services", "plugins"\],
> "lua\_socket\_pool\_size": 30,
> "nginx\_http\_ssl\_protocols": "TLSv1.1 TLSv1.2 TLSv1.3",
> "router\_consistency": "strict",
> "db\_resurrect\_ttl": 30,
> "nginx\_stream\_directives": {},
> "cassandra\_consistency": "ONE",
> "db\_cache\_ttl": 0,
> "admin\_error\_log": "\\/dev\\/stderr",
> "admin\_ssl\_cert\_default": "\\/usr\\/local\\/kong\\/ssl\\/admin-kong-default.crt",
> "dns\_not\_found\_ttl": 30,
> "pg\_ssl": false,
> "nginx\_http\_include": "\\/kong\\/servers.conf",
> "ssl\_cipher\_suite": "modern",
> "cassandra\_repl\_strategy": "SimpleStrategy",
> "kong\_env": "\\/usr\\/local\\/kong\\/.kong\_env",
> "cassandra\_schema\_consensus\_timeout": 10000,
> "pg\_max\_concurrent\_queries": 0,
> "client\_max\_body\_size": "0",
> "nginx\_kong\_conf": "\\/usr\\/local\\/kong\\/nginx-kong.conf",
> "real\_ip\_header": "X-Forwarded-For",
> "dns\_hostsfile": "\\/etc\\/hosts",
> "admin\_listeners": \[{
> "listener": "127.0.0.1:8444 ssl",
> "proxy\_protocol": false,
> "reuseport": false,
> "transparent": false,
> "ssl": true,
> "ip": "127.0.0.1",
> "deferred": false,
> "http2": false,
> "port": 8444,
> "bind": false
> }\],
> "dns\_no\_sync": false,
> "ssl\_cert": "\\/usr\\/local\\/kong\\/ssl\\/kong-default.crt",
> "cassandra\_timeout": 5000,
> "admin\_ssl\_cert\_key\_default": "\\/usr\\/local\\/kong\\/ssl\\/admin-kong-default.key",
> "cassandra\_ssl\_verify": false,
> "cassandra\_data\_centers": \["dc1:2", "dc2:3"\],
> "log\_level": "notice",
> "real\_ip\_recursive": "on",
> "proxy\_error\_log": "logs\\/error.log",
> "client\_ssl\_cert\_key\_default": "\\/usr\\/local\\/kong\\/ssl\\/kong-default.key",
> "admin\_ssl\_cert": "\\/usr\\/local\\/kong\\/ssl\\/admin-kong-default.crt",
> "anonymous\_reports": true,
> "nginx\_proxy\_directives": {},
> "nginx\_sproxy\_directives": {},
> "pg\_port": 5432,
> "pg\_ssl\_verify": false,
> "client\_body\_buffer\_size": "8k",
> "ssl\_preread\_enabled": true,
> "ssl\_cert\_csr\_default": "\\/usr\\/local\\/kong\\/ssl\\/kong-default.csr",
> "nginx\_conf": "\\/usr\\/local\\/kong\\/nginx.conf",
> "cassandra\_keyspace": "kong",
> "ssl\_cert\_default": "\\/usr\\/local\\/kong\\/ssl\\/kong-default.crt",
> "enabled\_headers": {
> "latency\_tokens": true,
> "X-Kong-Proxy-Latency": true,
> "Via": true,
> "server\_tokens": true,
> "Server": true,
> "X-Kong-Upstream-Latency": true,
> "X-Kong-Upstream-Status": false
> },
> "admin\_listen": \["127.0.0.1:8444 ssl"\]
> },
> "version": "1.3.0",
> "node\_id": "19a09d1a-f414-4f19-9604-f12c2ea2bb0a",
> "lua\_version": "LuaJIT 2.1.0-beta3",
> "prng\_seeds": {
> "pid: 32": 182465973931,
> "pid: 35": 911142381632,
> "pid: 39": 205124189184,
> "pid: 1": 219190232120,
> "pid: 34": 120102220132,
> "pid: 38": 405410720719,
> "pid: 37": 932922421325,
> "pid: 36": 541265322358,
> "pid: 33": 111174441921
> },
> "timers": {
> "pending": 144,
> "running": 0
> },
> "hostname": "ingress-kong-998974759-gtxvn"
> }
> \`\`\`
> You can also see that the used memory keeps going upwards:
>  
> !\[image\](https://user-images.githubusercontent.com/124244/68190878-2e6c1500-ffa6-11e9-8d80-809fb19cf2ce.png)

After further investigation this could be an expected behavior?

> [@Kong memory usage doesn't come down](https://discuss.konghq.com/t/kong-memory-usage-doesnt-come-down/3928/5):
>
> Hello @cedar715, This is more or less expected behavior in regard to how LuaJIT VM is used by Kong. As long as the memory does not grow unconfined it is not considered as a memory leak. The reason behind it is that Kong heavily caches various objects inside the Lua VM for speeding up the access, which does not get freed when the load is gone. Plus the LuaJIT VM itself does not always gives back freed memory to the O/S for various reasons (fragmentation, avoid frequent system calls, etc). If y…

---

<div class="post-metadata">

**Author:** ![niklasye](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/niklasye/32/857_2.png) [@niklasye](https://discuss.konghq.com/u/niklasye)\
**Post date:** [November 6, 2019, 2:23pm UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800/3 "2019-11-06T14:23:16Z")

</div>

I’ve decreased the number of nginx workers to 1(to decrease memory usage)  
Whenever the proxy now reaches ~99% of memory usage it seems to trigger a large garbage collection that impacts incoming requests.

I lose about 500ms of traffic(~40 requests) during the GC. It would be nice if the GC triggered earlier and in a less severe manner. Is it something we can configure I wonder?

I’m currently running the proxy with 1GB of memory, maybe that is not a realistic limit.

---

<div class="post-metadata">

**Author:** ![niklasye](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/niklasye/32/857_2.png) [@niklasye](https://discuss.konghq.com/u/niklasye)\
**Post date:** [November 7, 2019, 8:42am UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800/4 "2019-11-07T08:42:17Z")

</div>

I’ve done tests now with 4GB or memory for the proxy, the result is still the same. It triggers a large GC when the memory reaches 100% and a few requests are lost during the GC.

---

<div class="post-metadata">

**Author:** ![goober](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/goober/32/1359_2.png) [@goober](https://discuss.konghq.com/u/goober)\
**Post date:** [November 7, 2019, 11:54am UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800/5 "2019-11-07T11:54:31Z")

</div>

I have done some further investigation and can see this in the log while I do some stress testing:

```auto
19-11-07 11:29:13.599 - 2019/11/07 11:29:13 [notice] 1#0: start worker process 15682	proxy
19-11-07 11:29:13.596 - 2019/11/07 11:29:13 [alert] 1#0: worker process 3572 exited on signal 9	proxy
19-11-07 11:29:13.594 - 2019/11/07 11:29:13 [notice] 1#0: signal 17 (SIGCHLD) received from 3572	proxy
19-11-07 11:29:13.583 - E1107 11:29:13.582602 1 controller.go:132] unexpected failure updating Kong configuration: ingress-controller
19-11-07 11:29:13.583 - posting new config to /config: making HTTP reqeust: Post https://localhost:8444/config?check_hash=1: EOF	ingress-controller

```

From this time and until the next iteration for the ingress-controller to sync I get 404 for every request to an endpoind behind the api gateway. So this indicates that the dbless config is somehow wiped from the memory when the worker process is killed

---

<div class="post-metadata">

**Author:** ![hbagdi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hbagdi/32/562_2.png) [@hbagdi](https://discuss.konghq.com/u/hbagdi)\
**Post date:** [November 7, 2019, 8:16pm UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800/6 "2019-11-07T20:16:05Z")

</div>

Thank you for the reports @goober and @niklasye!

We have taken a note of these and the team is looking into the memory leak issue here.  
We will post an update as soon as we have one.

---

<div class="post-metadata">

**Author:** ![niklasye](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/niklasye/32/857_2.png) [@niklasye](https://discuss.konghq.com/u/niklasye)\
**Post date:** [November 25, 2019, 3:04pm UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800/7 "2019-11-25T15:04:10Z")

</div>

Hi! It looks like there might be a solution in master now, right? [https://github.com/Kong/kong/issues/5203](https://github.com/Kong/kong/issues/5203)

Would you know when we can expect a new release including this fix? 🙂

---

<div class="post-metadata">

**Author:** ![hbagdi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hbagdi/32/562_2.png) [@hbagdi](https://discuss.konghq.com/u/hbagdi)\
**Post date:** [November 26, 2019, 12:14am UTC](https://discuss.konghq.com/t/possible-memory-leak-kong-1-4-kic-0-6-1/4800/8 "2019-11-26T00:14:09Z")

</div>

There are a few fixes that we want to get in but expect a patch release soon, some time around next week.