Rails console makes app Out Of Memory and restarts

1

[Original title: “No Rakefile found”, cannot run rails db:seed command and cannot run console]

I have successfully deployed an existing Rails app with Fly.

It’s a Rails 7 app, I have kept the Dockerfile and the fly.toml but removed the Node/yarn parts in them as I don’t use Node (importmaps instead)

When I try to run fly ssh console -C "/app/bin/rails console", most of the time the process hangs and I just cannot access the console, sometimes it takes very long, I access the prompt but trying to write anything kicks me out.
I also usually get Out of memory: Killed process 515 (bundle) total-vm:246060kB, anon-rss:106508kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:496kB oom_score_adj:0, my Rails app is extremely light but it seems like I cannot really use it with free tier.

When I try to run fly ssh console -C "/app/bin/rails db:seed", I get this error:

rails aborted!
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)

but I have a Rakefile in my project.

Edit: By entering the image and executing bundle from within, I managed to run the seed:

$> fly ssh console
# cd /app
# bundle exec rails db:seed

Anyone had the same issues and solved them?

2

I scaled to a 512MB VM: turns out console requires 90MB of memory to work.
Screenshot 2022-08-28 at 20.57.48

Does anyone know how I can reduce my app’s memory usage so I can rollout a Rails app using free tier? I want to migrate my infra from Heroku, but I have multiple apps for staging or small apps that used Heroku Free Tier and that was enough.

3

Rails is a memory hog. We have some ideas for making rails console work without consuming so much memory, but right now it’s going to be hard to do much with Rails in a 256MB VM.

However, adding memory is pretty cheap. It’s like ~$1.25/mo to upgrade a VM to 512MB of RAM. You still get the free 3 VMs per month, so doing all three at 512MB of RAM would be less than $5/mo.

Heroku’s free tier is not something we can emulate, so we tried very hard to make it cheap to run VMs once you get beyond the free tier. We have some changes coming that will help even more (suspending idle VMs and not billing for them, more memory flexibility, etc).

Also one feature we offer that’s not obvious: all your apps can share the same Postgres. We setup a full Postgres server that can handle multiple DBs for you. You can run fly pg attach to get a new app hooked into it. It’s pretty useful for running a bunch of lightweight projects on the cheap.

2 Likes
4

Thank you @kurt for your reply. Yes, I was surprised by the amount of RAM required by rails console and I am very curious about know you’ll be working on this.

I was not aware of one Postgres server to rule them all, that is a very interesting feature indeed!

5

@wjordan has an experiment for making Puma fork the process for Rails console: GitHub - wjordan/puma-fork_eval: Puma plugin to fork-eval Ruby code in a preloaded application process. Like `spring` for production!

This would theoretically make the console share memory with the existing Rails process, rather than loading everything into memory a second time.

1 Like
6

I believe Heroku dynos have a good chunk of swap available to them by default (100% of their memory quota), making OOM events less common in their smallest configurations. Fly.io VMs don’t have any swap configured by default which makes them more sensitive to fluctuations in memory usage.

It’s a bit of a manual process, but you can add a swapfile with a few commands at runtime using fallocate, mkswap and swapon: Swap memory - #2 by OldhamMade

1 Like