From: Mathieu Othacehe <othacehe@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: Improving CI throughput
Date: Tue, 25 Aug 2020 15:32:50 +0200 [thread overview]
Message-ID: <87eenuu9z1.fsf@gnu.org> (raw)
In-Reply-To: <877dto2jhw.fsf_-_@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Mon, 24 Aug 2020 16:42:19 +0200")
Hey,
> Yeah, this is a ridiculous situation. We should do a hackathon to get
> better monitoring of useful metrics (machine load,
> time-of-push-to-time-to-build-completion, etc.), to clearly identify the
> bottlenecks (crashes? inefficient protocol? scheduling issues? Cuirass
> or offload or guix-daemon issue?), and to address as many of them as we
> can.
>
> Any volunteers? :-)
I'd really like to improve the situation! A hackathon seems like a
nice idea.
As a matter of fact, I already spent some times improving the stability
of Cuirass web interface[1].
Now I can see multiple topics that could be approached in parallel:
* Add metrics to Cuirass as you suggested. There's an open ticket about
that here[2].
* Investigate offloading issues[3].
* Fix database contention[4].
* Fix guix-daemon deadlocking[5].
* Monitor closely what's happening on Berlin and decide if it is
opportune to add a build scheduler mechanism somewhere. See what Hydra
is doing[6] and what Chris is proposing[7].
As most of the issues are only observed on Berlin machines, which access is
restricted, we will also have to find a way to reproduce them locally.
Anyway, if some people are motivated, we could try to plan a day or
week-end to work on those topics :).
Thanks,
Mathieu
[1]: https://issues.guix.gnu.org/42548.
[2]: https://issues.guix.gnu.org/32548.
[3]: https://issues.guix.gnu.org/34033.
[4]: https://issues.guix.gnu.org/42001.
[5]: https://issues.guix.gnu.org/31785.
[6]: https://github.com/NixOS/hydra/blob/master/src/hydra-queue-runner/dispatcher.cc
[7]: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00323.html
next prev parent reply other threads:[~2020-08-25 13:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 10:31 ARM build machines Jonathan Brielmaier
2020-07-28 12:55 ` Mathieu Othacehe
2020-08-24 14:42 ` Improving CI throughput Ludovic Courtès
2020-08-24 14:57 ` John Soo
2020-08-25 13:32 ` Mathieu Othacehe [this message]
2020-08-25 17:44 ` Ricardo Wurmus
2020-08-28 13:51 ` 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=87eenuu9z1.fsf@gnu.org \
--to=othacehe@gnu.org \
--cc=guix-devel@gnu.org \
--cc=ludo@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.