# High Level Kong Mem Question

**URL:** <https://discuss.konghq.com/t/high-level-kong-mem-question/1015>\
**Category:** Questions\
**Created:** [May 20, 2018, 2:18am UTC](https://discuss.konghq.com/t/high-level-kong-mem-question/1015 "2018-05-20T02:18:38Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jeremyjpj0916](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/jeremyjpj0916/32/1388_2.png) [@jeremyjpj0916](https://discuss.konghq.com/u/jeremyjpj0916)\
**Post date:** [May 20, 2018, 2:18am UTC](https://discuss.konghq.com/t/high-level-kong-mem-question/1015/1 "2018-05-20T02:18:38Z")

</div>

As I use Kong I have some lingering questions about mem consumption and such I would like clarified.

Kong gives us the ability to increase/decrease the default shared dictionary Kong core utilizes, what other memory settings are there to concern ourselves with in the Kong/Openresty/Nginx stack, and can those be set by us @ the Kong template layer? My specific concern is one such as:

1. I have heard the term Lua VM thrown around, does it have a defined mem ceiling by default and is it configurable+exposed to us Kongers?

So when we execute something like so:

```auto
  ngx.req.read_body()
  local req_body = ngx.req.get_body_data()

```

Where in memory is this going? To the Lua VM?

Sorry if these are dumb questions, but I am just pondering if there are situations Kong could run out of mem to service a Proxy, and the volumes/tx sizes it would take.

Thanks!

---

<div class="post-metadata">

**Author:** ![thibaultcha](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/thibaultcha/32/340_2.png) [@thibaultcha](https://discuss.konghq.com/u/thibaultcha)\
**Post date:** [May 20, 2018, 7:53pm UTC](https://discuss.konghq.com/t/high-level-kong-mem-question/1015/2 "2018-05-20T19:53:36Z")

</div>

> Kong gives us the ability to increase/decrease the default shared dictionary Kong core utilizes

More specifically, the size of the database cache shared between workers. Kong uses other [shared memory zones](https://github.com/Kong/kong/blob/master/kong/templates/nginx_kong.lua#L31-L39) that are not configurable. In the future, we might separate the database cache into multiple ones.

> I have heard the term Lua VM thrown around, does it have a defined mem ceiling by default and is it configurable+exposed to us Kongers?

Lua being an interpreted language, the term Lua VM refers to the Lua interpreter. LuaJIT is subject to some memory limits of its own, around ~2GB (a bit less in my experience) for LuaJIT 2.1 on 64 bits architectures. See [Re: LuaJIT strange memory limit](http://lua-users.org/lists/lua-l/2010-11/msg00241.html). Each worker gets its own Lua VM.

Because of this, code like the snippet you pasted can be dangerous with large bodies or in instances with a small number of workers, and lead to memory exhaustion of the Lua VM in those workers.

---

<div class="post-metadata">

**Author:** ![jeremyjpj0916](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/jeremyjpj0916/32/1388_2.png) [@jeremyjpj0916](https://discuss.konghq.com/u/jeremyjpj0916)\
**Post date:** [May 21, 2018, 4:39am UTC](https://discuss.konghq.com/t/high-level-kong-mem-question/1015/3 "2018-05-21T04:39:05Z")

</div>

This is exactly the level of insight I was looking for. Thanks again @thibaultcha! That snippet of code is how I get the HTTP body to sign in a JWT for non-repudiation in Gateway-\>API Provider security and I don’t see a way around that without doing Mutual TLS (which has never been one of my favorite patterns). I pondered sacrificing some security and just signing the HTTP headers for providers then to validate on but decided that would not suffice. If you want, I could do a nice write up in some agreeable portion of the Kong documentation on what you mentioned in your post if you like? Certainly could help others. I think it makes sense to set a global gateway limit in the 20-30 MB range anyways to help prevent a lua vm memory exhaustion and if api consumers need to move larger sized payloads to enforce a pattern of chunking on the tx because it just seems bad practice to use a single HTTP Packet for a very large payload (100 MB+).
