https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
Michael Tuexen changed:
What|Removed |Added
Flags|mfc-stable13? |mfc-stable13+
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
Kubilay Kocak changed:
What|Removed |Added
Status|New |Open
Keywords|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #14 from Christos Chatzaras ---
(In reply to Michael Tuexen from comment #13)
Thank you. At the moment I don't have a test system available. When I have I
will redo the tests and report the results.
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #13 from Michael Tuexen ---
I have MFCed to stable/13 some performance improvements committed by rrs@ to
main.
Can you retest to see if the load is now less than before?
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #12 from Christos Chatzaras ---
Created attachment 225360
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=225360=edit
tcp_hpts panic
The CURRENT kernel (with 13.0 userland) panic because of LRO. I disable LRO and
I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #11 from Christos Chatzaras ---
SSHGuard ( https://www.freshports.org/security/sshguard ) is a tool that checks
/var/log/auth.log , /var/log/maillog, etc and blocks IPs that try to brute
force passwords. When someone tries to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #10 from Michael Tuexen ---
(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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #9 from Christos Chatzaras ---
HPTS system is "kern.eventtimer.timer=HPET", right? With HPET I see (with
"top") ~ 2 times more interrupts in comparison with LAPIC.
I tried again to reproduce the issue with a STABLE/13 kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #8 from Michael Tuexen ---
(In reply to Christos Chatzaras from comment #7)
According to rrs@ (who wrote the HPTS system), the interrupt issue is know.
There is code, which reduces the interrupt load, but that code has not yet
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #7 from Christos Chatzaras ---
I was able to reproduce the issue with a "test" server && 10 VPS running Linux.
On each VPS I run wrk (benchmarking tool):
wrk -c 1000 -d 3600s http://url
This creates 1 concurrent
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #6 from Michael Tuexen ---
(In reply to Christos Chatzaras from comment #5)
Thanks for testing, I guess you confirmed what I assumed is causing the
behaviour.
I have no idea why this happens and if it is sort of expected or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #5 from Christos Chatzaras ---
To avoid reboot I did this which I believe is the same:
sysctl net.inet.tcp.functions_default
net.inet.tcp.functions_default: freebsd
kldload tcp_rack
sysctl net.inet.tcp.functions_default=rack
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
--- Comment #4 from Michael Tuexen ---
So loading the RACK module, but not loading it, does not trigger the issue.
Getting rid of all RACK based TCP connections seems to resolve the issue.
Can you do the following experiment?
1) Load
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are
14 matches
Mail list logo
