GNU bug report logs - #48178
Out of memory error when generating a docker-image.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48178 in the body.
You can then email your comments to 48178 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Roel Janssen <roel <at> gnu.org>
To: bug-guix <at> gnu.org
Subject: Out of memory error when generating a docker-image.
Date: Mon, 03 May 2021 00:09:36 +0200

[Message part 1 (text/plain, inline)]

Dear Guix,

While generating a docker-image that contains only a sshd service, an
nginx service, and an iptables service, it seems the VM that is spawned
to generate a docker image was allocated too little memory.  I attached
the log file.

Looking at 'guix/scripts/system.scm', it seems that we always pass 256M
of memory to the VM.  After bumping that to 4096M, I was able to
produce a docker image.

I'd like to see what we can do here.  Assigning too little memory leads
to problems generating the container, but assigning too much memory wil
l cause problems for computing machines that don't have much memory to
spare.

Would it be a good idea to make it configurable at run-time?

Kind regards,
Roel Janssen

[guix-docker-image.log (text/x-log, attachment)]

Message #8 received at 48178 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Roel Janssen <roel <at> gnu.org>
Cc: 48178 <at> debbugs.gnu.org
Subject: Re: bug#48178: Out of memory error when generating a docker-image.
Date: Mon, 3 May 2021 12:39:04 -0400

On Mon, May 03, 2021 at 12:09:36AM +0200, Roel Janssen wrote:
> Looking at 'guix/scripts/system.scm', it seems that we always pass 256M
> of memory to the VM.  After bumping that to 4096M, I was able to
> produce a docker image.

Can you test somes values that are in between? Like, 512M, 1024M, etc,
until we know how much is actually required? If 512M is enough, I don't
see a problem with increasing the hard-coded value to that.

> I'd like to see what we can do here.  Assigning too little memory leads
> to problems generating the container, but assigning too much memory wil
> l cause problems for computing machines that don't have much memory to
> spare.

There are some use cases for this code that we'd like to work on
low-resource machines (`guix system vm`), and other use cases (like
building Docker images) that shouldn't be expected to work on machines
with limited RAM.

> Would it be a good idea to make it configurable at run-time?

Yeah, maybe.

Message #11 received at 48178 <at> debbugs.gnu.org (full text, mbox):

From: Roel Janssen <roel <at> gnu.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 48178 <at> debbugs.gnu.org
Subject: Re: bug#48178: Out of memory error when generating a docker-image.
Date: Mon, 03 May 2021 19:47:49 +0200

[Message part 1 (text/plain, inline)]

On Mon, 2021-05-03 at 12:39 -0400, Leo Famulari wrote:
> On Mon, May 03, 2021 at 12:09:36AM +0200, Roel Janssen wrote:
> > Looking at 'guix/scripts/system.scm', it seems that we always pass
> > 256M
> > of memory to the VM.  After bumping that to 4096M, I was able to
> > produce a docker image.
> 
> Can you test somes values that are in between? Like, 512M, 1024M,
> etc,
> until we know how much is actually required? If 512M is enough, I
> don't
> see a problem with increasing the hard-coded value to that.
> 

I monitored the VM's memory usage and it peaked at 1.6G. But after
testing, it seems 1024 also works.

