mirrors/haproxy
1
0
Fork 0
mirror of https://git.haproxy.org/git/haproxy.git/ synced 2025-09-21 05:41:26 +02:00
Code Issues Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Willy Tarreau 2025-09-09 17:51:39 +02:00
parent d5e7fba5c0
commit d7696d11e1
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
src/peers.c
View File

@ -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;