Re: How many threads impala start for handling partitioned join?

[俊杰陈]

Thanks for the reply.

I saw IMPALA-3902  seems
to add support for multithread execution.  It describes the goal is to
support running multiple fragment instances on a single node, is that means
coordinator generate multiple instances for a plan fragment on a single
node so that starts multiple exchange nodes to receive data and process? Or
it starts instances for different plan fragments for preparing
the streaming?

2017-10-25 22:08 GMT+08:00 Jeszy :

> Hello JJ,
>
> No, currently Impala uses one thread to execute the join (without
> regard for the amount of partitions that fit into memory).
>
> HTH
>
> On 25 October 2017 at 05:44, 俊杰陈  wrote:
> > Hi
> >
> > When Impala does a partitioned join on a node, it split the build input
> > into partitions until a partition can fit into memory and consume the
> probe
> > input then do the join and output rows.
> >
> > My question is will impala schedule multiple tasks to do join if multiple
> > partitions fit into memory, or iterate over partitions? And for one
> > partition does it use multiple threads to do join?  Thanks in advanced.
> >
> >
> > JJ
>



-- 
Thanks & Best Regards

Podling Report Reminder - November 2017

[johndament]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 15 November 2017, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, November 01).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://wiki.apache.org/incubator/November2017

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Please hold off merging new code changes

[Tim Armstrong]

A few recent changes have destabilised a lot of tests - see IMPALA-6106 and
IMPALA-6108 in particular. Until those are sorted out let's avoid merging
any code changes that don't fix flaky or broken tests - it will just make
it more difficult to root-cause any further failures.

I'll send out another email once things are looking more stable.

Thanks,
Tim

Re: Does this mem-tracker.h assertion ring a bell?

[Tim Armstrong]

Will you file a JIRA for this bug? Sounds like something we don't want to
lose track of.

- Tim

On Wed, Oct 25, 2017 at 11:05 AM, Philip Zeyliger 
wrote:

> Thanks. I'm beginning to think my patch is not causing these breakages. A
> different run was almost clean, with some TPC-DS query tests failing, that
> I think are also new.
>
> -- Philip
>
> On Wed, Oct 25, 2017 at 10:36 AM, Tim Armstrong 
> wrote:
>
> > Yeah it's probably another consequence of
> > https://issues.apache.org/jira/browse/IMPALA-5789. Maybe your patch
> > changed
> > the timing enough to trigger it.
> >
> > I think the bug might be related to using directory.capacity() as the
> > argument to Release(). Calling directory.clear() after releasing the
> memory
> > in FitlerState::Disable() won't necessarily deallocate the memory so we
> > could end up releasing it twice.
> >
> > On Wed, Oct 25, 2017 at 10:11 AM, Mostafa Mokhtar  >
> > wrote:
> >
> > > Maybe related to https://issues.apache.org/jira/browse/IMPALA-6099?
> > >
> > > On Wed, Oct 25, 2017 at 10:02 AM, Philip Zeyliger  >
> > > wrote:
> > >
> > > > Hi folks,
> > > >
> > > > I'm debugging some test failures related to an LLVM/AvroCodegen patch
> > > I've
> > > > got going on. The failures are in the parallel EE tests, and most of
> > them
> > > > are complaining that Impala is out to lunch. It looks like the
> > following
> > > > assertion is firing, causing an impalad to fail, causing many tests
> to
> > > > start failing. (I've also got a minidump, but the build was on
> > > > jenkins.impala.io, so I don't think I have the symbols/binaries to
> use
> > > > it.)
> > > >
> > > > If this sort of thing rings a bell for anyone, please holler!
> > > >
> > > > Obviously I'll work on reproducing this locally to figure it out.
> > > >
> > > > F1025 02:20:43.786911 82485 mem-tracker.h:231] Check failed:
> > > > tracker->consumption_->current_value() >= 0 (-1052615 vs. 0)
> > > > Runtime Filter (Coordinator): Total=-1.00 MB Peak=1.00 MB
> > > > *** Check failure stack trace: ***
> > > > @  0x2f1e11d  google::LogMessage::Fail()
> > > > @  0x2f1f9c2  google::LogMessage::SendToLog()
> > > > @  0x2f1daf7  google::LogMessage::Flush()
> > > > @  0x2f210be  google::LogMessageFatal::~
> LogMessageFatal()
> > > > @  0x17425fb  impala::MemTracker::Release()
> > > > @  0x1fa7e8b  impala::Coordinator::UpdateFilter()
> > > > @  0x186e3cf  impala::ImpalaServer::UpdateFilter()
> > > > @  0x18d824f  impala::ImpalaInternalService:
> > :UpdateFilter()
> > > > @  0x1dda35a
> > > > impala::ImpalaInternalServiceProcessor::process_UpdateFilter()
> > > > @  0x1dd8308
> > > > impala::ImpalaInternalServiceProcessor::dispatchCall()
> > > > @  0x15410ea  apache::thrift::
> > TDispatchProcessor::process()
> > > > @  0x171042b
> > > > apache::thrift::server::TAcceptQueueServer::Task::run()
> > > > @  0x170c307  impala::ThriftThread::RunRunnable()
> > > > @  0x170da13  boost::_mfi::mf2<>::operator()()
> > > > @  0x170d8a9  boost::_bi::list3<>::operator()<>()
> > > > @  0x170d5f5  boost::_bi::bind_t<>::operator()()
> > > > @  0x170d508
> > > > boost::detail::function::void_function_obj_invoker0<>::invoke()
> > > > @  0x171bdfc  boost::function0<>::operator()()
> > > > @  0x19f3393  impala::Thread::SuperviseThread()
> > > > @  0x19fbf26  boost::_bi::list4<>::operator()<>()
> > > > @  0x19fbe69  boost::_bi::bind_t<>::operator()()
> > > > @  0x19fbe2c  boost::detail::thread_data<>::run()
> > > > @  0x20a7c9a  thread_proxy
> > > > @ 0x7fe6536186ba  start_thread
> > > > @ 0x7fe65334e3dd  clone
> > > > r.java:81)
> > > >
> > >
> >
>

