From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: guix pull timing out on low resource servers Date: Mon, 15 May 2017 13:38:59 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dAELu-0004Ax-RH for guix-devel@gnu.org; Mon, 15 May 2017 07:39:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dAELq-0002Nx-Sp for guix-devel@gnu.org; Mon, 15 May 2017 07:39:50 -0400 Received: from pb-sasl1.pobox.com ([64.147.108.66]:56004 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dAELq-0001yR-Nb for guix-devel@gnu.org; Mon, 15 May 2017 07:39:46 -0400 In-Reply-To: (ng0@pragmatique.xyz's message of "Mon, 15 May 2017 10:12:01 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: ng0 Cc: guix-devel@gnu.org On Mon 15 May 2017 12:12, ng0 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