[Bug 256217] [tcp] High system load because of interrupts with RACK

From: <bugzilla-noreply_at_freebsd.org>
Date: Sat, 29 May 2021 12:25:49 UTC

--- Comment #10 from Michael Tuexen <tuexen@freebsd.org> ---
(In reply to Christos Chatzaras from comment #9)
> HPTS system is "kern.eventtimer.timer=HPET", right? With HPET I see (with "top") ~ 2 > times more interrupts in comparison with LAPIC.

No. HPTS is a system for high resolution timing, which can be used by TCP. The
configuration parameters you are referring to are generic time sources.
Please note that when using HPTS with RACK, more events are generated and
handled compared to the RACK stack. That is what HPTS is for. However, the
interrupt load 
can be reduced by some optimisations. These are the optimisations rrs@ is
referring to.

> I tried again to reproduce the issue with a STABLE/13 kernel and it exists too. Next > I will try with a CURRENT kernel as I see some fixes for RACK.

releng/13 and stable/13 should be very similar with respect to RACK. All
are only in current right now.

> Regarding the "stuck" connection in LAST_ACK state someone tries to brute force SSH and "sshguard" blocks the connections (I have 4 "stuck" connection for SSH at the moment). Also I have 2 "stuck" connections in port 80 from "wrk benchmark". I found this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25986 which is old PR but @johalun replied that he can see this issue few months ago. But they are not talking about "rack" so this is not related. The only relation with "rack" is that these "stuck" connections create interrupts. At the moment these connections "stuck" for more than 35 minutes. Also I see some "stuck" connections in other servers that use "freebsd" stack.

I don't know how sshguard works, but I would be interested in understanding why

You are receiving this mail because:
You are the assignee for the bug.