From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 605BC1FF09B for ; Mon, 26 Oct 2026 14:46:31 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 864A52145F; Mon, 26 Oct 2026 14:46:26 +0100 (CET) From: Christian Ebner To: pbs-devel@lists.proxmox.com Subject: [RFC PATCH proxmox-backup 0/2] fix #7756: avoid qmp 'backup' timeout Date: Mon, 26 Oct 2026 14:45:57 +0100 Message-ID: <20261026134559.352926-1-c.ebner@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793022378167 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.654 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: O5U422QSMLLNPLUKZHL7VTZJVTJJ4MVW X-Message-ID-Hash: O5U422QSMLLNPLUKZHL7VTZJVTJJ4MVW X-MailFrom: c.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: During high load due to parallel backups or slow storage backend on the PBS, tokio blocking thread pool can become an issue. This is because fetching of the previous snapshot manifest and index files may be blocked in the blocking queue for a long time, leading to exceeded QMP command timeout, especially notable for snapshots with large index files. These patches optimize the async reader for content fetching and draft a possible workaround by fully offloading the file download handling to a dedicated thread, not offloading it to tokio's blocking thread pool. Open question is whether it would make sense to distinguish between API endpoints with higher priority and ones with lower priority in general, and offload them to high priority and low priority thread pools instead of spawning new threads on demand. Issue was raised again recently in the enterprise support and several times in the community forum [0-2]. [0] https://forum.proxmox.com/threads/179304/ [1] https://forum.proxmox.com/threads/183380/ [2] https://forum.proxmox.com/threads/185679/ Christian Ebner (2): api: optimize content streaming reader for file download fix #7756: api: stream file contents via dedicated thread src/api2/helpers.rs | 169 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 155 insertions(+), 14 deletions(-) -- 2.47.3