What's the memory resource?

Hi there, I’m using gitpod and running into memory issues.
I notice there is one env var GITPOD_MEMORY setting to 1879 and this makes JAVA VM maximum to 1897 as well.
From previous post,

it’s said to be 8GB, but my compiling failed due to this issue. I’m using bazel btw.

May I know what’s the current limit for memory?

Hi @iycheng, welcome to the Gitpod community! :tada:

Good catch! JAVA_TOOL_OPTIONS is indeed set based on GITPOD_MEMORY.

This 1.88 GB value is the current memory request (a Kubernetes concept), i.e. how much memory we expect Gitpod workspaces to typically use.

However, all Gitpod workspaces are allowed to use up to 12.88 GB (the current memory limit) before any safeguard mechanism kicks in. (If your workspace uses more than 12.88 GB, the Linux OOM-killer will start killing your top-RAM-consuming processes until your workspace goes below 12.88 GB again.)

Hi @jan
Thanks for the reply!
If I understand it correctly, do you mean that I can unset JAVA_TOOL_OPTIONS? Right now, I can only use 4 parallel builds for my repo :frowning:
I have two other questions actually:

  • for prebuild job, do we have this limitation?
  • if I click ‘Don’t wait for prebuild’, will it smartly use one of the prebuild before that commit?

Apologies for intruding on this post, but I’m just quite curious as to what the request and limit for hosted pods are in terms of CPU and disk space?

Hi @iycheng, you’re quite welcome!

Yes, I think that should be possible. But since JAVA_TOOL_OPTIONS is being set in your /home/gitpod/.bashrc, you may want to unset (or modify) it there too, e.g. by appending to /home/gitpod/.bashrc from your .gitpod.yml tasks.

Prebuilds indeed have the same memory limit, so the OOM-killer will also kick in at around 12.88 GB RAM usage.

However, Prebuilds have a higher memory request (about 4.83 GB, which also translates to GITPOD_MEMORY and JAVA_TOOL_OPTIONS there) in order to pack them more sparsely on Gitpod’s headless nodes.

Haha, funny you should ask, because I’m currently implementing such a feature: Incremental Prebuilds.

But currently in production, when you click on Don't Wait for Prebuild, it will give you a totally unbuilt workspace (i.e. any before / prebuild / init tasks will only start running live in your fresh workspace).

Hi @erasmuswill, welcome to this thread! And sure:

  • The CPU limit is 6 vCPUs per workspace. (However, please note that there is also a fair-use policy that kicks in and temporarily throttles your CPU if you use 100% of all CPU for several minutes – unless you have the Unleashed paid plan that is.)

  • The disk space limit is currently 30 GB (but I think that doesn’t make sense and we should raise it to 50 GB).

Hope this helps!


@jan Thanks for replying! I’m really exciting about the incremental builds feature! That’s very useful and should save a lot of resources&time as well!

1 Like