From d7696d11e140446c283d69c0e4af3efcb471b318 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Tue, 9 Sep 2025 17:51:39 +0200 Subject: [PATCH] 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. --- src/peers.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) 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;