unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Mathieu Othacehe <othacehe@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 50040@debbugs.gnu.org
Subject: [bug#50040] [PATCH 0/2] publish: Always render nar/narinfo during backing.
Date: Fri, 17 Sep 2021 17:27:04 +0200	[thread overview]
Message-ID: <87zgsbuss7.fsf@gnu.org> (raw)
In-Reply-To: <87tuix7qsw.fsf_-_@gnu.org> ("Ludovic Courtès"'s message of "Mon, 06 Sep 2021 15:54:23 +0200")


Hey Ludo,

> The ‘mumi worker’ process also seems to be doing a lot of I/O and using
> quite a bit of CPU (presumably allocating a lot).  Its ‘perf’ profile is
> like this:
>
>    2.62%  .mumi-real  libguile-3.0.so.1.1.1  [.] scm_ilength
>    1.20%  .mumi-real  libguile-3.0.so.1.1.1  [.] scm_getc
>    1.12%  .mumi-real  libgc.so.1.4.3         [.] GC_add_to_black_list_normal.part.4
>    1.06%  .mumi-real  libgc.so.1.4.3         [.] GC_build_fl
>    0.98%  .mumi-real  libgc.so.1.4.3         [.] GC_reclaim_clear
>    0.97%  .mumi-real  libguile-3.0.so.1.1.1  [.] get_callee_vcode
>    0.91%  .mumi-real  libgc.so.1.4.3         [.] GC_generic_malloc_many
>    0.90%  .mumi-real  libguile-3.0.so.1.1.1  [.] peek_byte_or_eof
>    0.78%  .mumi-real  [JIT] tid 62601        [.] 0x00007f886964804d
>
> Food for thought…

Yep, interesting findings, thanks for sharing. I just discovered that
the Nginx server is logging in /var/log/nginx/error.log the errors we
are interested in:

--8<---------------cut here---------------start------------->8---
2021/09/17 14:13:37 [error] 129925#0: *3727055 upstream timed out (110: Connection timed out) while reading response header from upstream, client: XXX, server: ci.guix.gnu.org, request: "GET /3m1j4ddx11
prp6azw3rjdhljg5vchf1s.narinfo HTTP/1.1", upstream: "http://127.0.0.1:3000/3m1j4ddx11prp6azw3rjdhljg5vchf1s.narinfo", host: "ci.guix.gnu.org"
2021/09/17 14:13:37 [error] 129925#0: *3727020 upstream timed out (110: Connection timed out) while reading response header from upstream, client: XXX, server: ci.guix.gnu.org, request: "GET /pdhr7fgql3
qm1x24yxkj4c2f6s7vffi5.narinfo HTTP/1.1", upstream: "http://127.0.0.1:3000/pdhr7fgql3qm1x24yxkj4c2f6s7vffi5.narinfo", host: "ci.guix.gnu.org"
2021/09/17 14:13:37 [error] 129925#0: *3726717 upstream timed out (110: Connection timed out) while reading response header from upstream, client: XXX, server: ci.guix.gnu.org, request: "GET /19gv6sq
qcmn8q020bpm9jyl6n9bjpg05.narinfo HTTP/1.1", upstream: "http://127.0.0.1:3000/19gv6sqqcmn8q020bpm9jyl6n9bjpg05.narinfo", host: "ci.guix.gnu.org"
2021/09/17 14:13:37 [error] 129925#0: *3725361 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 141.80.167.169, server: ci.guix.gnu.org, request: "GET /y8dp69gk
y4dn5vnn7wnx04j20q0yrdja.narinfo HTTP/1.1", upstream: "http://127.0.0.1:3000/y8dp69gky4dn5vnn7wnx04j20q0yrdja.narinfo", host: "141.80.167.131"
--8<---------------cut here---------------end--------------->8---

Despite the following diff, extending the timeout delays to 10 seconds,
we still have a lot of those errors. Some happening on the build farm
(141.80.167.X), some directly on user machines.

--8<---------------cut here---------------start------------->8---
diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index 44ff28e..7a085e5 100644
--- a/hydra/nginx/berlin.scm
+++ b/hydra/nginx/berlin.scm
@@ -97,9 +97,9 @@
 
            ;; Do not tolerate slowness of hydra.gnu.org when fetching
            ;; narinfos: better return 504 quickly than wait forever.
-           "proxy_connect_timeout 2s;"
-           "proxy_read_timeout 2s;"
-           "proxy_send_timeout 2s;"
+           "proxy_connect_timeout 10s;"
+           "proxy_read_timeout 10s;"
+           "proxy_send_timeout 10s;"
--8<---------------cut here---------------end--------------->8---

I'll see if I can reproduce the I/O pressure on demand, to be able to
have more accurate strace/perf investigations.

Thanks,

Mathieu




  reply	other threads:[~2021-09-17 15:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13 10:28 [bug#50040] [PATCH 0/2] publish: Always render nar/narinfo during backing Mathieu Othacehe
2021-08-13 10:30 ` [bug#50040] [PATCH 1/2] publish: Defer narinfo string creation to the http-write Mathieu Othacehe
2021-08-13 10:30   ` [bug#50040] [PATCH 2/2] publish: Remove cache bypass support Mathieu Othacehe
2021-08-30 22:31   ` [bug#50040] [PATCH 0/2] publish: Always render nar/narinfo during backing Ludovic Courtès
2021-08-31  9:08     ` Mathieu Othacehe
2021-09-01 20:48       ` Ludovic Courtès
2021-10-06  8:58   ` Mathieu Othacehe
2021-10-08  7:04     ` Mathieu Othacehe
2021-08-22  7:33 ` Mathieu Othacehe
2021-08-30 22:33   ` Ludovic Courtès
2021-09-06 13:54     ` Ludovic Courtès
2021-09-17 15:27       ` Mathieu Othacehe [this message]
2021-10-05 10:07         ` Mathieu Othacehe

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87zgsbuss7.fsf@gnu.org \
    --to=othacehe@gnu.org \
    --cc=50040@debbugs.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).