Closed stas-dovgodko closed 4 years ago
Just switch kernel 4.19 -> 5.3 and looks like solved
oh wow, interesting. a strace
/perf trace
would have been needed to see if there was a syscall or function call that took extra long time in that kernel.
Hi @carlhoerberg ,
kernel 4.9
v0.3.7
= 0.040654897689819
v0.4.3
= 0.36057305335999
strace
: https://dropmefiles.com/4zmB4
any updates?
For amqproxy version 0.4.3
we're seeing this issue on kernels 5.3.0
, 4.14.97
& 3.13.0
.
We ended up downgrading to amqproxy version 0.3.7
like @Co0ker & the issue went away on all kernel versions.
@carlhoerberg, something erroneous may have happened somewhere in here https://github.com/cloudamqp/amqproxy/compare/v0.3.7...master?
@carlhoerberg I've narrowed it down to v0.4.1
. v0.4.0
does not have the issue. https://github.com/cloudamqp/amqproxy/compare/v0.4.0...v0.4.1
Ok! Thank you for investigating. Might be the fact that we provided static builds from 0.4.1. Will provide dynamically linked builds again.
Maybe not, 0.4.0 was statically linked too :/
Ah, then I know, it's the TCP nodelay setting
0.4.4 enables TCP_NODELAY on all sockets: https://github.com/cloudamqp/amqproxy/releases/tag/v0.4.4
48core*200G server with zero LA :
via proxy
direct to rabbitmq:
355ms vs 8ms, what I'm doing wrong?