Re: guix pull timing out on low resource servers

[ng0 <ng0@pragmatique.xyz>]

On Mon, 15 May 2017, Andy Wingo wrote:

> 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

server 1: 1024MB RAM, 2048MB Swap, 4 cores.
server 2: 512MB RAM, 4096MB Swap, 2 cores.

Didn't fail before.. of course I can try to increase the swap, but I doubt 
that this really help.

Both systems were able to pull before we used 2.2

I even compiled most of the system on one of them as substitutes weren't 
available, so resources aren't the problem.