Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
Impala 2.11.0
-
None
-
ghx-label-6
Description
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 freed by the deserialization thread. Other ideas are welcomed.
cc'ing mmokhtar
Attachments
Issue Links
- relates to
-
-
- Resolved
-