Re: Does this mem-tracker.h assertion ring a bell?

[Philip Zeyliger]

Thanks. I'm beginning to think my patch is not causing these breakages. A
different run was almost clean, with some TPC-DS query tests failing, that
I think are also new.

-- Philip

On Wed, Oct 25, 2017 at 10:36 AM, Tim Armstrong 
wrote:

> Yeah it's probably another consequence of
> https://issues.apache.org/jira/browse/IMPALA-5789. Maybe your patch
> changed
> the timing enough to trigger it.
>
> I think the bug might be related to using directory.capacity() as the
> argument to Release(). Calling directory.clear() after releasing the memory
> in FitlerState::Disable() won't necessarily deallocate the memory so we
> could end up releasing it twice.
>
> On Wed, Oct 25, 2017 at 10:11 AM, Mostafa Mokhtar 
> wrote:
>
> > Maybe related to https://issues.apache.org/jira/browse/IMPALA-6099?
> >
> > On Wed, Oct 25, 2017 at 10:02 AM, Philip Zeyliger 
> > wrote:
> >
> > > Hi folks,
> > >
> > > I'm debugging some test failures related to an LLVM/AvroCodegen patch
> > I've
> > > got going on. The failures are in the parallel EE tests, and most of
> them
> > > are complaining that Impala is out to lunch. It looks like the
> following
> > > assertion is firing, causing an impalad to fail, causing many tests to
> > > start failing. (I've also got a minidump, but the build was on
> > > jenkins.impala.io, so I don't think I have the symbols/binaries to use
> > > it.)
> > >
> > > If this sort of thing rings a bell for anyone, please holler!
> > >
> > > Obviously I'll work on reproducing this locally to figure it out.
> > >
> > > F1025 02:20:43.786911 82485 mem-tracker.h:231] Check failed:
> > > tracker->consumption_->current_value() >= 0 (-1052615 vs. 0)
> > > Runtime Filter (Coordinator): Total=-1.00 MB Peak=1.00 MB
> > > *** Check failure stack trace: ***
> > > @  0x2f1e11d  google::LogMessage::Fail()
> > > @  0x2f1f9c2  google::LogMessage::SendToLog()
> > > @  0x2f1daf7  google::LogMessage::Flush()
> > > @  0x2f210be  google::LogMessageFatal::~LogMessageFatal()
> > > @  0x17425fb  impala::MemTracker::Release()
> > > @  0x1fa7e8b  impala::Coordinator::UpdateFilter()
> > > @  0x186e3cf  impala::ImpalaServer::UpdateFilter()
> > > @  0x18d824f  impala::ImpalaInternalService:
> :UpdateFilter()
> > > @  0x1dda35a
> > > impala::ImpalaInternalServiceProcessor::process_UpdateFilter()
> > > @  0x1dd8308
> > > impala::ImpalaInternalServiceProcessor::dispatchCall()
> > > @  0x15410ea  apache::thrift::
> TDispatchProcessor::process()
> > > @  0x171042b
> > > apache::thrift::server::TAcceptQueueServer::Task::run()
> > > @  0x170c307  impala::ThriftThread::RunRunnable()
> > > @  0x170da13  boost::_mfi::mf2<>::operator()()
> > > @  0x170d8a9  boost::_bi::list3<>::operator()<>()
> > > @  0x170d5f5  boost::_bi::bind_t<>::operator()()
> > > @  0x170d508
> > > boost::detail::function::void_function_obj_invoker0<>::invoke()
> > > @  0x171bdfc  boost::function0<>::operator()()
> > > @  0x19f3393  impala::Thread::SuperviseThread()
> > > @  0x19fbf26  boost::_bi::list4<>::operator()<>()
> > > @  0x19fbe69  boost::_bi::bind_t<>::operator()()
> > > @  0x19fbe2c  boost::detail::thread_data<>::run()
> > > @  0x20a7c9a  thread_proxy
> > > @ 0x7fe6536186ba  start_thread
> > > @ 0x7fe65334e3dd  clone
> > > r.java:81)
> > >
> >
>

