To clarify one bit - the acceptor thread is the thread calling accept() on
the listening TCP socket. Once accepted, the RPC system uses libev
(event-based IO) to react to new packets on a "reactor thread". When a full
RPC request is received, it is distributed to the "service threads".
I'd also
Hi
The acceptor thread only distributes work, it's very unlikely that is a
bottleneck. Same goes for the number of workers, since the number of
threads pulling data is defined by impala.
What is "extremely" slow in this case?
Some things to check:
It seems like this is scanning only 5
Hi!
I'm using kudu 1.3, impala 2.7.
I'm investigating about extreamly slow scan read in impala's profiling.
So i digged source impala, kudu's source code.
And i concluded this as a connection throughput problem.
As i found out, impala use below steps to send scan request to kudu.
1.
