From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 302DA1FF165 for ; Thu, 25 Sep 2025 10:27:21 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 39CF619A55; Thu, 25 Sep 2025 10:27:50 +0200 (CEST) Message-ID: <9facf42e-748f-4427-ab8d-eb133d55425b@proxmox.com> Date: Thu, 25 Sep 2025 10:27:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion References: <20250922101749.34397-1-f.ebner@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1758788852807 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.022 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH qemu-server] fix #6207: vm status: cache last disk read/write values X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Am 22.09.25 um 7:26 PM schrieb Thomas Lamprecht: > Am 22.09.25 um 12:18 schrieb Fiona Ebner: >> If disk read/write cannot be queried because of QMP timeout, they >> should not be reported as 0, but the last value should be re-used. >> Otherwise, the difference between that reported 0 and the next value, >> when the stats are queried successfully, will show up as a huge spike >> in the RRD graphs. > > Fine with the idea in general, but this is effectively relevant for > the pvestatd only though? > > As of now we would also cache in the API daemon, without every using > this. Might not be _that_ much, so not really a problem of the amount, > but feels a bit wrong to me w.r.t. "code place". > > Has pvestatd the necessary info, directly on indirectly through the > existence of some other vmstatus properties, to derive when it can > safely reuse the previous value? It's safe (and sensible/required) if and only if there is no new value. We could have the cache be only inside pvestatd, initialize the cache with a value of 0 and properly report diskread/write values as undef if we cannot get an actual value, and have that mean "re-use previous value". (Aside: we cannot use 0 instead of undef to mean "re-use previous value", because there are edge cases where a later 0 actually means 0 again, for example, all disk unplugged). > Or maybe we could make this caching opt-in through some module flag > that only pvestatd sets? But not really thought that through, so > please take this with a grain of salt. > > btw. what about QMP being "stuck" for a prolonged time, should we > stop using the previous value after a few times (or duration)? What other value could we use? Since the graph looks at the differences of reported values, the only reasonable value we can use if we cannot get a new one is the previous one. No matter how long it takes to get a new one, or there will be that completely wrong spike again. Or is there a N/A kind of value that we could use, where RRD/graph would be smart enough to know "I cannot calculate a difference now, will have to wait for multiple good values"? Then I'd go for that instead of the current approach. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel