drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From weijie tong <tongweijie...@gmail.com>
Subject Re: Questions about Drill's multi-thread model
Date Fri, 21 Jul 2017 09:31:22 GMT
Thanks for all your reply @Jinfeng @Paul Rogers.

Our storage plugin is Druid. The reason is that the blocked query exhausts
the storage plugin's concurrent threads. so other subsequent queries will
not be serviced immediately by the Druid plugin.



On Thu, 20 Jul 2017 at 2:15 AM Jinfeng Ni <jni@apache.org> wrote:

> What do you mean by "one query was blocked by the storage"? Are the other
> queries blocked in query planning time, or execution time?
>
> I recalled someone asked the problem related to long query planning. Turns
> out that if one enabled storage plugin is slow to access, it would affect
> every query, even if they do not need to access that slow storage plugin.
> In your case, if the other queries are blocked in planning time, it might
> be caused by the fact that storage plugin is slow due to the first running
> query.  See DRILL-5089.
>
> https://issues.apache.org/jira/browse/DRILL-5089
>
> On Wed, Jul 19, 2017 at 9:14 AM, Paul Rogers <progers@mapr.com> wrote:
>
> > Hi Weijie,
> >
> > There is nothing in Drill’s design that would account for this behavior:
> > each query runs a separate set of threads from any other query; there is
> no
> > synchronization among queries.
> >
> > Did you, perhaps, enable Drill’s ZK-based queueing feature? That would
> > cause later queries to block waiting for the completion of earlier ones.
> >
> > Otherwise, perhaps there is an issue with some particular piece of code.
> > What type of file is being read? In what environment?
> >
> > Thanks,
> >
> > - Paul
> >
> > > On Jul 19, 2017, at 7:20 AM, weijie tong <tongweijie178@gmail.com>
> > wrote:
> > >
> > > Hi there,
> > >   Our product environment has a situation that if one query was blocked
> > by
> > > the storage,then all other queries which come later would took long and
> > > long time to run even they really just need fewer time. At the time
> ,the
> > > cluster's load is not too high.
> > >    I know that every foreman will run in dedicated different  threads.
> I
> > > want to know that IO threads model,whether they are shared by different
> > > foremans' threads. How to explain last scenario's behavior?
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message