Re: Does this mem-tracker.h assertion ring a bell?

[Tim Armstrong]

Yeah it's probably another consequence of
https://issues.apache.org/jira/browse/IMPALA-5789. Maybe your patch changed
the timing enough to trigger it.

I think the bug might be related to using directory.capacity() as the
argument to Release(). Calling directory.clear() after releasing the memory
in FitlerState::Disable() won't necessarily deallocate the memory so we
could end up releasing it twice.

On Wed, Oct 25, 2017 at 10:11 AM, Mostafa Mokhtar 
wrote:

> Maybe related to https://issues.apache.org/jira/browse/IMPALA-6099?
>
> On Wed, Oct 25, 2017 at 10:02 AM, Philip Zeyliger 
> wrote:
>
> > Hi folks,
> >
> > I'm debugging some test failures related to an LLVM/AvroCodegen patch
> I've
> > got going on. The failures are in the parallel EE tests, and most of them
> > are complaining that Impala is out to lunch. It looks like the following
> > assertion is firing, causing an impalad to fail, causing many tests to
> > start failing. (I've also got a minidump, but the build was on
> > jenkins.impala.io, so I don't think I have the symbols/binaries to use
> > it.)
> >
> > If this sort of thing rings a bell for anyone, please holler!
> >
> > Obviously I'll work on reproducing this locally to figure it out.
> >
> > F1025 02:20:43.786911 82485 mem-tracker.h:231] Check failed:
> > tracker->consumption_->current_value() >= 0 (-1052615 vs. 0)
> > Runtime Filter (Coordinator): Total=-1.00 MB Peak=1.00 MB
> > *** Check failure stack trace: ***
> > @  0x2f1e11d  google::LogMessage::Fail()
> > @  0x2f1f9c2  google::LogMessage::SendToLog()
> > @  0x2f1daf7  google::LogMessage::Flush()
> > @  0x2f210be  google::LogMessageFatal::~LogMessageFatal()
> > @  0x17425fb  impala::MemTracker::Release()
> > @  0x1fa7e8b  impala::Coordinator::UpdateFilter()
> > @  0x186e3cf  impala::ImpalaServer::UpdateFilter()
> > @  0x18d824f  impala::ImpalaInternalService::UpdateFilter()
> > @  0x1dda35a
> > impala::ImpalaInternalServiceProcessor::process_UpdateFilter()
> > @  0x1dd8308
> > impala::ImpalaInternalServiceProcessor::dispatchCall()
> > @  0x15410ea  apache::thrift::TDispatchProcessor::process()
> > @  0x171042b
> > apache::thrift::server::TAcceptQueueServer::Task::run()
> > @  0x170c307  impala::ThriftThread::RunRunnable()
> > @  0x170da13  boost::_mfi::mf2<>::operator()()
> > @  0x170d8a9  boost::_bi::list3<>::operator()<>()
> > @  0x170d5f5  boost::_bi::bind_t<>::operator()()
> > @  0x170d508
> > boost::detail::function::void_function_obj_invoker0<>::invoke()
> > @  0x171bdfc  boost::function0<>::operator()()
> > @  0x19f3393  impala::Thread::SuperviseThread()
> > @  0x19fbf26  boost::_bi::list4<>::operator()<>()
> > @  0x19fbe69  boost::_bi::bind_t<>::operator()()
> > @  0x19fbe2c  boost::detail::thread_data<>::run()
> > @  0x20a7c9a  thread_proxy
> > @ 0x7fe6536186ba  start_thread
> > @ 0x7fe65334e3dd  clone
> > r.java:81)
> >
>

