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 E6A511FF138 for ; Mon, 20 Jul 2026 14:39:53 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id AB9D0216E2; Mon, 20 Jul 2026 14:38:17 +0200 (CEST) From: Daniel Kral To: pve-devel@lists.proxmox.com Subject: [PATCH ha-manager 14/16] lrm: read service config once per work iteration Date: Mon, 20 Jul 2026 14:37:03 +0200 Message-ID: <20260720123705.216089-15-d.kral@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260720123705.216089-1-d.kral@proxmox.com> References: <20260720123705.216089-1-d.kral@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1784551006553 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.228 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) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust 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: UJKHWS4E3LI5YEZG6MQUJZXG47L3LKMM X-Message-ID-Hash: UJKHWS4E3LI5YEZG6MQUJZXG47L3LKMM X-MailFrom: d.kral@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 VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Make update_lrm_status() read and parse the HA resources config once per work() iteration. This significantly reduces the time spent reading and parsing the HA resource config every time run_workers() is called and every time a LRM worker's result is collected with handle_service_exitcode(). This does not change the current behavior as the HA resource config and vmlist, which are used for the return value of the read_service_config() in the PVE2 environment, are only updated after every cfs_update(). However, cfs_update() is only called before each work() iteration in PVE::HA::LRM::do_one_iteration() and in PVE::HA::Env::PVE2::after_fork() and handle_service_exit_code() is only called from resource_command_finished(), which in turn is only called from the main thread and not the worker threads (i.e., after_fork() is not called). A test startup of 768 HA resources on a single node at the same time showed ~1,250% less calls to checked_resources_config() (from 10,333 to 82 calls) and ~14,320% less calls to parse_sid() (from 15,639,537 to 109,198 calls). Additionally, this reduces the inclusive average execution time per call for several subroutines where the HA resource config was read within: +---------------------------+---------------+--------------+ | Subroutine | Before Change | After Change | +---------------------------+---------------+--------------+ | check_active_workers | 327ms | 11.6ms | | resource_command_finished | 22.7ms | 2.81ms | | handle_service_exitcode | 21.1ms | 10µs | +---------------------------+---------------+--------------+ The profiling was done on a physical host with Devel::NYTProf 6.14 [0]. [0] https://metacpan.org/pod/Devel::NYTProf Signed-off-by: Daniel Kral --- src/PVE/HA/LRM.pm | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/src/PVE/HA/LRM.pm b/src/PVE/HA/LRM.pm index 1a093e8e..5f77580c 100644 --- a/src/PVE/HA/LRM.pm +++ b/src/PVE/HA/LRM.pm @@ -41,6 +41,9 @@ sub new { mode => 'active', cluster_state_update => 0, active_idle_rounds => 0, + # service_config in current work() iteration + # does contain all HA resources, users must filter for the assigned node + service_config => {}, # service_status from manager_status in current work() iteration # does contain all HA resources, users must filter for the assigned node service_status => {}, @@ -213,10 +216,11 @@ sub flush_lrm_status { =head3 $self->update_lrm_status() Updates the internal LRM status properties to reflect the state given by the -C>. +C> and +C>. The internal LRM status properties that are updated are C, -C, and C. +C, C, and C. Returns 1 if the update was successful, otherwise returns undef. @@ -232,6 +236,7 @@ sub update_lrm_status { $haenv->log('err', "updating service status from manager failed: $err"); return undef; } else { + $self->{service_config} = $haenv->read_service_config(); $self->{service_status} = $ms->{service_status} || {}; my $nodename = $haenv->nodename(); $self->{node_status} = $ms->{node_status}->{$nodename} || 'unknown'; @@ -658,13 +663,12 @@ sub work { sub run_workers { my ($self) = @_; - my $haenv = $self->{haenv}; + my ($haenv, $sc) = $self->@{qw(haenv service_config)}; my $starttime = $haenv->get_time(); # number of workers to start, if 0 we exec the command directly without forking my $max_workers = $haenv->get_max_workers(); - my $sc = $haenv->read_service_config(); my $worker = $self->{workers}; # we only got limited time but want to ensure that every queued worker is scheduled @@ -909,7 +913,7 @@ sub handle_service_exitcode { my $haenv = $self->{haenv}; my $tries = $self->{restart_tries}; - my $sc = $haenv->read_service_config(); + my $sc = $self->{service_config}; my $max_restart = 0; -- 2.47.3