From e4d247e2179e5a02c7932d6b25773e885698a90a Mon Sep 17 00:00:00 2001 From: Willy Tarreau <w@1wt.eu> Date: Tue, 9 Feb 2021 17:39:08 +0100 Subject: [PATCH] BUG/MINOR: freq_ctr: fix a wrong delay calculation in next_event_delay() The sleep time calculation in next_event_delay() was wrong because it was dividing 999 by the number of pending events, and was directly responsible for an observation made a long time ago that listeners would eat all the CPU when hammered while globally rate-limited, because the more the queued events, the least it would wait, and would ignore the configured frequency to compute the delay. This was addressed in various ways in listeners through the switch to the FULL state and the wakeup of manage_global_listener_queue() that avoids this fast loop, but the calculation made there remained wrong nevertheless. It's even visible with this patch that the accept frequency is much more accurate at low values now; for example, configuring a maxconrate of 10 would give between 8.99 and 11.0 cps before this patch and between 9.99 and 10.0 with it. Better fix it now in case it's reused anywhere else and causes confusion again. It maybe be backported but is probably not worth it. --- src/freq_ctr.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/freq_ctr.c b/src/freq_ctr.c index ad032a338..a7adf0ba9 100644 --- a/src/freq_ctr.c +++ b/src/freq_ctr.c @@ -156,7 +156,13 @@ unsigned int next_event_delay(struct freq_ctr *ctr, unsigned int freq, unsigned if (curr < freq) return 0; - wait = 999 / curr; + /* too many events already, let's count how long to wait before they're + * processed. For this we'll subtract from the number of pending events + * the ones programmed for the current period, to know how long to wait + * for the next period. Each event takes 1/freq sec, thus 1000/freq ms. + */ + curr -= freq; + wait = curr * 1000 / (freq ? freq : 1); return MAX(wait, 1); }