https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #10 from Michael Tuexen <tue...@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 improvements 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 that happens... -- You are receiving this mail because: You are the assignee for the bug.
