Cannot install erlang 20.3.8.23

you can add swap so the server can “survive” the compile..

maybe erlang 22.1 is more effective during compile.. did you install that using asdf as well?

after a total of 364257280 bytes

that is only ~350 mb - is something else using memory? (postgres? running beam?)

1 GiB is usually not enough to compile programs of this size. It might help but does not necessarily have to, when you force to use not more than a single compiling job. I’m not sure if asdf gives you the possibility to so though. Something comparable to makes -j flag.

Alternatively you can try to give that machine about 4 to 8 gigs of swap. If it is only for temprary use, then just using a swap file should be enough, though compiling might take forever.

The third possibility is to scale up your droplet temporary (CPU/mem only, NO disk!) and scale down after the compile job has succeeded.

And last but not least there is number 4. Use a docker image locally which is configured very closely to your droplet to build the desired version of erlang. Extract the artifacts from the resulting image and push them to the droplet such that asdf is able to find them. I’m not sure how asdf keeps track of installed versions though. If you are out of luck, you’ll need to manually edit the database file that keeps track of installed versions.

After reading the article and @NobbZ opinion I have opted for temporarily resizing the droptlet so as to have 4GB of RAM instead of 1GB.

If this is not enough I will consider other options, although swapping is not recommended because it can make the droplet unstable.

I have also checked the RAM usage and I can confirm that at one point during the compilation, it definitely runs out of RAM. Because the machine has no Swap, it then crashes.

I am now resizing the droplet, lets see how it goes !

I have resized my droplet and compiled erlang. It worked. My droplet now has 4gb of RAM and costs 4x as much.

Initially I didn’t think this was going to be an issue, after all, this is just a temporary scale up (I thought).

Unfortunately for me, as I later found out, I’m not able to downsize the droplet as the official article mentioned. I’m stuck with a droplet that will cost me 4x as much and the only thing I can do is to scp the files I want to a smaller instance, which is incredibly disappointing.

Doing so will not only take hours(which I pay for, obviously) it also requires me to know where asdf places all the releases and scp them manually.

In hindsight, resizing the droplet was a terrible mistake, I should have simply created a 3GB swap partition and let the SSD drive take the heat.

I hope my experience helps someone in the future!

There’s an ASDF_CONCURRENCY variable documented, but it pretty much depends on plugins to actually use it.

So far I never had any problems downscaling, though I did so only a handful of times when experimenting around.

The important thing is to not resize the Harddisk, as resizing it will make the action irreversible.

This is actually the default mode on digital ocean. Resizing a droplet raises the disk size no matter what is you use the standard plan, which I do.

I tried again, I resized my 5 USD droplet to a 10 USD one, booted into it, run some random commands, powered down and resized back to a 5 USD one…

And now I will destroy this testmachine again before I get billed to much for it.

And its just as I said, “Resize CPU and RAM only” has to be choosen. For me the option with disk size included was preselected.

Did exactly the same thing, can’t resize down now. Maybe it has to do with the availability of the zone?

Do you need wx? If not, then pass --without-wx to configure and it will not build.