https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256217
Michael Tuexen changed:
What|Removed |Added
Flags|mfc-stable13? |mfc-stable13+
Status|
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 ass
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&action=edit
tcp_hpts panic
The CURRENT kernel (with 13.0 userland) panic because of LRO. I disable LRO a
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 lo
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 i
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 an
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 b
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 connection
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 not
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 RAC
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 receiv
14 matches
Mail list logo
