From: ludo@gnu.org (Ludovic Courtès)
To: Roel Janssen <roel@gnu.org>
Cc: guix-devel@gnu.org, 27097@debbugs.gnu.org
Subject: Performance on NFS
Date: Wed, 07 Jun 2017 12:35:06 +0200 [thread overview]
Message-ID: <87a85kt7ad.fsf_-_@gnu.org> (raw)
In-Reply-To: <87efuym57c.fsf@gnu.org> (Roel Janssen's message of "Tue, 06 Jun 2017 00:37:41 +0200")
Hi Roel,
Roel Janssen <roel@gnu.org> skribis:
>> That is going to make builds verrrry slow. I would suggest having
>> guix-daemon operate on the local /gnu (that’s what Ricardo did, IIRC).
>
> That definitely speeds things up about 50%. So, running the environment
> command from a node that is connected to the node that runs
> guix-daemon, will take about 30 seconds instead of one minute.
>
> This could be made faster by letting 'guix-daemon' do more of the work,
> and let the client-side 'guix' only do the minimum.
Right, but it’s the client that computes the derivation, which involves
quite a bit of I/O and computation.
> (I know.. this remote-guix-daemon stuff voids the warranty.. ;))
>
> The NFS overhead is pretty large. Maybe we can better tune it, and if
> so, document how to tune it for GNU Guix. I already talked to our
> storage expert, and tuning boils down to using fast disks, a
> large-enough NFS cache, and low-latency network equipment.
>
> The reason we have /gnu NFS-mounted on the build node is that we can
> then very easily replace the node when it would have a hardware failure,
> without even losing the ability to run programs that were already
> installed.
I guess you could also use a RAID device for /gnu/store. Or you could
have a local /gnu/store and replicate it elsewhere, maybe
opportunistically via ‘guix publish’.
>> We should make sure these 1782 calls are all warranted (e.g., make sure
>> we don’t open the same file twice; this could be easily diagnosed by
>> looking at the output of ‘strace’.)
>>
>> But then, as you say, it’s a process that opens lots of files.
>>
>> We could cache package lookups, and maybe that’d help a little bit.
>> Currently we use ‘fold-packages’, which loads every single package
>> module, and then we look for a package named “coreutils” among them;
>> with a cache, we could directly load (gnu packages base) and its
>> dependencies.
>>
>> Ludo’.
>
> Running 'guix package -A' only takes a couple of seconds. So I don't
> think that loading the Scheme modules is really a big issue.
How does:
time guix environment --ad-hoc coreutils --pure -- true
compare to:
time guix environment --ad-hoc -e '(@ (gnu packages base) coreutils)' --pure -- true
? That would give us an estimate of how much the cache I describe would
help.
Thanks,
Ludo’.
next prev parent reply other threads:[~2017-06-07 10:35 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-27 10:56 bug#27097: [PATCH] gnu: Add emacs-direnv Christopher Baines
2017-05-27 11:31 ` Combining Guix, direnv and Emacs for environment customisation Christopher Baines
2017-05-30 15:03 ` Ludovic Courtès
2017-05-30 15:03 ` bug#27097: " Ludovic Courtès
2017-06-01 13:17 ` Roel Janssen
2017-06-03 13:59 ` Ludovic Courtès
2017-06-03 13:59 ` bug#27097: " Ludovic Courtès
2017-06-03 21:08 ` Roel Janssen
2017-06-04 21:15 ` Ludovic Courtès
2017-06-04 21:15 ` bug#27097: " Ludovic Courtès
2017-06-05 22:37 ` Roel Janssen
2017-06-07 10:35 ` Ludovic Courtès [this message]
2017-06-07 13:06 ` Performance on NFS Roel Janssen
2017-06-09 13:46 ` Ludovic Courtès
2017-06-12 8:45 ` Roel Janssen
2017-06-12 8:45 ` [bug#27097] " Roel Janssen
2017-06-12 15:58 ` Ludovic Courtès
2017-06-16 15:23 ` Ludovic Courtès
2017-06-17 7:36 ` Roel Janssen
2017-06-17 22:40 ` Ludovic Courtès
2017-06-17 23:15 ` Roel Janssen
2017-06-18 8:43 ` Ricardo Wurmus
2017-06-19 8:01 ` RPC performance Ludovic Courtès
2017-06-19 8:15 ` Ludovic Courtès
2017-06-19 14:25 ` Ricardo Wurmus
2017-06-22 14:03 ` Andy Wingo
2017-06-22 16:05 ` Ludovic Courtès
2017-06-23 9:09 ` Andy Wingo
2017-06-23 9:24 ` Ludovic Courtès
2017-06-23 9:46 ` Andy Wingo
2017-06-26 11:54 ` Ludovic Courtès
2017-06-26 14:19 ` Andy Wingo
2017-06-19 21:25 ` Ludovic Courtès
2017-06-22 8:04 ` Ricardo Wurmus
2017-06-07 11:01 ` Combining Guix, direnv and Emacs for environment customisation Ricardo Wurmus
2017-06-07 12:25 ` Performance on NFS Ludovic Courtès
2017-06-07 12:59 ` Ricardo Wurmus
2017-06-07 12:59 ` bug#27097: " Ricardo Wurmus
2017-08-29 19:02 ` Combining Guix, direnv and Emacs for environment customisation Thompson, David
2017-08-29 22:30 ` Maxim Cournoyer
2017-08-30 5:52 ` Carlo Zancanaro
2017-08-30 10:09 ` Ludovic Courtès
2017-08-30 10:16 ` Ludovic Courtès
2017-05-28 20:09 ` bug#27097: [PATCH] gnu: Add emacs-direnv 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=87a85kt7ad.fsf_-_@gnu.org \
--to=ludo@gnu.org \
--cc=27097@debbugs.gnu.org \
--cc=guix-devel@gnu.org \
--cc=roel@gnu.org \
/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.