Support Questions

ask_bill_brooks · ‎08-07-2019

We have an end-user who runs queries usually with Impala/HUE. He is receiving this error, which I assume will require some changes in tuning parameters. But where do we start to investigate here? The error message is:

ExecQueryFInstances rpc query_id=e74ef8d9b9215369:4994cbde00000000 failed: Failed to get minimum memory reservation of 68.00 MB on daemon chia1.haas.berkeley.edu:22000 for query e74ef8d9b9215369:4994cbde00000000 because it would exceed an applicable memory limit. Memory is likely oversubscribed. Reducing query concurrency or configuring admission control may help avoid this error. Memory usage: Process: Limit=97.35 GB Total=80.62 GB Peak=85.72 GB Buffer Pool: Free Buffers: Total=0 Buffer Pool: Clean Pages: Total=4.24 GB Buffer Pool: Unused Reservation: Total=-4.24 GB Free Disk IO Buffers: Total=1.41 GB Peak=1.99 GB RequestPool=root.hue: Total=78.60 GB Peak=82.56 GB Query(2f4b5cff11212907:886aa1400000000): Reservation=77.88 GB ReservationLimit=77.88 GB OtherMemory=731.77 MB Total=78.60 GB Peak=78.92 GB Query(e74ef8d9b9215369:4994cbde00000000): Reservation=0 ReservationLimit=77.88 GB OtherMemory=0 Total=0 Peak=0 RequestPool=root.mdevaan: Total=0 Peak=18.23 GB RequestPool=root.bergquist: Total=0 Peak=84.21 GB RequestPool=root.saqib: Total=0 Peak=8.93 GB Untracked Memory: Total=631.52 MB

Thanks!

EricL · ‎08-29-2019

@Zane,

The issues I can see from this profile as below:

1. The query got closed due to client inactivity:
Query f64da6a899944136:22dcac6800000000 expired due to client inactivity (timeout is 10m)

Not because of OOM

2. you do not have table stats, which can cause impala to use bad query plan:

WARNING: The following tables are missing relevant table and/or column statistics.
external_data.physician_compare

This is evident that in the SUMMARY section, the estimated rows are -1:

Operator #Hosts Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak Mem Detail
--------------------------------------------------------------------------------------------------------------------------
01:EXCHANGE 1 189.890ms 189.890ms 1.02K -1 0 0 UNPARTITIONED
00:SCAN HDFS 5 98.859ms 104.753ms 22.53K -1 78.33 MB 176.00 MB external_data.physician_compare

3. Query finished in about 1 second, as result was ready after 1.45 seconds:

First row fetched: 1.45s

4. I can see the query is most likely from hue:

Session Type: HIVESERVER2

So my conclusion is that user stayed in Hue Hive editor idle until query is closed from server side. There is no issue from the query itself whatsoever.

Cheers

View solution in original post

Tim Armstrong · ‎09-20-2019

@Zane- I'm late but can provide some additional insight.

I think the suggestion in the error message is a good one (I'm biased because I wrote it, but some thought went into it). "Memory is likely oversubscribed. Reducing query concurrency or configuring admission control may help avoid this error". The general solution for this is to set up admission control with some memory limits so that memory doesn't get oversubscribed, and so that one query can't gobble up more memory than you like. I did a talk at strata that gave pointers on a lot of this things - https://conferences.oreilly.com/strata/strata-ca-2019/public/schedule/detail/73000

In this case you can actually see that query 2f4b5cff11212907:886aa1400000000 is using Total=78.60 GB memory, so that's likely your problem.

Impala's resource management is totally permissive out of the box and will happily let queries use up all the resources in the system like this.

I didn't see what version you're running, but there were a lot of improvements in this area (config options, OOM-avoidance, diagnostics) in CDH6.1+

There's various other angles you can take to improve this - if the queries using lots of memory are suboptimal, tuning them (maybe just computing stats) makes a big difference. You can also