Re: Does this mem-tracker.h assertion ring a bell?

[Mostafa Mokhtar]

Maybe related to https://issues.apache.org/jira/browse/IMPALA-6099?

On Wed, Oct 25, 2017 at 10:02 AM, Philip Zeyliger 
wrote:

> Hi folks,
>
> I'm debugging some test failures related to an LLVM/AvroCodegen patch I've
> got going on. The failures are in the parallel EE tests, and most of them
> are complaining that Impala is out to lunch. It looks like the following
> assertion is firing, causing an impalad to fail, causing many tests to
> start failing. (I've also got a minidump, but the build was on
> jenkins.impala.io, so I don't think I have the symbols/binaries to use
> it.)
>
> If this sort of thing rings a bell for anyone, please holler!
>
> Obviously I'll work on reproducing this locally to figure it out.
>
> F1025 02:20:43.786911 82485 mem-tracker.h:231] Check failed:
> tracker->consumption_->current_value() >= 0 (-1052615 vs. 0)
> Runtime Filter (Coordinator): Total=-1.00 MB Peak=1.00 MB
> *** Check failure stack trace: ***
> @  0x2f1e11d  google::LogMessage::Fail()
> @  0x2f1f9c2  google::LogMessage::SendToLog()
> @  0x2f1daf7  google::LogMessage::Flush()
> @  0x2f210be  google::LogMessageFatal::~LogMessageFatal()
> @  0x17425fb  impala::MemTracker::Release()
> @  0x1fa7e8b  impala::Coordinator::UpdateFilter()
> @  0x186e3cf  impala::ImpalaServer::UpdateFilter()
> @  0x18d824f  impala::ImpalaInternalService::UpdateFilter()
> @  0x1dda35a
> impala::ImpalaInternalServiceProcessor::process_UpdateFilter()
> @  0x1dd8308
> impala::ImpalaInternalServiceProcessor::dispatchCall()
> @  0x15410ea  apache::thrift::TDispatchProcessor::process()
> @  0x171042b
> apache::thrift::server::TAcceptQueueServer::Task::run()
> @  0x170c307  impala::ThriftThread::RunRunnable()
> @  0x170da13  boost::_mfi::mf2<>::operator()()
> @  0x170d8a9  boost::_bi::list3<>::operator()<>()
> @  0x170d5f5  boost::_bi::bind_t<>::operator()()
> @  0x170d508
> boost::detail::function::void_function_obj_invoker0<>::invoke()
> @  0x171bdfc  boost::function0<>::operator()()
> @  0x19f3393  impala::Thread::SuperviseThread()
> @  0x19fbf26  boost::_bi::list4<>::operator()<>()
> @  0x19fbe69  boost::_bi::bind_t<>::operator()()
> @  0x19fbe2c  boost::detail::thread_data<>::run()
> @  0x20a7c9a  thread_proxy
> @ 0x7fe6536186ba  start_thread
> @ 0x7fe65334e3dd  clone
> r.java:81)
>

