Re: Estimate peak memory VS used peak memory

2018-03-05 Thread Alexander Behm
Sounds like you either onboarded a new workload with nested types or an
existing workload with nested types somehow got broken in the upgrade.
That error message is quite accurate: Impala does not support IS [NOT] NULL
predicates on complex types, but it sounds like that same query used to
work before.

I'm happy to help figure out what happened, but I'll need the SQL of the
query and the CREATE TABLE/VIEW statements of the tables/views involved in
the query. Sounds like there might be a bug here.

On Wed, Feb 28, 2018 at 10:29 AM, Fawze Abujaber  wrote:

> Hi Mostafa,
>
> I already rollback the version, so i don't know how to get the settings
> and if i can get the query profile fora finished queries in the rollback
> version.
>
> But for example after the upgrade we started to see the following error
> which stopped to see after the rollback: IS NOT NULL predicate does not
> support complex types
>
>
>- IllegalStateException: org.apache.impala.common.AnalysisException:
>IS NOT NULL predicate does not support complex types: participants IS NOT
>NULL CAUSED BY: AnalysisException: IS NOT NULL predicate does not support
>complex types: participants IS NOT NULL
>
>
>
> On Wed, Feb 28, 2018 at 7:56 PM, Mostafa Mokhtar 
> wrote:
>
>> Can you please share the query profiles for the failures you got along
>> with the admission control setting?
>>
>> Thanks
>> Mostafa
>>
>> On Feb 28, 2018, at 9:28 AM, Fawze Abujaber  wrote:
>>
>> Thanks you all for your help and advises.
>>
>> Unfortunately i rolled back the upgrade till i understand how to control
>> impala resources and tackle all the failures that i start to see after the
>> upgrade.
>>
>>
>>
>> On Fri, Feb 23, 2018 at 8:22 PM, Fawze Abujaber 
>> wrote:
>>
>>> Hi Tim,
>>>
>>> My Goal is : queries that their actual memory per node exceeds more than
>>> what i setup as a default max memory node to fail, despite i have a
>>> different queries in the pool, in the same pool some business queries can
>>> be simple as select count(*) and some others can have few joins.
>>>
>>> And i think this is the right decision and such query should be
>>> optimized.
>>>
>>> And also if i'm looking in my historical queries, i can know from the
>>> max used memory per node which queries will fail, and i think this help me
>>> alot, but i need any other query to queued if it asked actual memory lower
>>> than what i setup as default max memory per node for a query.
>>>
>>> Based on the above i'm looking for the parameters that i need to
>>> configure.
>>>
>>> i don't mind how much time and how much queries will queued, in my case
>>> i don't have any impala query that running beyond 4-5 minutes and 80% of
>>> queries below 1 minute.
>>>
>>> So i don't mind to setup the queue timeout to 20 minutes and max queued
>>> to 20-30 queries per pool.
>>>
>>> I want to make sure no query will fail if it not exceeding the default
>>> memory per node that i setup.
>>>
>>> should i used only the default max memory per node alone? should i
>>> combined it with the max running queries or with the memory limit of the
>>> whole pool?
>>>
>>>
>>> On Fri, Feb 23, 2018 at 8:08 PM, Tim Armstrong 
>>> wrote:
>>>
 I think the previous answers have been good. I wanted to add a couple
 of side notes for context since I've been doing a lot of work in this area
 of Impala. I could talk about this stuff for hours.

 We do have mechanisms, like spilling data to disk or reducing # of
 threads, that kick in to keep queries under the mem_limit. This has existed
 in some form since Impala 2.0, but Impala 2.10 included some architectural
 changes to make this more robust, and we have further improvements in the
 pipeline. The end goal, which we're getting much closer to, is that queries
 should reliably run to completion instead of getting killed after they are
 admitted.

 That support is going to enable future enhancements to memory-based
 admission control to make it easier for cluster admins like yourself to
 configure admission control. It is definitely tricky to pick a good value
 for mem_limit when pools can contain a mix of queries and I think Impala
 can do better at making these decisions automatically.

 - Tim

 On Fri, Feb 23, 2018 at 9:05 AM, Alexander Behm  wrote:

> For a given query the logic for determining the memory that will be
> required from admission is:
> - if the query has mem_limit use that
> - otherwise, use memory estimates from the planner
>
> A query may be assigned a mem_limit by:
> - taking the default mem_limit from the pool it was submitted to (this
> is the recommended practice)
> - manually setting one for the query (in case you want to override the
> pool default for a single query)
>
> In that 

Re: Estimate peak memory VS used peak memory

2018-03-04 Thread Jeszy
Looks like a very different question than the original one on this
thread, it would be better to start a new thread for a new question.
Keep in mind that you are likely to get quicker answers (from
yourself) by checking the behaviour against the documentation. If
there is a bug (sounds possible), it might have already been found,
searching around issues.apache.org will tell, along with fix version
(if any).

HTH

On 4 March 2018 at 21:35, Fawze Abujaber  wrote:
> Hi Mostafa,
>
> Is this expected behavior or a BUG?
>
> On Wed, 28 Feb 2018 at 20:29 Fawze Abujaber  wrote:
>>
>> Hi Mostafa,
>>
>> I already rollback the version, so i don't know how to get the settings
>> and if i can get the query profile fora finished queries in the rollback
>> version.
>>
>> But for example after the upgrade we started to see the following error
>> which stopped to see after the rollback: IS NOT NULL predicate does not
>> support complex types
>>
>> IllegalStateException: org.apache.impala.common.AnalysisException: IS NOT
>> NULL predicate does not support complex types: participants IS NOT NULL
>> CAUSED BY: AnalysisException: IS NOT NULL predicate does not support complex
>> types: participants IS NOT NULL
>>
>>
>>
>> On Wed, Feb 28, 2018 at 7:56 PM, Mostafa Mokhtar 
>> wrote:
>>>
>>> Can you please share the query profiles for the failures you got along
>>> with the admission control setting?
>>>
>>> Thanks
>>> Mostafa
>>>
>>> On Feb 28, 2018, at 9:28 AM, Fawze Abujaber  wrote:
>>>
>>> Thanks you all for your help and advises.
>>>
>>> Unfortunately i rolled back the upgrade till i understand how to control
>>> impala resources and tackle all the failures that i start to see after the
>>> upgrade.
>>>
>>>
>>>
>>> On Fri, Feb 23, 2018 at 8:22 PM, Fawze Abujaber 
>>> wrote:

 Hi Tim,

 My Goal is : queries that their actual memory per node exceeds more than
 what i setup as a default max memory node to fail, despite i have a
 different queries in the pool, in the same pool some business queries can 
 be
 simple as select count(*) and some others can have few joins.

 And i think this is the right decision and such query should be
 optimized.

 And also if i'm looking in my historical queries, i can know from the
 max used memory per node which queries will fail, and i think this help me
 alot, but i need any other query to queued if it asked actual memory lower
 than what i setup as default max memory per node for a query.

 Based on the above i'm looking for the parameters that i need to
 configure.

 i don't mind how much time and how much queries will queued, in my case
 i don't have any impala query that running beyond 4-5 minutes and 80% of
 queries below 1 minute.

 So i don't mind to setup the queue timeout to 20 minutes and max queued
 to 20-30 queries per pool.

 I want to make sure no query will fail if it not exceeding the default
 memory per node that i setup.

 should i used only the default max memory per node alone? should i
 combined it with the max running queries or with the memory limit of the
 whole pool?


 On Fri, Feb 23, 2018 at 8:08 PM, Tim Armstrong 
 wrote:
>
> I think the previous answers have been good. I wanted to add a couple
> of side notes for context since I've been doing a lot of work in this area
> of Impala. I could talk about this stuff for hours.
>
> We do have mechanisms, like spilling data to disk or reducing # of
> threads, that kick in to keep queries under the mem_limit. This has 
> existed
> in some form since Impala 2.0, but Impala 2.10 included some architectural
> changes to make this more robust, and we have further improvements in the
> pipeline. The end goal, which we're getting much closer to, is that 
> queries
> should reliably run to completion instead of getting killed after they are
> admitted.
>
> That support is going to enable future enhancements to memory-based
> admission control to make it easier for cluster admins like yourself to
> configure admission control. It is definitely tricky to pick a good value
> for mem_limit when pools can contain a mix of queries and I think Impala 
> can
> do better at making these decisions automatically.
>
> - Tim
>
> On Fri, Feb 23, 2018 at 9:05 AM, Alexander Behm
>  wrote:
>>
>> For a given query the logic for determining the memory that will be
>> required from admission is:
>> - if the query has mem_limit use that
>> - otherwise, use memory estimates from the planner
>>
>> A query may be assigned a mem_limit by:
>> - taking the default mem_limit from the pool it was submitted to (this
>> is the 

Re: Estimate peak memory VS used peak memory

2018-03-04 Thread Fawze Abujaber
Hi Mostafa,

Is this expected behavior or a BUG?

On Wed, 28 Feb 2018 at 20:29 Fawze Abujaber  wrote:

> Hi Mostafa,
>
> I already rollback the version, so i don't know how to get the settings
> and if i can get the query profile fora finished queries in the rollback
> version.
>
> But for example after the upgrade we started to see the following error
> which stopped to see after the rollback: IS NOT NULL predicate does not
> support complex types
>
>
>- IllegalStateException: org.apache.impala.common.AnalysisException:
>IS NOT NULL predicate does not support complex types: participants IS NOT
>NULL CAUSED BY: AnalysisException: IS NOT NULL predicate does not support
>complex types: participants IS NOT NULL
>
>
>
> On Wed, Feb 28, 2018 at 7:56 PM, Mostafa Mokhtar 
> wrote:
>
>> Can you please share the query profiles for the failures you got along
>> with the admission control setting?
>>
>> Thanks
>> Mostafa
>>
>> On Feb 28, 2018, at 9:28 AM, Fawze Abujaber  wrote:
>>
>> Thanks you all for your help and advises.
>>
>> Unfortunately i rolled back the upgrade till i understand how to control
>> impala resources and tackle all the failures that i start to see after the
>> upgrade.
>>
>>
>>
>> On Fri, Feb 23, 2018 at 8:22 PM, Fawze Abujaber 
>> wrote:
>>
>>> Hi Tim,
>>>
>>> My Goal is : queries that their actual memory per node exceeds more than
>>> what i setup as a default max memory node to fail, despite i have a
>>> different queries in the pool, in the same pool some business queries can
>>> be simple as select count(*) and some others can have few joins.
>>>
>>> And i think this is the right decision and such query should be
>>> optimized.
>>>
>>> And also if i'm looking in my historical queries, i can know from the
>>> max used memory per node which queries will fail, and i think this help me
>>> alot, but i need any other query to queued if it asked actual memory lower
>>> than what i setup as default max memory per node for a query.
>>>
>>> Based on the above i'm looking for the parameters that i need to
>>> configure.
>>>
>>> i don't mind how much time and how much queries will queued, in my case
>>> i don't have any impala query that running beyond 4-5 minutes and 80% of
>>> queries below 1 minute.
>>>
>>> So i don't mind to setup the queue timeout to 20 minutes and max queued
>>> to 20-30 queries per pool.
>>>
>>> I want to make sure no query will fail if it not exceeding the default
>>> memory per node that i setup.
>>>
>>> should i used only the default max memory per node alone? should i
>>> combined it with the max running queries or with the memory limit of the
>>> whole pool?
>>>
>>>
>>> On Fri, Feb 23, 2018 at 8:08 PM, Tim Armstrong 
>>> wrote:
>>>
 I think the previous answers have been good. I wanted to add a couple
 of side notes for context since I've been doing a lot of work in this area
 of Impala. I could talk about this stuff for hours.

 We do have mechanisms, like spilling data to disk or reducing # of
 threads, that kick in to keep queries under the mem_limit. This has existed
 in some form since Impala 2.0, but Impala 2.10 included some architectural
 changes to make this more robust, and we have further improvements in the
 pipeline. The end goal, which we're getting much closer to, is that queries
 should reliably run to completion instead of getting killed after they are
 admitted.

 That support is going to enable future enhancements to memory-based
 admission control to make it easier for cluster admins like yourself to
 configure admission control. It is definitely tricky to pick a good value
 for mem_limit when pools can contain a mix of queries and I think Impala
 can do better at making these decisions automatically.

 - Tim

 On Fri, Feb 23, 2018 at 9:05 AM, Alexander Behm  wrote:

> For a given query the logic for determining the memory that will be
> required from admission is:
> - if the query has mem_limit use that
> - otherwise, use memory estimates from the planner
>
> A query may be assigned a mem_limit by:
> - taking the default mem_limit from the pool it was submitted to (this
> is the recommended practice)
> - manually setting one for the query (in case you want to override the
> pool default for a single query)
>
> In that setup, the memory estimates from the planner are irrelevant
> for admission decisions and only serve for informational purposes.
> Please do not read too much into the memory estimates from the
> planner. They can be totally wrong (like your 8TB example).
>
>
> On Fri, Feb 23, 2018 at 3:47 AM, Jeszy  wrote:
>
>> Again, the 8TB estimate would not be relevant if the query had a
>> mem_limit set.
>> I 

Re: Estimate peak memory VS used peak memory

2018-02-28 Thread Fawze Abujaber
Hi Mostafa,

I already rollback the version, so i don't know how to get the settings and
if i can get the query profile fora finished queries in the rollback
version.

But for example after the upgrade we started to see the following error
which stopped to see after the rollback: IS NOT NULL predicate does not
support complex types


   - IllegalStateException: org.apache.impala.common.AnalysisException: IS
   NOT NULL predicate does not support complex types: participants IS NOT NULL
   CAUSED BY: AnalysisException: IS NOT NULL predicate does not support
   complex types: participants IS NOT NULL



On Wed, Feb 28, 2018 at 7:56 PM, Mostafa Mokhtar 
wrote:

> Can you please share the query profiles for the failures you got along
> with the admission control setting?
>
> Thanks
> Mostafa
>
> On Feb 28, 2018, at 9:28 AM, Fawze Abujaber  wrote:
>
> Thanks you all for your help and advises.
>
> Unfortunately i rolled back the upgrade till i understand how to control
> impala resources and tackle all the failures that i start to see after the
> upgrade.
>
>
>
> On Fri, Feb 23, 2018 at 8:22 PM, Fawze Abujaber  wrote:
>
>> Hi Tim,
>>
>> My Goal is : queries that their actual memory per node exceeds more than
>> what i setup as a default max memory node to fail, despite i have a
>> different queries in the pool, in the same pool some business queries can
>> be simple as select count(*) and some others can have few joins.
>>
>> And i think this is the right decision and such query should be optimized.
>>
>> And also if i'm looking in my historical queries, i can know from the max
>> used memory per node which queries will fail, and i think this help me
>> alot, but i need any other query to queued if it asked actual memory lower
>> than what i setup as default max memory per node for a query.
>>
>> Based on the above i'm looking for the parameters that i need to
>> configure.
>>
>> i don't mind how much time and how much queries will queued, in my case i
>> don't have any impala query that running beyond 4-5 minutes and 80% of
>> queries below 1 minute.
>>
>> So i don't mind to setup the queue timeout to 20 minutes and max queued
>> to 20-30 queries per pool.
>>
>> I want to make sure no query will fail if it not exceeding the default
>> memory per node that i setup.
>>
>> should i used only the default max memory per node alone? should i
>> combined it with the max running queries or with the memory limit of the
>> whole pool?
>>
>>
>> On Fri, Feb 23, 2018 at 8:08 PM, Tim Armstrong 
>> wrote:
>>
>>> I think the previous answers have been good. I wanted to add a couple of
>>> side notes for context since I've been doing a lot of work in this area of
>>> Impala. I could talk about this stuff for hours.
>>>
>>> We do have mechanisms, like spilling data to disk or reducing # of
>>> threads, that kick in to keep queries under the mem_limit. This has existed
>>> in some form since Impala 2.0, but Impala 2.10 included some architectural
>>> changes to make this more robust, and we have further improvements in the
>>> pipeline. The end goal, which we're getting much closer to, is that queries
>>> should reliably run to completion instead of getting killed after they are
>>> admitted.
>>>
>>> That support is going to enable future enhancements to memory-based
>>> admission control to make it easier for cluster admins like yourself to
>>> configure admission control. It is definitely tricky to pick a good value
>>> for mem_limit when pools can contain a mix of queries and I think Impala
>>> can do better at making these decisions automatically.
>>>
>>> - Tim
>>>
>>> On Fri, Feb 23, 2018 at 9:05 AM, Alexander Behm 
>>> wrote:
>>>
 For a given query the logic for determining the memory that will be
 required from admission is:
 - if the query has mem_limit use that
 - otherwise, use memory estimates from the planner

 A query may be assigned a mem_limit by:
 - taking the default mem_limit from the pool it was submitted to (this
 is the recommended practice)
 - manually setting one for the query (in case you want to override the
 pool default for a single query)

 In that setup, the memory estimates from the planner are irrelevant for
 admission decisions and only serve for informational purposes.
 Please do not read too much into the memory estimates from the planner.
 They can be totally wrong (like your 8TB example).


 On Fri, Feb 23, 2018 at 3:47 AM, Jeszy  wrote:

> Again, the 8TB estimate would not be relevant if the query had a
> mem_limit set.
> I think all that we discussed is covered in the docs, but if you feel
> like specific parts need clarification, please file a jira.
>
> On 23 February 2018 at 11:51, Fawze Abujaber 
> wrote:
> > Sorry for  asking many 

Re: Estimate peak memory VS used peak memory

2018-02-28 Thread Mostafa Mokhtar
Can you please share the query profiles for the failures you got along with the 
admission control setting? 

Thanks 
Mostafa

> On Feb 28, 2018, at 9:28 AM, Fawze Abujaber  wrote:
> 
> Thanks you all for your help and advises.
> 
> Unfortunately i rolled back the upgrade till i understand how to control 
> impala resources and tackle all the failures that i start to see after the 
> upgrade.
> 
> 
> 
>> On Fri, Feb 23, 2018 at 8:22 PM, Fawze Abujaber  wrote:
>> Hi Tim,
>> 
>> My Goal is : queries that their actual memory per node exceeds more than 
>> what i setup as a default max memory node to fail, despite i have a 
>> different queries in the pool, in the same pool some business queries can be 
>> simple as select count(*) and some others can have few joins.
>> 
>> And i think this is the right decision and such query should be optimized.
>> 
>> And also if i'm looking in my historical queries, i can know from the max 
>> used memory per node which queries will fail, and i think this help me alot, 
>> but i need any other query to queued if it asked actual memory lower than 
>> what i setup as default max memory per node for a query.
>> 
>> Based on the above i'm looking for the parameters that i need to configure.
>> 
>> i don't mind how much time and how much queries will queued, in my case i 
>> don't have any impala query that running beyond 4-5 minutes and 80% of 
>> queries below 1 minute.
>> 
>> So i don't mind to setup the queue timeout to 20 minutes and max queued to 
>> 20-30 queries per pool.
>> 
>> I want to make sure no query will fail if it not exceeding the default 
>> memory per node that i setup.
>> 
>> should i used only the default max memory per node alone? should i combined 
>> it with the max running queries or with the memory limit of the whole pool?
>> 
>> 
>>> On Fri, Feb 23, 2018 at 8:08 PM, Tim Armstrong  
>>> wrote:
>>> I think the previous answers have been good. I wanted to add a couple of 
>>> side notes for context since I've been doing a lot of work in this area of 
>>> Impala. I could talk about this stuff for hours.
>>> 
>>> We do have mechanisms, like spilling data to disk or reducing # of threads, 
>>> that kick in to keep queries under the mem_limit. This has existed in some 
>>> form since Impala 2.0, but Impala 2.10 included some architectural changes 
>>> to make this more robust, and we have further improvements in the pipeline. 
>>> The end goal, which we're getting much closer to, is that queries should 
>>> reliably run to completion instead of getting killed after they are 
>>> admitted.
>>> 
>>> That support is going to enable future enhancements to memory-based 
>>> admission control to make it easier for cluster admins like yourself to 
>>> configure admission control. It is definitely tricky to pick a good value 
>>> for mem_limit when pools can contain a mix of queries and I think Impala 
>>> can do better at making these decisions automatically.
>>> 
>>> - Tim
>>> 
 On Fri, Feb 23, 2018 at 9:05 AM, Alexander Behm  
 wrote:
 For a given query the logic for determining the memory that will be 
 required from admission is:
 - if the query has mem_limit use that
 - otherwise, use memory estimates from the planner
 
 A query may be assigned a mem_limit by:
 - taking the default mem_limit from the pool it was submitted to (this is 
 the recommended practice)
 - manually setting one for the query (in case you want to override the 
 pool default for a single query)
 
 In that setup, the memory estimates from the planner are irrelevant for 
 admission decisions and only serve for informational purposes.
 Please do not read too much into the memory estimates from the planner. 
 They can be totally wrong (like your 8TB example).
 
 
> On Fri, Feb 23, 2018 at 3:47 AM, Jeszy  wrote:
> Again, the 8TB estimate would not be relevant if the query had a 
> mem_limit set.
> I think all that we discussed is covered in the docs, but if you feel
> like specific parts need clarification, please file a jira.
> 
> On 23 February 2018 at 11:51, Fawze Abujaber  wrote:
> > Sorry for  asking many questions, but i see your answers are closing the
> > gaps that i cannot find in the documentation.
> >
> > So how we can explain that there was an estimate for 8T per node and 
> > impala
> > decided to submit this query?
> >
> > My goal that each query running beyond the actual limit per node to 
> > fail (
> > and this is what i setup in the default memory per node per pool) an 
> > want
> > all other queries to be queue and not killed, so what i understand that 
> > i
> > need to setup the max queue query to unlimited and the queue timeout to
> > hours.
> >
> > And in order to reach that i 

Re: Estimate peak memory VS used peak memory

2018-02-28 Thread Fawze Abujaber
Thanks you all for your help and advises.

Unfortunately i rolled back the upgrade till i understand how to control
impala resources and tackle all the failures that i start to see after the
upgrade.



On Fri, Feb 23, 2018 at 8:22 PM, Fawze Abujaber  wrote:

> Hi Tim,
>
> My Goal is : queries that their actual memory per node exceeds more than
> what i setup as a default max memory node to fail, despite i have a
> different queries in the pool, in the same pool some business queries can
> be simple as select count(*) and some others can have few joins.
>
> And i think this is the right decision and such query should be optimized.
>
> And also if i'm looking in my historical queries, i can know from the max
> used memory per node which queries will fail, and i think this help me
> alot, but i need any other query to queued if it asked actual memory lower
> than what i setup as default max memory per node for a query.
>
> Based on the above i'm looking for the parameters that i need to configure.
>
> i don't mind how much time and how much queries will queued, in my case i
> don't have any impala query that running beyond 4-5 minutes and 80% of
> queries below 1 minute.
>
> So i don't mind to setup the queue timeout to 20 minutes and max queued to
> 20-30 queries per pool.
>
> I want to make sure no query will fail if it not exceeding the default
> memory per node that i setup.
>
> should i used only the default max memory per node alone? should i
> combined it with the max running queries or with the memory limit of the
> whole pool?
>
>
> On Fri, Feb 23, 2018 at 8:08 PM, Tim Armstrong 
> wrote:
>
>> I think the previous answers have been good. I wanted to add a couple of
>> side notes for context since I've been doing a lot of work in this area of
>> Impala. I could talk about this stuff for hours.
>>
>> We do have mechanisms, like spilling data to disk or reducing # of
>> threads, that kick in to keep queries under the mem_limit. This has existed
>> in some form since Impala 2.0, but Impala 2.10 included some architectural
>> changes to make this more robust, and we have further improvements in the
>> pipeline. The end goal, which we're getting much closer to, is that queries
>> should reliably run to completion instead of getting killed after they are
>> admitted.
>>
>> That support is going to enable future enhancements to memory-based
>> admission control to make it easier for cluster admins like yourself to
>> configure admission control. It is definitely tricky to pick a good value
>> for mem_limit when pools can contain a mix of queries and I think Impala
>> can do better at making these decisions automatically.
>>
>> - Tim
>>
>> On Fri, Feb 23, 2018 at 9:05 AM, Alexander Behm 
>> wrote:
>>
>>> For a given query the logic for determining the memory that will be
>>> required from admission is:
>>> - if the query has mem_limit use that
>>> - otherwise, use memory estimates from the planner
>>>
>>> A query may be assigned a mem_limit by:
>>> - taking the default mem_limit from the pool it was submitted to (this
>>> is the recommended practice)
>>> - manually setting one for the query (in case you want to override the
>>> pool default for a single query)
>>>
>>> In that setup, the memory estimates from the planner are irrelevant for
>>> admission decisions and only serve for informational purposes.
>>> Please do not read too much into the memory estimates from the planner.
>>> They can be totally wrong (like your 8TB example).
>>>
>>>
>>> On Fri, Feb 23, 2018 at 3:47 AM, Jeszy  wrote:
>>>
 Again, the 8TB estimate would not be relevant if the query had a
 mem_limit set.
 I think all that we discussed is covered in the docs, but if you feel
 like specific parts need clarification, please file a jira.

 On 23 February 2018 at 11:51, Fawze Abujaber  wrote:
 > Sorry for  asking many questions, but i see your answers are closing
 the
 > gaps that i cannot find in the documentation.
 >
 > So how we can explain that there was an estimate for 8T per node and
 impala
 > decided to submit this query?
 >
 > My goal that each query running beyond the actual limit per node to
 fail (
 > and this is what i setup in the default memory per node per pool) an
 want
 > all other queries to be queue and not killed, so what i understand
 that i
 > need to setup the max queue query to unlimited and the queue timeout
 to
 > hours.
 >
 > And in order to reach that i need to setup the default memory per
 node for
 > each pool and setting either max concurrency or the max memory per
 pool that
 > will help to measure the max concurrent queries that can run in
 specific
 > pool.
 >
 > I think reaching this goal will close all my gaps.
 >
 >
 >
 > On Fri, Feb 23, 2018 at 11:49 AM, 

Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Fawze Abujaber
Hi Tim,

My Goal is : queries that their actual memory per node exceeds more than
what i setup as a default max memory node to fail, despite i have a
different queries in the pool, in the same pool some business queries can
be simple as select count(*) and some others can have few joins.

And i think this is the right decision and such query should be optimized.

And also if i'm looking in my historical queries, i can know from the max
used memory per node which queries will fail, and i think this help me
alot, but i need any other query to queued if it asked actual memory lower
than what i setup as default max memory per node for a query.

Based on the above i'm looking for the parameters that i need to configure.

i don't mind how much time and how much queries will queued, in my case i
don't have any impala query that running beyond 4-5 minutes and 80% of
queries below 1 minute.

So i don't mind to setup the queue timeout to 20 minutes and max queued to
20-30 queries per pool.

I want to make sure no query will fail if it not exceeding the default
memory per node that i setup.

should i used only the default max memory per node alone? should i combined
it with the max running queries or with the memory limit of the whole pool?


On Fri, Feb 23, 2018 at 8:08 PM, Tim Armstrong 
wrote:

> I think the previous answers have been good. I wanted to add a couple of
> side notes for context since I've been doing a lot of work in this area of
> Impala. I could talk about this stuff for hours.
>
> We do have mechanisms, like spilling data to disk or reducing # of
> threads, that kick in to keep queries under the mem_limit. This has existed
> in some form since Impala 2.0, but Impala 2.10 included some architectural
> changes to make this more robust, and we have further improvements in the
> pipeline. The end goal, which we're getting much closer to, is that queries
> should reliably run to completion instead of getting killed after they are
> admitted.
>
> That support is going to enable future enhancements to memory-based
> admission control to make it easier for cluster admins like yourself to
> configure admission control. It is definitely tricky to pick a good value
> for mem_limit when pools can contain a mix of queries and I think Impala
> can do better at making these decisions automatically.
>
> - Tim
>
> On Fri, Feb 23, 2018 at 9:05 AM, Alexander Behm 
> wrote:
>
>> For a given query the logic for determining the memory that will be
>> required from admission is:
>> - if the query has mem_limit use that
>> - otherwise, use memory estimates from the planner
>>
>> A query may be assigned a mem_limit by:
>> - taking the default mem_limit from the pool it was submitted to (this is
>> the recommended practice)
>> - manually setting one for the query (in case you want to override the
>> pool default for a single query)
>>
>> In that setup, the memory estimates from the planner are irrelevant for
>> admission decisions and only serve for informational purposes.
>> Please do not read too much into the memory estimates from the planner.
>> They can be totally wrong (like your 8TB example).
>>
>>
>> On Fri, Feb 23, 2018 at 3:47 AM, Jeszy  wrote:
>>
>>> Again, the 8TB estimate would not be relevant if the query had a
>>> mem_limit set.
>>> I think all that we discussed is covered in the docs, but if you feel
>>> like specific parts need clarification, please file a jira.
>>>
>>> On 23 February 2018 at 11:51, Fawze Abujaber  wrote:
>>> > Sorry for  asking many questions, but i see your answers are closing
>>> the
>>> > gaps that i cannot find in the documentation.
>>> >
>>> > So how we can explain that there was an estimate for 8T per node and
>>> impala
>>> > decided to submit this query?
>>> >
>>> > My goal that each query running beyond the actual limit per node to
>>> fail (
>>> > and this is what i setup in the default memory per node per pool) an
>>> want
>>> > all other queries to be queue and not killed, so what i understand
>>> that i
>>> > need to setup the max queue query to unlimited and the queue timeout to
>>> > hours.
>>> >
>>> > And in order to reach that i need to setup the default memory per node
>>> for
>>> > each pool and setting either max concurrency or the max memory per
>>> pool that
>>> > will help to measure the max concurrent queries that can run in
>>> specific
>>> > pool.
>>> >
>>> > I think reaching this goal will close all my gaps.
>>> >
>>> >
>>> >
>>> > On Fri, Feb 23, 2018 at 11:49 AM, Jeszy  wrote:
>>> >>
>>> >> > Do queuing query or not is based on the prediction which based on
>>> the
>>> >> > estimate and of course the concurrency that can run in a pool.
>>> >>
>>> >> Yes, it is.
>>> >>
>>> >> > If I have memory limit per pool and memory limit per node for a
>>> pool, so
>>> >> > it
>>> >> > can be used to estimate number of queries that can run
>>> concurrently, is
>>> >> > 

Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Tim Armstrong
I think the previous answers have been good. I wanted to add a couple of
side notes for context since I've been doing a lot of work in this area of
Impala. I could talk about this stuff for hours.

We do have mechanisms, like spilling data to disk or reducing # of threads,
that kick in to keep queries under the mem_limit. This has existed in some
form since Impala 2.0, but Impala 2.10 included some architectural changes
to make this more robust, and we have further improvements in the pipeline.
The end goal, which we're getting much closer to, is that queries should
reliably run to completion instead of getting killed after they are
admitted.

That support is going to enable future enhancements to memory-based
admission control to make it easier for cluster admins like yourself to
configure admission control. It is definitely tricky to pick a good value
for mem_limit when pools can contain a mix of queries and I think Impala
can do better at making these decisions automatically.

- Tim

On Fri, Feb 23, 2018 at 9:05 AM, Alexander Behm 
wrote:

> For a given query the logic for determining the memory that will be
> required from admission is:
> - if the query has mem_limit use that
> - otherwise, use memory estimates from the planner
>
> A query may be assigned a mem_limit by:
> - taking the default mem_limit from the pool it was submitted to (this is
> the recommended practice)
> - manually setting one for the query (in case you want to override the
> pool default for a single query)
>
> In that setup, the memory estimates from the planner are irrelevant for
> admission decisions and only serve for informational purposes.
> Please do not read too much into the memory estimates from the planner.
> They can be totally wrong (like your 8TB example).
>
>
> On Fri, Feb 23, 2018 at 3:47 AM, Jeszy  wrote:
>
>> Again, the 8TB estimate would not be relevant if the query had a
>> mem_limit set.
>> I think all that we discussed is covered in the docs, but if you feel
>> like specific parts need clarification, please file a jira.
>>
>> On 23 February 2018 at 11:51, Fawze Abujaber  wrote:
>> > Sorry for  asking many questions, but i see your answers are closing the
>> > gaps that i cannot find in the documentation.
>> >
>> > So how we can explain that there was an estimate for 8T per node and
>> impala
>> > decided to submit this query?
>> >
>> > My goal that each query running beyond the actual limit per node to
>> fail (
>> > and this is what i setup in the default memory per node per pool) an
>> want
>> > all other queries to be queue and not killed, so what i understand that
>> i
>> > need to setup the max queue query to unlimited and the queue timeout to
>> > hours.
>> >
>> > And in order to reach that i need to setup the default memory per node
>> for
>> > each pool and setting either max concurrency or the max memory per pool
>> that
>> > will help to measure the max concurrent queries that can run in specific
>> > pool.
>> >
>> > I think reaching this goal will close all my gaps.
>> >
>> >
>> >
>> > On Fri, Feb 23, 2018 at 11:49 AM, Jeszy  wrote:
>> >>
>> >> > Do queuing query or not is based on the prediction which based on the
>> >> > estimate and of course the concurrency that can run in a pool.
>> >>
>> >> Yes, it is.
>> >>
>> >> > If I have memory limit per pool and memory limit per node for a
>> pool, so
>> >> > it
>> >> > can be used to estimate number of queries that can run concurrently,
>> is
>> >> > this
>> >> > also based on the prediction and not the actual use.
>> >>
>> >> Also on prediction.
>> >
>> >
>>
>
>


Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Alexander Behm
For a given query the logic for determining the memory that will be
required from admission is:
- if the query has mem_limit use that
- otherwise, use memory estimates from the planner

A query may be assigned a mem_limit by:
- taking the default mem_limit from the pool it was submitted to (this is
the recommended practice)
- manually setting one for the query (in case you want to override the pool
default for a single query)

In that setup, the memory estimates from the planner are irrelevant for
admission decisions and only serve for informational purposes.
Please do not read too much into the memory estimates from the planner.
They can be totally wrong (like your 8TB example).


On Fri, Feb 23, 2018 at 3:47 AM, Jeszy  wrote:

> Again, the 8TB estimate would not be relevant if the query had a mem_limit
> set.
> I think all that we discussed is covered in the docs, but if you feel
> like specific parts need clarification, please file a jira.
>
> On 23 February 2018 at 11:51, Fawze Abujaber  wrote:
> > Sorry for  asking many questions, but i see your answers are closing the
> > gaps that i cannot find in the documentation.
> >
> > So how we can explain that there was an estimate for 8T per node and
> impala
> > decided to submit this query?
> >
> > My goal that each query running beyond the actual limit per node to fail
> (
> > and this is what i setup in the default memory per node per pool) an want
> > all other queries to be queue and not killed, so what i understand that i
> > need to setup the max queue query to unlimited and the queue timeout to
> > hours.
> >
> > And in order to reach that i need to setup the default memory per node
> for
> > each pool and setting either max concurrency or the max memory per pool
> that
> > will help to measure the max concurrent queries that can run in specific
> > pool.
> >
> > I think reaching this goal will close all my gaps.
> >
> >
> >
> > On Fri, Feb 23, 2018 at 11:49 AM, Jeszy  wrote:
> >>
> >> > Do queuing query or not is based on the prediction which based on the
> >> > estimate and of course the concurrency that can run in a pool.
> >>
> >> Yes, it is.
> >>
> >> > If I have memory limit per pool and memory limit per node for a pool,
> so
> >> > it
> >> > can be used to estimate number of queries that can run concurrently,
> is
> >> > this
> >> > also based on the prediction and not the actual use.
> >>
> >> Also on prediction.
> >
> >
>


Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Fawze Abujaber
Sorry for  asking many questions, but i see your answers are closing the
gaps that i cannot find in the documentation.

So how we can explain that there was an estimate for 8T per node and impala
decided to submit this query?

My goal that each query running beyond the actual limit per node to fail (
and this is what i setup in the default memory per node per pool) an want
all other queries to be queue and not killed, so what i understand that i
need to setup the max queue query to unlimited and the queue timeout to
hours.

And in order to reach that i need to setup the default memory per node for
each pool and setting either max concurrency or the max memory per pool
that will help to measure the max concurrent queries that can run in
specific pool.

I think reaching this goal will close all my gaps.



On Fri, Feb 23, 2018 at 11:49 AM, Jeszy  wrote:

> > Do queuing query or not is based on the prediction which based on the
> > estimate and of course the concurrency that can run in a pool.
>
> Yes, it is.
>
> > If I have memory limit per pool and memory limit per node for a pool, so
> it
> > can be used to estimate number of queries that can run concurrently, is
> this
> > also based on the prediction and not the actual use.
>
> Also on prediction.
>


Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Jeszy
> Do queuing query or not is based on the prediction which based on the
> estimate and of course the concurrency that can run in a pool.

Yes, it is.

> If I have memory limit per pool and memory limit per node for a pool, so it
> can be used to estimate number of queries that can run concurrently, is this
> also based on the prediction and not the actual use.

Also on prediction.


Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Fawze Abujaber
Do queuing query or not is based on the prediction which based on the
estimate and of course the concurrency that can run in a pool.

If I have memory limit per pool and memory limit per node for a pool, so it
can be used to estimate number of queries that can run concurrently, is
this also based on the prediction and not the actual use.

I believe with the time and trends we can learn a lot from the admission
control but trying to minimize the impact the business at this period of
learning ...

On Fri, 23 Feb 2018 at 11:26 Jeszy  wrote:

> Queries will be killed based on actual usage (peak memory usage across
> hosts), so the 200mb is the interesting value in your example.
>
> Compare the pool's available memory to the query's mem requirement
> (based on estimate or mem_limit, as discussed) to predict admission.
>
> On 23 February 2018 at 10:06, Fawze Abujaber  wrote:
> > Thanks jezy for your detailed response.
> >
> > Yes I read the documentation.
> >
> > Let simplify my question:
> >
> > I have pools set up with memory limit per node and concurrency.
> >
> > If I’m looking on the historical impala queries that I have and the
> metrics
> > I have per query, on which metrics I can understand that impala will kill
> > the query, for example if I have a query with estimate of 2GB and the
> used
> > per node is 200mb, what is the default memory values that i need to
> setup so
> > the query will not fail.
> >
> > The second one is the distribution between pools, if one query is running
> > which metrics o have to look into to know if I submit a query it fail or
> > not.
> >
> > On Fri, 23 Feb 2018 at 10:48 Jeszy  wrote:
> >>
> >> Hey Fawze,
> >>
> >> Answers inline.
> >>
> >> On 23 February 2018 at 01:23, Fawze Abujaber  wrote:
> >> > There is no option in the admission control to setup memory limit per
> >> > query,
> >> > the memory limit is per pool and there is a default memory per node
> for
> >> > query.
> >>
> >> per node for query memory limit multiplied by number of nodes gives
> >> you a per query memory limit. I agree its confusing that the
> >> configurations mix and match between per-node and aggregated values.
> >> In this case there's a good reason though, as a single node running
> >> out of memory will lead to query failure, meaning that in addition to
> >> total memory used, distribution of memory usage between hosts also
> >> matters.
> >>
> >> > I have hundreds of impala queries and more add hoc queries, making a
> >> > pool
> >> > for each query is not a visible solution.
> >> >
> >> > still waiting to understand how the estimate per node related to the
> >> > default
> >> > memory per node I set up per pool, is it used in the decision of
> queuing
> >> > and
> >> > killing the query? and if this is true how it was not kill a query
> that
> >> > was
> >> > estimated it needs 8.2TB memory per node.
> >> >
> >> > Understanding on which parameters impala decides to kill a query can
> >> > help
> >> > understand to define and divide the memory between the pools.
> >>
> >> If you set mem_limit at any level (service level, pool level, or query
> >> level), it will be used for admission control purposes instead of
> >> estimates. So a 8.2TB estimate would not be a problem, if impala can
> >> reserve mem_limit amount on each host, it will start running the
> >> query.
> >>
> >> > Passing memory limit per query manually is also not visible and such
> >> > settings not needs admission control.
> >> >
> >> > I have support pool that runs ad hoc query and I can not ask them to
> use
> >> > memory limit per query, and I have analytics pool which is fully
> >> > business
> >> > and I can rely on admission control if it extremely in accurate.
> >>
> >> It's a bit tricky to use memory-based admission control with
> >> non-trivial ad hoc queries. For simple ad-hoc queries, you can try to
> >> come up with a 'good enough' mem_limit, or omit mem_limit and trust
> >> impala's estimations. You can check the estimated vs. actual values
> >> for a representative set of ad hoc queries to see what would work in
> >> your case. I've found that people tend to go with a large enough
> >> mem_limit for the ad hoc pool.
> >>
> >> > Can someone explain me exactly which recommended setting to use per
> pool
> >> > and
> >> > which of them rely on impala memory estimates?
> >>
> >> The documentation of admission control
> >> (https://impala.apache.org/docs/build/html/topics/impala_admission.html
> )
> >> gives you a good view on how stuff works, but you will have to figure
> >> out how to use these features for your specific use case. That said,
> >> when using memory based admission control, it is best practice to
> >> always use a mem_limit due to potential inaccuracy of estimates as
> >> well as potential variance of estimates between Impala releases. Keep
> >> in mind that you can opt to set a default mem_limit for one pool and
> >> leave it 

Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Jeszy
Queries will be killed based on actual usage (peak memory usage across
hosts), so the 200mb is the interesting value in your example.

Compare the pool's available memory to the query's mem requirement
(based on estimate or mem_limit, as discussed) to predict admission.

On 23 February 2018 at 10:06, Fawze Abujaber  wrote:
> Thanks jezy for your detailed response.
>
> Yes I read the documentation.
>
> Let simplify my question:
>
> I have pools set up with memory limit per node and concurrency.
>
> If I’m looking on the historical impala queries that I have and the metrics
> I have per query, on which metrics I can understand that impala will kill
> the query, for example if I have a query with estimate of 2GB and the used
> per node is 200mb, what is the default memory values that i need to setup so
> the query will not fail.
>
> The second one is the distribution between pools, if one query is running
> which metrics o have to look into to know if I submit a query it fail or
> not.
>
> On Fri, 23 Feb 2018 at 10:48 Jeszy  wrote:
>>
>> Hey Fawze,
>>
>> Answers inline.
>>
>> On 23 February 2018 at 01:23, Fawze Abujaber  wrote:
>> > There is no option in the admission control to setup memory limit per
>> > query,
>> > the memory limit is per pool and there is a default memory per node for
>> > query.
>>
>> per node for query memory limit multiplied by number of nodes gives
>> you a per query memory limit. I agree its confusing that the
>> configurations mix and match between per-node and aggregated values.
>> In this case there's a good reason though, as a single node running
>> out of memory will lead to query failure, meaning that in addition to
>> total memory used, distribution of memory usage between hosts also
>> matters.
>>
>> > I have hundreds of impala queries and more add hoc queries, making a
>> > pool
>> > for each query is not a visible solution.
>> >
>> > still waiting to understand how the estimate per node related to the
>> > default
>> > memory per node I set up per pool, is it used in the decision of queuing
>> > and
>> > killing the query? and if this is true how it was not kill a query that
>> > was
>> > estimated it needs 8.2TB memory per node.
>> >
>> > Understanding on which parameters impala decides to kill a query can
>> > help
>> > understand to define and divide the memory between the pools.
>>
>> If you set mem_limit at any level (service level, pool level, or query
>> level), it will be used for admission control purposes instead of
>> estimates. So a 8.2TB estimate would not be a problem, if impala can
>> reserve mem_limit amount on each host, it will start running the
>> query.
>>
>> > Passing memory limit per query manually is also not visible and such
>> > settings not needs admission control.
>> >
>> > I have support pool that runs ad hoc query and I can not ask them to use
>> > memory limit per query, and I have analytics pool which is fully
>> > business
>> > and I can rely on admission control if it extremely in accurate.
>>
>> It's a bit tricky to use memory-based admission control with
>> non-trivial ad hoc queries. For simple ad-hoc queries, you can try to
>> come up with a 'good enough' mem_limit, or omit mem_limit and trust
>> impala's estimations. You can check the estimated vs. actual values
>> for a representative set of ad hoc queries to see what would work in
>> your case. I've found that people tend to go with a large enough
>> mem_limit for the ad hoc pool.
>>
>> > Can someone explain me exactly which recommended setting to use per pool
>> > and
>> > which of them rely on impala memory estimates?
>>
>> The documentation of admission control
>> (https://impala.apache.org/docs/build/html/topics/impala_admission.html)
>> gives you a good view on how stuff works, but you will have to figure
>> out how to use these features for your specific use case. That said,
>> when using memory based admission control, it is best practice to
>> always use a mem_limit due to potential inaccuracy of estimates as
>> well as potential variance of estimates between Impala releases. Keep
>> in mind that you can opt to set a default mem_limit for one pool and
>> leave it unset for another.
>>
>> > So my conclusion right now to avoid using any settings rely on the
>> > estimates
>> > and to ignore the estimates when I want to evaluate query.
>>
>> Sounds good.
>>
>> > @mostafa, since my issue with all the query, I think the profile will
>> > not
>> > help me to solve such huge issue.
>> >
>> > I’m planning to move a way from Vertica and rely on impala as a sql
>> > engine
>> > and now fully confused how I can do this if I can’t use the admission
>> > control.
>> >
>> > Last think, is it recommend to use the impala admission control?
>>
>> Yes. Admission control can take a while to understand, but if done
>> right, it works.
>>
>> HTH
>>
>> > On Fri, 23 Feb 2018 at 1:56 Alexander Behm 
>> > wrote:
>> >>
>> 

Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Fawze Abujaber
Thanks jezy for your detailed response.

Yes I read the documentation.

Let simplify my question:

I have pools set up with memory limit per node and concurrency.

If I’m looking on the historical impala queries that I have and the metrics
I have per query, on which metrics I can understand that impala will kill
the query, for example if I have a query with estimate of 2GB and the used
per node is 200mb, what is the default memory values that i need to setup
so the query will not fail.

The second one is the distribution between pools, if one query is running
which metrics o have to look into to know if I submit a query it fail or
not.

On Fri, 23 Feb 2018 at 10:48 Jeszy  wrote:

> Hey Fawze,
>
> Answers inline.
>
> On 23 February 2018 at 01:23, Fawze Abujaber  wrote:
> > There is no option in the admission control to setup memory limit per
> query,
> > the memory limit is per pool and there is a default memory per node for
> > query.
>
> per node for query memory limit multiplied by number of nodes gives
> you a per query memory limit. I agree its confusing that the
> configurations mix and match between per-node and aggregated values.
> In this case there's a good reason though, as a single node running
> out of memory will lead to query failure, meaning that in addition to
> total memory used, distribution of memory usage between hosts also
> matters.
>
> > I have hundreds of impala queries and more add hoc queries, making a pool
> > for each query is not a visible solution.
> >
> > still waiting to understand how the estimate per node related to the
> default
> > memory per node I set up per pool, is it used in the decision of queuing
> and
> > killing the query? and if this is true how it was not kill a query that
> was
> > estimated it needs 8.2TB memory per node.
> >
> > Understanding on which parameters impala decides to kill a query can help
> > understand to define and divide the memory between the pools.
>
> If you set mem_limit at any level (service level, pool level, or query
> level), it will be used for admission control purposes instead of
> estimates. So a 8.2TB estimate would not be a problem, if impala can
> reserve mem_limit amount on each host, it will start running the
> query.
>
> > Passing memory limit per query manually is also not visible and such
> > settings not needs admission control.
> >
> > I have support pool that runs ad hoc query and I can not ask them to use
> > memory limit per query, and I have analytics pool which is fully business
> > and I can rely on admission control if it extremely in accurate.
>
> It's a bit tricky to use memory-based admission control with
> non-trivial ad hoc queries. For simple ad-hoc queries, you can try to
> come up with a 'good enough' mem_limit, or omit mem_limit and trust
> impala's estimations. You can check the estimated vs. actual values
> for a representative set of ad hoc queries to see what would work in
> your case. I've found that people tend to go with a large enough
> mem_limit for the ad hoc pool.
>
> > Can someone explain me exactly which recommended setting to use per pool
> and
> > which of them rely on impala memory estimates?
>
> The documentation of admission control
> (https://impala.apache.org/docs/build/html/topics/impala_admission.html)
> gives you a good view on how stuff works, but you will have to figure
> out how to use these features for your specific use case. That said,
> when using memory based admission control, it is best practice to
> always use a mem_limit due to potential inaccuracy of estimates as
> well as potential variance of estimates between Impala releases. Keep
> in mind that you can opt to set a default mem_limit for one pool and
> leave it unset for another.
>
> > So my conclusion right now to avoid using any settings rely on the
> estimates
> > and to ignore the estimates when I want to evaluate query.
>
> Sounds good.
>
> > @mostafa, since my issue with all the query, I think the profile will not
> > help me to solve such huge issue.
> >
> > I’m planning to move a way from Vertica and rely on impala as a sql
> engine
> > and now fully confused how I can do this if I can’t use the admission
> > control.
> >
> > Last think, is it recommend to use the impala admission control?
>
> Yes. Admission control can take a while to understand, but if done
> right, it works.
>
> HTH
>
> > On Fri, 23 Feb 2018 at 1:56 Alexander Behm 
> wrote:
> >>
> >> The planner memory estimates are conservative and sometimes extremely
> >> inaccurate. In their current form, they are rarely appropriate for
> admission
> >> decisions.
> >>
> >> The recommended practice for memory-based admission control it to set a
> >> mem_limit for every query. You can make this easier by setting up
> different
> >> pools with different mem_limits, e.g. a small/medium/big queries pool or
> >> similar.
> >>
> >> On Thu, Feb 22, 2018 at 3:00 PM, Mostafa Mokhtar 

Re: Estimate peak memory VS used peak memory

2018-02-23 Thread Jeszy
Hey Fawze,

Answers inline.

On 23 February 2018 at 01:23, Fawze Abujaber  wrote:
> There is no option in the admission control to setup memory limit per query,
> the memory limit is per pool and there is a default memory per node for
> query.

per node for query memory limit multiplied by number of nodes gives
you a per query memory limit. I agree its confusing that the
configurations mix and match between per-node and aggregated values.
In this case there's a good reason though, as a single node running
out of memory will lead to query failure, meaning that in addition to
total memory used, distribution of memory usage between hosts also
matters.

> I have hundreds of impala queries and more add hoc queries, making a pool
> for each query is not a visible solution.
>
> still waiting to understand how the estimate per node related to the default
> memory per node I set up per pool, is it used in the decision of queuing and
> killing the query? and if this is true how it was not kill a query that was
> estimated it needs 8.2TB memory per node.
>
> Understanding on which parameters impala decides to kill a query can help
> understand to define and divide the memory between the pools.

If you set mem_limit at any level (service level, pool level, or query
level), it will be used for admission control purposes instead of
estimates. So a 8.2TB estimate would not be a problem, if impala can
reserve mem_limit amount on each host, it will start running the
query.

> Passing memory limit per query manually is also not visible and such
> settings not needs admission control.
>
> I have support pool that runs ad hoc query and I can not ask them to use
> memory limit per query, and I have analytics pool which is fully business
> and I can rely on admission control if it extremely in accurate.

It's a bit tricky to use memory-based admission control with
non-trivial ad hoc queries. For simple ad-hoc queries, you can try to
come up with a 'good enough' mem_limit, or omit mem_limit and trust
impala's estimations. You can check the estimated vs. actual values
for a representative set of ad hoc queries to see what would work in
your case. I've found that people tend to go with a large enough
mem_limit for the ad hoc pool.

> Can someone explain me exactly which recommended setting to use per pool and
> which of them rely on impala memory estimates?

The documentation of admission control
(https://impala.apache.org/docs/build/html/topics/impala_admission.html)
gives you a good view on how stuff works, but you will have to figure
out how to use these features for your specific use case. That said,
when using memory based admission control, it is best practice to
always use a mem_limit due to potential inaccuracy of estimates as
well as potential variance of estimates between Impala releases. Keep
in mind that you can opt to set a default mem_limit for one pool and
leave it unset for another.

> So my conclusion right now to avoid using any settings rely on the estimates
> and to ignore the estimates when I want to evaluate query.

Sounds good.

> @mostafa, since my issue with all the query, I think the profile will not
> help me to solve such huge issue.
>
> I’m planning to move a way from Vertica and rely on impala as a sql engine
> and now fully confused how I can do this if I can’t use the admission
> control.
>
> Last think, is it recommend to use the impala admission control?

Yes. Admission control can take a while to understand, but if done
right, it works.

HTH

> On Fri, 23 Feb 2018 at 1:56 Alexander Behm  wrote:
>>
>> The planner memory estimates are conservative and sometimes extremely
>> inaccurate. In their current form, they are rarely appropriate for admission
>> decisions.
>>
>> The recommended practice for memory-based admission control it to set a
>> mem_limit for every query. You can make this easier by setting up different
>> pools with different mem_limits, e.g. a small/medium/big queries pool or
>> similar.
>>
>> On Thu, Feb 22, 2018 at 3:00 PM, Mostafa Mokhtar 
>> wrote:
>>>
>>> It is recommended to set a per query memory limit as part of admission
>>> and not rely on estimates as they are sometimes inaccurate.
>>> Can you please include the full query profile?
>>>
>>>
>>> On Thu, Feb 22, 2018 at 12:13 PM, Fawze Abujaber 
>>> wrote:

 Hi Mostafa,

 It's not a specific query, almost all the query has such differene
 between the 2 values.

 I can see even queries showing the estimate per node is 8.2 Tib

 User: psanalytics

 Database: default

 Query Type: QUERY
 Coordinator: slpr-dhc014.lpdomain.com

 Duration: 6.48s

 Rows Produced: 708
 Estimated per Node Peak Memory: 8.2 TiB

 Per Node Peak Memory Usage: 1.1 GiB

 Pool: root.impanalytics
 Threads: CPU Time: 20.1m



 How you can explain this behavior, and 

Re: Estimate peak memory VS used peak memory

2018-02-22 Thread Mostafa Mokhtar
It is recommended to set a per query memory limit as part of admission and
not rely on estimates as they are sometimes inaccurate.
Can you please include the full query profile?


On Thu, Feb 22, 2018 at 12:13 PM, Fawze Abujaber  wrote:

> Hi Mostafa,
>
> It's not a specific query, almost all the query has such differene between
> the 2 values.
>
> I can see even queries showing the estimate per node is 8.2 Tib
>
>
>- User: psanalytics
>- Database: default
>- Query Type: QUERY
>- Coordinator: slpr-dhc014.lpdomain.com
>
>- Duration: 6.48s
>- Rows Produced: 708
>- Estimated per Node Peak Memory: 8.2 TiB
>- Per Node Peak Memory Usage: 1.1 GiB
>- Pool: root.impanalytics
>- Threads: CPU Time: 20.1m
>
>
>
> How you can explain this behavior, and for sure i don't have 8.2 Tib
> memory per node to give neither you.
>
> Can you please explain me how i should treat Estimated per Node Peak
> Memory and if it used by impala for the resource pool and admission control
> and what is the relation of this value to the default memory per node that
> i setup for each resource pool?
>
> Below is part of one of the queries profile which the estimate per node
> was ~ @GB and the used was 200MB per node.
>
>
>  Instance 744de1b6228736fa:b54bfaa7000f 
> (host=slpr-dhc004.lpdomain.com:22000):(Total:
> 1s455ms, non-child: 1s292ms, % non-child: 88.82%)
> Hdfs split stats (:<# splits>/):
> 6:1/1.20 MB 2:1/199.83 KB 1:1/1.20 MB 10:2/1.42 MB 8:1/225.57 KB 9:1/191.64
> KB 5:2/289.57 KB 3:2/1012.83 KB
> MemoryUsage(500.000ms): 6.09 MB, 6.09 MB, 3.00 MB
> ThreadUsage(500.000ms): 1, 1, 1
>  - AverageThreadTokens: 1.00
>  - BloomFilterBytes: 0
>  - PeakMemoryUsage: 7.17 MB (7521751)
>  - PeakReservation: 0
>  - PeakUsedReservation: 0
>  - PerHostPeakMemUsage: 106.53 MB (111709581)
>  - RowsProduced: 32.83K (32826)
>  - TotalNetworkReceiveTime: 0.000ns
>  - TotalNetworkSendTime: 1s297ms
>  - TotalStorageWaitTime: 234.356ms
>  - TotalThreadsInvoluntaryContextSwitches: 66 (66)
>  - TotalThreadsTotalWallClockTime: 1s715ms
>- TotalThreadsSysTime: 5.998ms
>- TotalThreadsUserTime: 124.975ms
>  - TotalThreadsVoluntaryContextSwitches: 303 (303)
> Fragment Instance Lifecycle Timings:
>- ExecTime: 1s394ms
>  - ExecTreeExecTime: 67.115ms
>- OpenTime: 32.795ms
>  - ExecTreeOpenTime: 73.243us
>- PrepareTime: 27.602ms
>  - ExecTreePrepareTime: 243.141us
> DataStreamSender (dst_id=11):(Total: 38.747ms, non-child:
> 38.747ms, % non-child: 100.00%)
>- BytesSent: 39.71 MB (41643000)
>- NetworkThroughput(*): 1.97 GB/sec
>- OverallThroughput: 1.00 GB/sec
>- PeakMemoryUsage: 59.38 KB (60800)
>- RowsReturned: 32.83K (32826)
>- SerializeBatchTime: 16.860ms
>- TransmitDataRPCTime: 19.698ms
>- UncompressedRowBatchSize: 77.58 MB (81350840)
> CodeGen:(Total: 56.573ms, non-child: 56.573ms, % non-child:
> 100.00%)
>- CodegenTime: 1.299ms
>- CompileTime: 10.672ms
>- LoadTime: 0.000ns
>- ModuleBitcodeSize: 1.96 MB (2050180)
>- NumFunctions: 16 (16)
>- NumInstructions: 250 (250)
>- OptimizationTime: 21.023ms
>- PeakMemoryUsage: 125.00 KB (128000)
>- PrepareTime: 24.116ms
> SUBPLAN_NODE (id=6):(Total: 67.311ms, non-child: 12.013ms, %
> non-child: 17.85%)
>- PeakMemoryUsage: 627.94 KB (643015)
>- RowsReturned: 32.77K (32768)
>- RowsReturnedRate: 486.81 K/sec
>   NESTED_LOOP_JOIN_NODE (id=9):(Total: 33.999ms, non-child:
> 25.197ms, % non-child: 74.11%)
>  - BuildRows: 0 (0)
>  - BuildTime: 0.000ns
>  - PeakMemoryUsage: 24.00 KB (24576)
>  - ProbeRows: 32.83K (32826)
>  - ProbeTime: 0.000ns
>  - RowsReturned: 16.80M (16795311)
>  - RowsReturnedRate: 493.99 M/sec
> Nested Loop Join Builder:
>- PeakMemoryUsage: 8.00 KB (8192)
> SINGULAR_ROW_SRC_NODE (id=7):
>- PeakMemoryUsage: 0
>- RowsReturned: 0 (0)
>- RowsReturnedRate: 0
>   UNNEST_NODE (id=8):(Total: 8.801ms, non-child: 8.801ms, %
> non-child: 100.00%)
>  - AvgCollectionSize: 1.00
>  - MaxCollectionSize: 1 (1)
>  - MinCollectionSize: 1 (1)
>  - NumCollections: 32.83K (32826)
>  - PeakMemoryUsage: 0
>  - RowsReturned: 1 (1)
>  - RowsReturnedRate: 113.00 /sec
> HDFS_SCAN_NODE (id=5):(Total: 21.299ms, non-child: 21.299ms, %
> non-child: 100.00%)

Re: Estimate peak memory VS used peak memory

2018-02-22 Thread Mostafa Mokhtar
@Fawze,

To best serve your question please share a profile for the problematic
query.

Thanks
Mostafa

On Thu, Feb 22, 2018 at 9:40 AM, Jim Apple  wrote:

> I think compute stats will help estimates be more accurate.
>
> On Thu, Feb 22, 2018 at 4:48 AM, Fawze Abujaber  wrote:
>
>> Hi Guys,
>>
>> In Impala version 2.10 i see a lot that the Estimate per Mode peak memory
>> can reach X30 times of the Per Node Peak Memory usage.
>>
>> For example one of the query the estimate was 9GB while the usage was
>> 30GB.
>>
>> I have 3 questions:
>>
>> 1- Do you think the compute stats will help here?
>> 2- How i can reduce this gap?
>> 3- Does the resource pools based on the Estimate per Mode peak memory?
>> so if for such query i put the default max memory limit to 5GB, will this
>> query fail?
>>
>>
>>
>


Re: Estimate peak memory VS used peak memory

2018-02-22 Thread Jim Apple
I think compute stats will help estimates be more accurate.

On Thu, Feb 22, 2018 at 4:48 AM, Fawze Abujaber  wrote:

> Hi Guys,
>
> In Impala version 2.10 i see a lot that the Estimate per Mode peak memory
> can reach X30 times of the Per Node Peak Memory usage.
>
> For example one of the query the estimate was 9GB while the usage was 30GB.
>
> I have 3 questions:
>
> 1- Do you think the compute stats will help here?
> 2- How i can reduce this gap?
> 3- Does the resource pools based on the Estimate per Mode peak memory? so
> if for such query i put the default max memory limit to 5GB, will this
> query fail?
>
>
>