Memory use in Redwood v6

I recently upgraded my project from the v6 RC to the official 6.0.6 version. I’m hosting my project on Render.com and I’m using the free tier while I prototype, so I have a tiny CPU/RAM etc. But in any case, I’m seeing intermittent out-of-memory errors, and I don’t think anything changed on the frontend aside from the upgrade. Error message:

Server unhealthy

Ran out of memory (used over 512MB) while running your code.

512MB is tiny, to be sure, but I’m curious if there is something larger than expected in 6.0.6 vs the v6 RC.

Hmm, the only time I’ve seen this memory limit error is during deployment. For hobby/dev projects, based on my experience, agreed you should be ok. But :man_shrugging:

Do try the latest patched version for v6, v6.0.7 and let me know if there’s any improvements. The performance fixes are mostly for AWS Lambda infra, but maybe they were also affecting Render if just subtly.

That’s true, I’ve only seen it in deployment so far as well.

I tried v6.0.7 tonight and still ran into the same issue though (on the Render.com free tier, again) – but on retry the deployment was successful.

I’ve upgraded to 6.2.0, but I’m still having memory errors during deployment. I think it’s due to DB migrations though. The log has errors like this, where I think the exit code 137 is the out of memory error.

I haven’t been making any DB migrations recently; I think these are all old from initial schema development. Any ideas if this memory error is expected, when I’m running with only 512 MB RAM?

I could upgrade to 2GB on render.com but I wasn’t sure if this was the problem or if I’m doing something wrong. Also the prices for a mere 2GB of ram seem steeper than I expected, so maybe I should look around for other deployment options, but that’s a different story!

Sep 10 11:09:14 PM 2 migrations found in prisma/migrations
Sep 10 11:09:14 PM
Sep 10 11:09:14 PM
Sep 10 11:09:14 PM No pending migrations to apply.
Sep 10 11:09:23 PM Installing plugin “@redwoodjs/cli-data-migrate”…
Sep 10 11:09:39 PM Killed
Sep 10 11:09:39 PM /opt/render/project/src/node_modules/execa/lib/error.js:60
Sep 10 11:09:39 PM error = new Error(message);
Sep 10 11:09:39 PM ^
Sep 10 11:09:39 PM
Sep 10 11:09:39 PM Error: Command failed with exit code 137: yarn rw dataMigrate up

Ah yeah I have the same problem with my Build Competition’s project deployment - didn’t want to deal with it so for the month I’m on the 2gb plan, but it is quite expensive for a hobby project.

Redwood shouldn’t be running out of memory with only one user, definitely seems like something is off. I haven’t had this issue with a larger project with more users that’s still on v5 - haven’t wanted to upgrade yet specifically because of this issue.

I haven’t tried this out yet, but this is what the Render team suggested:

To prevent NodeJS’s underlying V8 engine from allocating more heap space memory than what your service allows for, try setting an NODE_OPTIONS environment variable with the value --max-old-space-size=1536 . Change the value to 920 for a 1GB instance and 460 for a 512MB instance. These values are just rough guides, you may be able to increase it or need to lower it depending on how your application uses its memory.

If this doesn’t help, we have a blog article on how you can remoting debug NodeJS applications here: Remote Debugging with SSH and VS Code | Render

Thanks for the suggestions here. I tried several values of --max-old-space-size but never was able to get this working.

I’m going to try to switch over to Vercel and see if that works any better. My only concern is that its Postgres and Python serverless options are both in “Beta”. I have a separate python backend API so I really need python, but I think serverless might be better anyway if I can get it working.

I’m only aware of tests eating into memory quiet badly, but that might be connected.