# High memory use during assets precompilation

**URL:** https://meta.discourse.org/t/high-memory-use-during-assets-precompilation/56526
**Category:** Development
**Created:** [January 28, 2017, 6:57pm UTC](https://meta.discourse.org/t/high-memory-use-during-assets-precompilation/56526 "2017-01-28T18:57:49Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![Rotonen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rotonen/32/121135_2.png) [@Rotonen](https://meta.discourse.org/u/Rotonen)
#### Post date: [January 28, 2017, 6:57pm UTC](https://meta.discourse.org/t/high-memory-use-during-assets-precompilation/56526/1 "2017-01-28T18:57:49Z")

</div>

During upgrades Bundler uses a lot of memory in relation to the rest of the installation during the assets precompilation. This would hint at some VM object refcount thing not releasing the touched objects (files having been read in?) and thus the GC not firing and doing its job. Most likely this is an artefact of either Bundler itself or the Rails asset pipeline.

```
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3952 1000 20 0 3636888 651740 14836 R 86,8 31,8 2:23.24 bundle
3433 1000 20 0 1681992 190036 4776 S 0,0 9,3 0:05.55 ruby
3403 1000 20 0 1688156 172824 4812 S 0,0 8,4 0:05.95 ruby
3391 1000 20 0 1687128 143528 5100 S 0,0 7,0 0:05.95 ruby
3366 1000 20 0 510236 105780 4528 S 0,3 5,2 0:02.84 ruby
2920 1000 20 0 465132 92584 6804 S 0,0 4,5 0:11.59 ruby

```

For your consideration to maybe take a deeper look at this, as it is causing annoying shuffling for sysadmins with other processes on servers at upgrade times if the servers are provisioned for the runtime memory requirements.

---

<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: [January 30, 2017, 3:37pm UTC](https://meta.discourse.org/t/high-memory-use-during-assets-precompilation/56526/2 "2017-01-30T15:37:02Z")

</div>

@sgrif is painfully aware of this 🙂

The bad news, at the moment stuff is looking even worse if we upgrade to sprockets 4 (we are on 3)

The good news, some time this year we plan to move off [sprockets](https://github.com/rails/sprockets) altogether and make this a non-issue.

---

<div class="post-metadata">

### Author: ![Rotonen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rotonen/32/121135_2.png) [@Rotonen](https://meta.discourse.org/u/Rotonen)
#### Post date: [January 30, 2017, 5:13pm UTC](https://meta.discourse.org/t/high-memory-use-during-assets-precompilation/56526/3 "2017-01-30T17:13:18Z")

</div>

I figured you would hit this bit of juggling on your hosted services and hoped you would have cooked up a pattern in-house.

If you have a public ticket on an open source component for that at some point, do cross post here - I’m willing to help tackle this (design-side, implementation-side, just general input, metrification, testing).

Otherwise may the UNIX pipe (or Goroutine or equivalent) be with you.

---

<div class="post-metadata">

### Author: ![Rotonen](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/rotonen/32/121135_2.png) [@Rotonen](https://meta.discourse.org/u/Rotonen)
#### Post date: [March 23, 2017, 10:18am UTC](https://meta.discourse.org/t/high-memory-use-during-assets-precompilation/56526/4 "2017-03-23T10:18:26Z")

</div>

`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`

Seems you fixed this via GC parametres at some point as of late, thank you.

---

<div class="post-metadata">

### Author: ![davidnmbond](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/davidnmbond/32/378330_2.png) [@davidnmbond](https://meta.discourse.org/u/davidnmbond)
#### Post date: [April 12, 2024, 1:23pm UTC](https://meta.discourse.org/t/high-memory-use-during-assets-precompilation/56526/5 "2024-04-12T13:23:28Z")

</div>

Any progress on this issue? We are seeing 14GB of memory being allocated when creating an EMPTY instance of 3.2.1 before it runs out of memory and dies.

---

<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: [April 12, 2024, 4:58pm UTC](https://meta.discourse.org/t/high-memory-use-during-assets-precompilation/56526/6 "2024-04-12T16:58:59Z")

</div>

Could you share output of `vmstat 5` in this case? If you’re looking at `ps` or `top` then you might be seeing something other than the memory that’s in use. Allocated memory isn’t so important if it’s not in use.

For example, in ps output I see VSZ and RSS. I care about the RSS.

```plaintext
# ps uax|egrep '[0-9].unicorn|VS[Z]'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
ddiscou+ 2192 0.0 13.4 558320 267540 ? Sl Jan10 33:21 unicorn master -E production -c config/unicorn.conf.rb
ddiscou+ 2294 0.0 18.2 5126600 363432 ? Sl Jan10 90:59 unicorn worker[0] -E production -c config/unicorn.conf.rb
ddiscou+ 2301 0.0 14.2 5149576 282892 ? Sl Jan10 38:40 unicorn worker[1] -E production -c config/unicorn.conf.rb

```

In `top` I see the same thing but it’s called VIRT and RES

```plaintext
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND                                                          
 2284 ddiscou+ 25 5 5246644 327496 5640 S 1.7 16.4 872:50.70 ruby                                                             
 2294 ddiscou+ 20 0 5126600 364284 14436 S 0.7 18.3 91:00.13 ruby                                                             

```

vmstat tells me what the memory pressure is right now - how much swap remains, how much free memory and buffer memory, and most crucially if there’s any swap-in (the `si` column)

```plaintext
root@ubuntu-2gb-nbg1-1:~# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r b swpd free buff cache si so bi bo in cs us sy id wa st
 0 0 239616 127080 185428 464448 0 0 14 32 4 2 2 1 97 0 0
 0 0 239616 124584 185432 464500 0 0 0 13 138 318 2 2 96 0 0
 0 0 239616 126120 185436 464500 0 0 0 13 116 264 1 0 99 0 0
 0 0 239616 120376 185436 464504 0 0 0 46 125 322 3 2 95 0 0
 0 0 239616 123448 185436 464504 0 0 0 73 129 306 1 1 98 0 0

```
