all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andy Wingo <wingo@igalia.com>
To: ng0 <ng0@pragmatique.xyz>
Cc: guix-devel@gnu.org
Subject: Re: guix pull timing out on low resource servers
Date: Mon, 15 May 2017 13:38:59 +0200	[thread overview]
Message-ID: <cucy3ty9woc.fsf@igalia.com> (raw)
In-Reply-To: <nycvar.YAK.7.76.1705151011190.11797@ybpnyubfg> (ng0@pragmatique.xyz's message of "Mon, 15 May 2017 10:12:01 +0000")

On Mon 15 May 2017 12:12, ng0 <ng0@pragmatique.xyz> writes:

> Since the switch to Guile 2.2 and guix pull taking much more
> computing time and resources, all my virtual hosting servers
> time out when I run guix pull on them without using mosh
> and just openssh, because the process just takes much too
> long.
>
> I doubt I'm the only one who experiences this, and just
> increasing the server specs for this process is pointless
> for what they run.
> It's even worse than that, in the future there will be just
> one DNS server running GuixSD, this requires minimal resources.
> Should I just never update these devices or "just get a real
> server"?

I have the smallest DigitalOcean droplet size with a swap partition, and
things work for me I think.  Takes a while though.

There will always be some machines that won't be able to "guix pull"
because of resource constraints.  But I think they are in a minority and
they don't include e.g. the smallest DigitalOcean droplets.

In the meantime we need to rework "build-all.scm" I think to not incur
an O(N) memory usage in the size of the guix package set by
topologically sorting the files (I know there are cycles, but the
general approach should improve things), and by forking off and
compiling the files in separate processes instead of doing everything
from one process (albeit with many threads).  Additionally there are
some compiler speedups in Guile to be had (notably the "basic register
allocation" task from
https://wingolog.org/archives/2016/02/04/guile-compiler-tasks).

And in the meantime-meantime, the workaround is to use a swap file that
is as large as necessary.

Andy

  reply	other threads:[~2017-05-15 11:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15 10:12 guix pull timing out on low resource servers ng0
2017-05-15 11:38 ` Andy Wingo [this message]
2017-05-15 12:30   ` ng0
2017-05-16  7:39     ` ng0
2017-05-16 19:46 ` Leo Famulari
2017-05-17 12:39   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cucy3ty9woc.fsf@igalia.com \
    --to=wingo@igalia.com \
    --cc=guix-devel@gnu.org \
    --cc=ng0@pragmatique.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.