Does this mem-tracker.h assertion ring a bell?

[Philip Zeyliger]

Hi folks,

I'm debugging some test failures related to an LLVM/AvroCodegen patch I've
got going on. The failures are in the parallel EE tests, and most of them
are complaining that Impala is out to lunch. It looks like the following
assertion is firing, causing an impalad to fail, causing many tests to
start failing. (I've also got a minidump, but the build was on
jenkins.impala.io, so I don't think I have the symbols/binaries to use it.)

If this sort of thing rings a bell for anyone, please holler!

Obviously I'll work on reproducing this locally to figure it out.

F1025 02:20:43.786911 82485 mem-tracker.h:231] Check failed:
tracker->consumption_->current_value() >= 0 (-1052615 vs. 0)
Runtime Filter (Coordinator): Total=-1.00 MB Peak=1.00 MB
*** Check failure stack trace: ***
@  0x2f1e11d  google::LogMessage::Fail()
@  0x2f1f9c2  google::LogMessage::SendToLog()
@  0x2f1daf7  google::LogMessage::Flush()
@  0x2f210be  google::LogMessageFatal::~LogMessageFatal()
@  0x17425fb  impala::MemTracker::Release()
@  0x1fa7e8b  impala::Coordinator::UpdateFilter()
@  0x186e3cf  impala::ImpalaServer::UpdateFilter()
@  0x18d824f  impala::ImpalaInternalService::UpdateFilter()
@  0x1dda35a
impala::ImpalaInternalServiceProcessor::process_UpdateFilter()
@  0x1dd8308
impala::ImpalaInternalServiceProcessor::dispatchCall()
@  0x15410ea  apache::thrift::TDispatchProcessor::process()
@  0x171042b
apache::thrift::server::TAcceptQueueServer::Task::run()
@  0x170c307  impala::ThriftThread::RunRunnable()
@  0x170da13  boost::_mfi::mf2<>::operator()()
@  0x170d8a9  boost::_bi::list3<>::operator()<>()
@  0x170d5f5  boost::_bi::bind_t<>::operator()()
@  0x170d508
boost::detail::function::void_function_obj_invoker0<>::invoke()
@  0x171bdfc  boost::function0<>::operator()()
@  0x19f3393  impala::Thread::SuperviseThread()
@  0x19fbf26  boost::_bi::list4<>::operator()<>()
@  0x19fbe69  boost::_bi::bind_t<>::operator()()
@  0x19fbe2c  boost::detail::thread_data<>::run()
@  0x20a7c9a  thread_proxy
@ 0x7fe6536186ba  start_thread
@ 0x7fe65334e3dd  clone
r.java:81)

[GitHub] incubator-impala pull request #3: fix doc about parquet under incubation

[Humbedooh]

Github user Humbedooh closed the pull request at:

https://github.com/apache/incubator-impala/pull/3


---

Re: How many threads impala start for handling partitioned join?

[Jeszy]

Hello JJ,

No, currently Impala uses one thread to execute the join (without
regard for the amount of partitions that fit into memory).

HTH

On 25 October 2017 at 05:44, 俊杰陈  wrote:
> Hi
>
> When Impala does a partitioned join on a node, it split the build input
> into partitions until a partition can fit into memory and consume the probe
> input then do the join and output rows.
>
> My question is will impala schedule multiple tasks to do join if multiple
> partitions fit into memory, or iterate over partitions? And for one
> partition does it use multiple threads to do join?  Thanks in advanced.
>
>
> JJ