# Configure ruby's memory limit?

**URL:** https://meta.discourse.org/t/configure-rubys-memory-limit/165651
**Category:** Feature
**Created:** [September 28, 2020, 5:06pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651 "2020-09-28T17:06:12Z")
**Posts on this page:** 12
**Page:** 1

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [September 28, 2020, 5:06pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/1 "2020-09-28T17:06:12Z")

</div>

Could it be made a site configuration option as to how much memory can be used? Presently the tuning is set to 2G (Edit: oops, I am wrong, see below) - previously it was 4G - and yet the recommended hardware configuration is 1G + swap. It seems to me that a 1G node might well get into a bit of a paging frenzy if ruby’s usage really did get up to 2G.

From an upgrade log:

```
Migrating default
Seeding default
***Bundling assets. This will take a while*** 
$ RUBY_GC_MALLOC_LIMIT_MAX=20971520 RUBY_GC_OLDMALLOC_LIMIT_MAX=20971520 RUBY_GC_HEAP_GROWTH_MAX_SLOTS=50000 RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0.9 bundle exec rake assets:precompile
Purging temp files
Bundling assets

```

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 28, 2020, 5:07pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/2 "2020-09-28T17:07:14Z")

</div>

Not sure how relevant these settings are in modern Ruby but @sam would know best.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [September 28, 2020, 5:24pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/3 "2020-09-28T17:24:58Z")

</div>

Ahem, excuse me, that’s not 2G, that’s 20M. So nothing like the situation that I thought it was. (Edit: it’s worse! See below)

---

<div class="post-metadata">

### Author: ![JimPas](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jimpas/32/148179_2.png) [@JimPas](https://meta.discourse.org/u/JimPas)
#### Post date: [September 28, 2020, 6:34pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/4 "2020-09-28T18:34:31Z")

</div>

> [@Ed\_S](#):
>
> that’s not 2G, that’s 20M

Try 20G. 😉 🙂

> [@Ed\_S](#):
>
> `$ RUBY_GC_MALLOC_LIMIT_MAX=20971520 RUBY_GC_OLDMALLOC_LIMIT_MAX=20971520`

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [September 28, 2020, 6:38pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/5 "2020-09-28T18:38:06Z")

</div>

Discourse have a predictable memory usage, so the knob you want is the number of Unicorn workers.

> <https://github.com/discourse/discourse_docker/blob/master/discourse-setup#L247>

If you have a 1GB server we will default to 2 workers, which should operate well under this low amount of memory.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [September 28, 2020, 6:43pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/6 "2020-09-28T18:43:27Z")

</div>

Indeed, while running as a forum. But this is not that!

During upgrades, some tasks specify those envvars for ruby.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [September 28, 2020, 6:52pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/7 "2020-09-28T18:52:06Z")

</div>

Yes, during updates we set those vars so the upgrade doesn’t fail because of memory pressure on very low spec machines.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [September 28, 2020, 6:55pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/8 "2020-09-28T18:55:47Z")

</div>

Right, and my observation is that the limits might be set too high for some cases, so I’m wondering if it can be made configurable.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [September 28, 2020, 7:10pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/9 "2020-09-28T19:10:48Z")

</div>

We tested this procedure a lot over the years and can ensure that it will work for small communities using a 1GB VPS just fine. It even terminates additional Unicorn workers to reclaim memory during the upgrade to help.

You can read the code that came from this commit:

[https://github.com/discourse/docker\_manager/commit/2bc201509216bb9181419e0a87a5bde3866087c7](https://github.com/discourse/docker_manager/commit/2bc201509216bb9181419e0a87a5bde3866087c7)

If you can reproduce it failing on a Digital Ocean droplet we are happy to take a look into it.

> [@Ed\_S](#):
>
> I’m wondering if it can be made configurable.

If that is a must you can fork the plugin and adjust to your needs.

---

<div class="post-metadata">

### Author: ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [September 28, 2020, 7:46pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/10 "2020-09-28T19:46:26Z")

</div>

Thanks, I’m getting a picture now. (Two very important points: these GC settings are adjusted specifically for upgrades, and the units are bytes, so the limit is set presently to 20MB. There are useful and interesting details in [this earlier thread](https://web.archive.org/web/20140802023242/https://meta.discourse.org/t/tuning-ruby-and-rails-for-discourse/4126) [archive link because it’s unavailable to me now].)

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [September 28, 2020, 11:47pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/11 "2020-09-28T23:47:27Z")

</div>

Should we undelete that topic @sam? Is it of historical value or obsolete?

---

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [September 28, 2020, 11:51pm UTC](https://meta.discourse.org/t/configure-rubys-memory-limit/165651/12 "2020-09-28T23:51:26Z")

</div>

It is certainly out-of-date, latest ruby has multiple malloc limits. It is an interesting topic with some historical value but would need a big “Out-of-date” sign on top.

Our upgrade is already running as tight as it can, best we could do on top of this is decrease availability. If memory is super constrained then you are going to have to eat outages when you upgrade.
