From: Willy Tarreau <w@1wt.eu>
Date: Tue, 9 Sep 2025 15:51:39 +0000 (+0200)
Subject: MEDIUM: peers: don't even try to process updates under contention
X-Git-Tag: v3.3-dev9~172
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d7696d11e140446c283d69c0e4af3efcb471b318;p=thirdparty%2Fhaproxy.git

MEDIUM: peers: don't even try to process updates under contention

Recent fix 2421c3769a ("BUG/MEDIUM: peers: don't fail twice to grab the
update lock") improved the situation a lot for peers under locking
contention but still not enough for situations with many peers and
many entries to expire fast. It's indeed still possible to trigger
warnings at end of injection sessions for 16 peers at 100k req/s each
doing 10 random track-sc when process_table_expire() runs and holds the
update lock if compiled with a high value of STKTABLE_MAX_UPDATES_AT_ONCE
(1000). Better just not insist in this case and postpone the update.

At this point, under load only ebmb_lookup() consumes CPU, other functions
are in the few percent, indicating reasonable contention, and peers remain
updated.

This should be backported to 3.2 after a bit of testing.
---

diff --git a/src/peers.c b/src/peers.c
index 93410be6d..b13215b5d 100644
--- a/src/peers.c
+++ b/src/peers.c
@@ -1574,7 +1574,12 @@ int peer_send_teachmsgs(struct appctx *appctx, struct peer *p,
 	/* We force new pushed to 1 to force identifier in update message */
 	new_pushed = 1;
 
-	HA_RWLOCK_RDLOCK(STK_TABLE_UPDT_LOCK, &st->table->updt_lock);
+	if (HA_RWLOCK_TRYRDLOCK(STK_TABLE_UPDT_LOCK, &st->table->updt_lock) != 0) {
+		/* just don't engage here if there is any contention */
+		applet_have_more_data(appctx);
+		ret = -1;
+		goto out_unlocked;
+	}
 
 	while (1) {
 		struct stksess *ts;