Mix deps.get eats all memory

gVolop

i have the same issue like here Hex v0.20.2-5 eats all memory and dies, but maybe it is us - #4 by outlog

When i try to execute mix.deps.get after removing mix.lock, the terminal hangs at Resolving Hex dependencies... . The process then starts to eat all available memory and swap …

my-app|qa⚡ ⇒ mix hex.info
Hex:  0.20.5
Elixir: 1.9.4
OTP:  22.1.4

Built with: Elixir 1.9.4 and OTP 22.1.4

my-app|qa⚡ ⇒ mix deps.get                                    
* Updating google_api_storage (https://github.com/DinaWork/google-api-storage.git)
* Updating google_auth (https://github.com/DinaWork/google-auth.git)
* Updating paranoid (https://github.com/echobind/paranoid.git)
Resolving Hex dependencies...

it’s umbrella with ~30 apps

i think it started after i update hex to 0.20.2
but now, even if i trying to change it back to lower version - i still have the same issue.

20 comments

#hex

2 4472 20

2022-11-10 12:33:34 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

josevalim

Creator of Elixir

Those issues are caused by the dependency resolution algorithm. It means the search space is too big and finding suitable solutions takes too long. The simplest suggestion to address this is to constraint your dependencies. For example, if you have Ecto ~> 3.0, update to latest Ecto ~> 3.6 and so on.

If you have a lock file, then update your deps in groups, doing mix deps.update phoenix ecto instead of passing the --all flag.

We have some possible improvements in mind for dependency resolution but, if the search space is too big, ultimately there won’t be much we can do.

Post #1

Lihemen

I have a similar issue like yours on an 8GB RAM Ubuntu 21.0.4 system.

mix deps.get hangs at Resolving dependencies until the terminal gets tired and kills it.

I’m trying to set up a new Pheonix Liveview Project using Pheonix 1.5.12 and Elixir 1.10.3 (compiled with Erlang/OTP 22).

ANY help would be appreciated.

Post #2

gVolop

you have an answer from @josevalim.. Mix deps.get eats all memory - #2 by josevalim this is the solution.

Post #3

amcvitty

A key point I learned from this thread is that if you have a mix.lock file already, then this dependency resolution isn’t necessary, so you won’t run out of memory.

So if you’re having this problem on your server, try running on your development machine and committing the mix.lock.

(I came across this thread while trying out deploying a phoenix app on a tiny free google cloud server, and my first thought was to just run phx.new and fire it up, which didn’t work because it didn’t have the memory to run mix deps.get)

Post #4

lud

Got this issue yesterday after deleting the mix.lock because of version conflict.

I commented all my deps, decommenting each deps, one at a time, and calling mix.deps get each time

Post #5

ericmj

Elixir Core Team

This is the right approach, you should always commit your mix.lock file.

Post #6

ericmj

Elixir Core Team

We are working on a fix to this issue but it requires a full rewrite of the resolver algorithm so unfortunately it will take some time until it is released and in production quality.

In the mean time make sure you always commit your mix.lock file and follow the instructions here if you run into issues.

Post #7

gVolop

sure, we always commit it.
but sometimes, if you have dependencies version conflict - you need to remove the .lock file …

in my case - when i had to remove the lock file - i got this issue in my local mac (not in dock/any deployment env) - so @josevalim answer solved it for me, (updating the Ecto version was enough)

Post #8

LostKobrakai

You can also unlock individual dependencies using mix deps.unlock package.

Post #9

ericmj

Elixir Core Team

You don’t have to remove the mix.lock when you have conflicts. Mix won’t write a lockfile if the resolution has conflicts. Instead unlock or update the individual deps that are conflicting.

Post #10

Load more posts (10 remaining)