From nobody Sat May 29 12:25:49 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3CE57DB84FC for ; Sat, 29 May 2021 12:25:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fsgkk13f2z4mf1 for ; Sat, 29 May 2021 12:25:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0BBAE1DCD for ; Sat, 29 May 2021 12:25:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 14TCPndK021664 for ; Sat, 29 May 2021 12:25:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14TCPnNM021663 for net@FreeBSD.org; Sat, 29 May 2021 12:25:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 256217] [tcp] High system load because of interrupts with RACK Date: Sat, 29 May 2021 12:25:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256217 --- Comment #10 from Michael Tuexen --- (In reply to Christos Chatzaras from comment #9) > HPTS system is "kern.eventtimer.timer=3DHPET", right? With HPET I see (wi= th "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=20 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 exist= s 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" connecti= on for SSH at the moment). Also I have 2 "stuck" connections in port 80 fro= m "wrk benchmark". I found this: https://bugs.freebsd.org/bugzilla/show_bug= .cgi?id=3D25986 which is old PR but @johalun replied that he can see this i= ssue few months ago. But they are not talking about "rack" so this is not r= elated. The only relation with "rack" is that these "stuck" connections cre= ate interrupts. At the moment these connections "stuck" for more than 35 mi= nutes. Also I see some "stuck" connections in other servers that use "freeb= sd" stack. I don't know how sshguard works, but I would be interested in understanding= why that happens... --=20 You are receiving this mail because: You are the assignee for the bug.=