You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Michael Ho (JIRA)" <ji...@apache.org> on 2017/10/26 23:44:00 UTC
[jira] [Created] (IMPALA-6116) KRPC service queue can easily
overflow
Michael Ho created IMPALA-6116:
----------------------------------
Summary: KRPC service queue can easily overflow
Key: IMPALA-6116
URL: https://issues.apache.org/jira/browse/IMPALA-6116
Project: IMPALA
Issue Type: Sub-task
Components: Distributed Exec
Affects Versions: Impala 2.11.0
Reporter: Michael Ho
During testing with KRPC, it's observed that the number of entries in the service queue needs to be extended to a rather large number (e.g. 10,000) in order to avoid excessive RPC retries due to service queue being full when hosts are under load in a cluster of modest size (100~150 nodes).
In the short run, we may have to use a rather large default value for the service queue's size. We can consider sizing it based on the cluster's size at startup (if at all possible). This, of course, is not ideal as the service queue may consume non-trivial amount of untracked memory (each entry contains a compressed row batch).
In the long run, we may need to implement flow control (IMPALA-5859) in Impala to avoid re-sending the row batch without checking if the receiver has space for it. Moreover, we may need to reconsider the role of service queue: should the actual queuing of incoming row batches be attached to a per-exchange node queue and have a separate deserialization thread pool which pulls from this queue ? In this way, we can account for the memory consumption and size the queue based on number of senders and memory budget of a query. One hurdle is that we need to overcome the undesirable cross-thread allocation pattern as rpc_context is allocated from service threads but may need be freed by the deserialization thread. Other ideas are welcomed.
cc'ing [~mmokhtar]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)