I tested with 2048 (worked), 1024 (worked), and 512 (didn't work).

> > I'd like to see what we can do here.  Assigning too little memory
> > leads
> > to problems generating the container, but assigning too much memory
> > wil
> > l cause problems for computing machines that don't have much memory
> > to
> > spare.
> 

In that case... The attached patch would only increase the size when
generating a Docker container image.  Would that be acceptable?

> There are some use cases for this code that we'd like to work on
> low-resource machines (`guix system vm`), and other use cases (like
> building Docker images) that shouldn't be expected to work on
> machines
> with limited RAM.
> 
> > Would it be a good idea to make it configurable at run-time?
> 
> Yeah, maybe.
> 

I think it'd be better to have it somehow dynamically increase, but I
don't see how I could determine the VM size needed for a given system
configuration.  So perhaps the attached patch is an acceptable
compromise.

Kind regards,
Roel Janssen

[0001-guix-scripts-system-Increase-the-size-for-generating.patch (text/x-patch, attachment)]

Message #14 received at 48178 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Roel Janssen <roel <at> gnu.org>
Cc: 48178 <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#48178: Out of memory error when generating a docker-image.
Date: Mon, 10 May 2021 10:29:14 +0300

[Message part 1 (text/plain, inline)]

On Mon, May 03, 2021 at 07:47:49PM +0200, Roel Janssen wrote:
> On Mon, 2021-05-03 at 12:39 -0400, Leo Famulari wrote:
> > On Mon, May 03, 2021 at 12:09:36AM +0200, Roel Janssen wrote:
> > > Looking at 'guix/scripts/system.scm', it seems that we always pass
> > > 256M
> > > of memory to the VM.  After bumping that to 4096M, I was able to
> > > produce a docker image.
> > 
> > Can you test somes values that are in between? Like, 512M, 1024M,
> > etc,
> > until we know how much is actually required? If 512M is enough, I
> > don't
> > see a problem with increasing the hard-coded value to that.
> > 
> 
> I monitored the VM's memory usage and it peaked at 1.6G. But after
> testing, it seems 1024 also works.
> 
> I tested with 2048 (worked), 1024 (worked), and 512 (didn't work).
> 
> > > I'd like to see what we can do here.  Assigning too little memory
> > > leads
> > > to problems generating the container, but assigning too much memory
> > > wil
> > > l cause problems for computing machines that don't have much memory
> > > to
> > > spare.
> > 
> 
> In that case... The attached patch would only increase the size when
> generating a Docker container image.  Would that be acceptable?
> 
> > There are some use cases for this code that we'd like to work on
> > low-resource machines (`guix system vm`), and other use cases (like
> > building Docker images) that shouldn't be expected to work on
> > machines
> > with limited RAM.
> > 
> > > Would it be a good idea to make it configurable at run-time?
> > 
> > Yeah, maybe.
> > 
> 
> I think it'd be better to have it somehow dynamically increase, but I
> don't see how I could determine the VM size needed for a given system
> configuration.  So perhaps the attached patch is an acceptable
> compromise.
> 
> Kind regards,
> Roel Janssen
> 

Looks good to me!

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Message #19 received at 48178-done <at> debbugs.gnu.org (full text, mbox):

From: Roel Janssen <roel <at> gnu.org>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 48178-done <at> debbugs.gnu.org, Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#48178: Out of memory error when generating a docker-image.
Date: Mon, 10 May 2021 09:46:25 +0200

On Mon, 2021-05-10 at 10:29 +0300, Efraim Flashner wrote:
> On Mon, May 03, 2021 at 07:47:49PM +0200, Roel Janssen wrote:
> > On Mon, 2021-05-03 at 12:39 -0400, Leo Famulari wrote:
> > > On Mon, May 03, 2021 at 12:09:36AM +0200, Roel Janssen wrote:
> > > > Looking at 'guix/scripts/system.scm', it seems that we always
> > > > pass
> > > > 256M
> > > > of memory to the VM.  After bumping that to 4096M, I was able
> > > > to
> > > > produce a docker image.
> > > 
> > > Can you test somes values that are in between? Like, 512M, 1024M,
> > > etc,
> > > until we know how much is actually required? If 512M is enough, I
> > > don't
> > > see a problem with increasing the hard-coded value to that.
> > > 
> > 
> > I monitored the VM's memory usage and it peaked at 1.6G. But after
> > testing, it seems 1024 also works.
> > 
> > I tested with 2048 (worked), 1024 (worked), and 512 (didn't work).
> > 
> > > > I'd like to see what we can do here.  Assigning too little
> > > > memory
> > > > leads
> > > > to problems generating the container, but assigning too much
> > > > memory
> > > > wil
> > > > l cause problems for computing machines that don't have much
> > > > memory
> > > > to
> > > > spare.
> > > 
> > 
> > In that case... The attached patch would only increase the size
> > when
> > generating a Docker container image.  Would that be acceptable?
> > 
> > > There are some use cases for this code that we'd like to work on
> > > low-resource machines (`guix system vm`), and other use cases
> > > (like
> > > building Docker images) that shouldn't be expected to work on
> > > machines
> > > with limited RAM.
> > > 
> > > > Would it be a good idea to make it configurable at run-time?
> > > 
> > > Yeah, maybe.
> > > 
> > 
> > I think it'd be better to have it somehow dynamically increase, but
> > I
> > don't see how I could determine the VM size needed for a given
> > system
> > configuration.  So perhaps the attached patch is an acceptable
> > compromise.
> > 
> > Kind regards,
> > Roel Janssen
> > 
> 
> Looks good to me!
> 

Thank you for looking at it!  I pushed the proposed patch in
ce3d05cc08c01351756ab5d5b7f25cfe0295c230.

Kind regards,
Roel Janssen

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.