all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "Mark Schouten" <mark@tuxis.nl>
To: "Thomas Lamprecht" <t.lamprecht@proxmox.com>,
	"Proxmox Backup Server development discussion"
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] Scheduler causing connectivity issues?
Date: Mon, 18 Jul 2022 07:31:41 +0000	[thread overview]
Message-ID: <em8c48fb27-3367-4e7f-9adf-09bac2c8390e@e231eb23.com> (raw)
In-Reply-To: <4a05245f-6bd1-02da-f600-9976c4f1abf5@proxmox.com>

Hi,

>You have 30% of runnable process getting stalled due waiting for IO, that
>naturally should not cause the request accept future to get starved but is
>the reason for why it happened with the current (or better old)
>architecture. Increasing available memory, so that the page cache can hold
>more entries, could already relieve that system a bit.

Thanks. Please note that /var/lib/proxmox is on a different set of disks 
than the datastores. Root pool is on two PM883’s, datastore is lots of 
spinning disks with nvme-special devices. Not sure if that’s relevant in 
your findings, but here you have it :)

Memory upgrade is somewhere on our roadmap.

>We improved on the reproducer we got locally by simulating a higher latency
>disk using dm-delay on a small single core VM.
>
>For one we made the libpve-storage-perl do more efficient list-snapshot
>requests if they can be filtered by VMID, and on the PBS side we moved most
>operations that cause IO (and are related to backup groups/snapshots) to a
>separate thread pool so that the main thread should be less
>congested/blocked.
Given the other responses in this thread, I’m not going to upgrade yet 
to a testing-version in production. Please let me know if there is any 
other info you need from me.

—
Mark Schouten, CTO
Tuxis B.V.
mark@tuxis.nl





  parent reply	other threads:[~2022-07-18  7:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-07 15:49 Mark Schouten
2022-07-08  7:09 ` Thomas Lamprecht
2022-07-08  9:36   ` Jorge Boncompte
2022-07-08  9:40     ` dea
2022-07-11  8:44   ` Mark Schouten
2022-07-13  7:55     ` dea
2022-07-13  8:14     ` Thomas Lamprecht
2022-07-13 10:41       ` Mark Schouten
2022-07-15 11:49         ` Thomas Lamprecht
2022-07-15 12:01           ` dea
2022-07-15 12:57             ` Thomas Lamprecht
2022-07-15 13:02               ` dea
2022-07-15 13:24                 ` dea
2022-07-15 14:43                   ` dea
2022-07-17 15:04                   ` dea
2022-07-18 13:30                     ` Thomas Lamprecht
2022-07-19 11:01                       ` David Lawley
2022-07-19 13:04                         ` Thomas Lamprecht
2022-07-19 15:08                           ` dea
2022-07-18  7:31           ` Mark Schouten [this message]
2022-07-18 11:03             ` Thomas Lamprecht
2022-07-20  7:30               ` Mark Schouten
2022-07-21 13:10                 ` Thomas Lamprecht

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=em8c48fb27-3367-4e7f-9adf-09bac2c8390e@e231eb23.com \
    --to=mark@tuxis.nl \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /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.
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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal