Hi,
Using version 1.5, DirectMemory is currently set at 32GB, heap is at
8GB. We have been trying to perform multiple aggregation in one query (see
below) on 40 Billions+ rows stored on 13 nodes. We are using parquet format.
We keep getting OutOfMemoryException: Failure allocating buffer..
ombination of things that work in
> there.
> >
> > https://drill.apache.org/docs/troubleshooting/#memory-issues
> >
> > Back to your spill stuff if you disable hash aggregation, do you know if
> > your spill directories are setup? That may be part of the issue, I am not
&
uery.
>
> A plan would be grateful as well.
>
> Thanks
>
> On Mon, Apr 4, 2016 at 3:09 PM, François Méthot <fmetho...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Querying 150 Billion records spread over ~21 000 parquets stored in
> hdfs
> > on 13 nodes (6
It might just adds up to the mystery of this issue but when we start
getting those hanging CTAS query,
if we restart our drill cluster and the problem goes away.
Next time we start getting this problem I will try to collect the JStack
output of the foreman too.
Thanks for looking into this.
Hi,
Querying 150 Billion records spread over ~21 000 parquets stored in hdfs
on 13 nodes (6 cores each, Max Dir. Mem: 32GB, Max Heap 8 GB).
Is their a known issue or drill limitation that would explain why the first
query below can't return the expected single row and aggregation ?
create
mory_per_node and you can also reduce the value of
> > planner.width.max_per_node. Please note that reducing the value of the
> > latter option may increase the query's execution time.
> >
> > On Wed, Mar 16, 2016 at 2:47 PM, François Méthot <fmetho...@gmail.com>
> > wr
Hi,
Using Drill 1.5, 13 nodes (6 cores each, Max Dir. Mem: 32GB, Max Heap 8 GB).
Sometime our CTAS queries gets "stuck". It runs for few hours or days and
in the Fragment profiles graph, we see that the query is waiting on a
single fragment ( for what appears to be a single horizontal line in
lso causes the issue to
happen.
ex: select col1 from hdfs.`/datasrc/` where dir0>= 1234567;
We ended up giving "execute" access to all the data file.
We would really like to know if this is the intend to have drill to expect
execute access permission on data files.
Thanks
On Tue, A
r0>= 1234567;
> >
> > We ended up giving "execute" access to all the data file.
> >
> > We would really like to know if this is the intend to have drill to
> expect
> > execute access permission on data files.
> >
> > Thanks
> >
> > On
ld resolve the inconsistency we see
using the UDFs.
Thanks
On Thu, Apr 14, 2016 at 1:20 PM, François Méthot <fmetho...@gmail.com>
wrote:
> I was able to reproduce this on 1.5 running on a cluster
> and on 1.6 in embedded mode.
>
> Within a single select, if I select the s
ay from 1.8.
we will test with the most recent version of 1.8 when we get the chance.
Francois
On Fri, Apr 15, 2016 at 10:57 AM, François Méthot <fmetho...@gmail.com>
wrote:
> We dig down the problem even more and we now have a reproducible issue
> even without using UDF
I was able to reproduce this on 1.5 running on a cluster
and on 1.6 in embedded mode.
Within a single select, if I select the same udf(value) multiple time,
different result may get outputted for each columns.
ex:
select name, ilike(name, 'jack'), ilike(name, 'jack'), ilike(name, 'jack'),
free to assign the Jira to yourself and post a pull request.
>
> -- Zelaine
>
> On Wed, Sep 14, 2016 at 11:49 AM, François Méthot <fmetho...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I have on my local repo a fix for
> >
> > https://issues.apache.or
ting.
> >
> > On Wed, Sep 28, 2016 at 8:55 AM, François Méthot <fmetho...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> Since release 1.8,
> >>
> >> we have a workspace hdfs.datarepo1 mapped to
> >> /year/month/da
ages in the logs around the time of failure
> on any of the drillbits? Specially on atsqa4-133.qa.lab? Specially this one
> (“..” are place holders):
> Message of mode .. of rpc type .. took longer than ..ms. Actual
> duration was ..ms.
>
> Thank you,
> Sudheesh
>
> &g
e.
> + Are both messages on the same Drillbit?
>
> The other warnings can be ignored.
>
> Thank you,
> Sudheesh
>
> [1] I just realized that atsqa4-133.qa.lab is in one of our test
> environments :)
> [2] https://issues.apache.org/jira/browse/DRILL-4766 <
> https://i
Hi,
Since release 1.8,
we have a workspace hdfs.datarepo1 mapped to
/year/month/day/
containging csv.gz
if we do select count(1) on any level of the dir structure like
select count(1) from hdfs.datarepo1.`/2016/08`;
We get
Error: SYSTEM ERROR: IllegalStateException: You cannot convert a
n, Sep 19, 2016 at 2:59 PM, François Méthot <fmetho...@gmail.com>
wrote:
> Hi Sudheesh,
>
> If I add selection filter so that no row are returned, the same problem
> occur. I also simplified the query to include only few integer columns.
>
> That particular data repo is ~200+ Bi
and registered again right after?
We are using Zookeeper 3.4.5
On Wed, Sep 28, 2016 at 10:36 AM, François Méthot <fmetho...@gmail.com>
wrote:
> Hi,
>
> We have switched to 1.8 and we are still getting node disconnection.
>
> We did many tests, we thought init
; data distribution for sure. It would be good if you can provide more
> details i.e. how the data is
> distributed in the cluster and how the load on the nodes changed when
> affinity factor was increased.
>
> Thanks,
> Padma
>
>
> > On Oct 14, 2016, at 6:45 PM, Franç
y remote reads which causes lags in
> drillbit to ZooKeeper heartbeats (since these services use the same
> network)? Maybe others can comment here.
> >
> > Thank you,
> > Sudheesh
> >
> >> On Oct 12, 2016, at 6:06 PM, François Méthot <fmeth
Hi,
Is there a way to limit the number of files produced by a CTAS query ?
I would like the speed benefits of having hundreds of scanner fragment but
don't want to deal with hundreds of output files.
Our usecase right now is using 880 thread to scan and produce a report
output spread over... 880
with zookeeper?
On Fri, Sep 30, 2016 at 4:21 PM, François Méthot <fmetho...@gmail.com>
wrote:
> After the 30 seconds gap, all the Drill nodes receives the following:
>
> 2016-09-26 20:07:38,629 [Curator-ServiceCache-0] Debug Active drillbit set
> changed. Now includes 220 total bits. New
eing written to.
>
>
> Could you file a JIRA for this?
>
>
> Thanks
>
> Kunal
>
> ________
> From: François Méthot <fmetho...@gmail.com>
> Sent: Thursday, March 23, 2017 9:08:51 AM
> To: dev@drill.apache.org
> Subject: Re: Single
Hi,
Is there a way to force Drill to store CTAS generated parquet file as a
single block when using HDFS? Java HDFS API allows to do that, files could
be created with the Parquet block-size.
We are using Drill on hdfs configured with block size of 128MB. Changing
this size is not an option at
; it will create more blocks on HDFS.
> Can you let me know what is the HDFS API that would allow you to
> do otherwise ?
>
> Thanks,
> Padma
>
>
> > On Mar 22, 2017, at 11:54 AM, François Méthot <fmetho...@gmail.com>
> wrote:
> >
> > Hi,
>
e configured store.parquet.block-size to the
> create call.
> I will try it out and see. will let you know.
>
> Thanks,
> Padma
>
>
> > On Mar 22, 2017, at 4:16 PM, François Méthot <fmetho...@gmail.com>
> wrote:
> >
> > Here are 2 links I could find:
> >
> >
lated improvements that Drill 1.10 carried out.
>
> If the problem goes away, could you file a JIRA and share the sample query
> and data to allow us a repro ?
>
> Thanks
>
> Kunal
>
>
> From: François Méthot <fmetho...@gmail.com>
> S
Hi Ted,
We did a proof of concept with reading pcap from drill. Our approach was
to avoid writing yet another pcap decoder so we tried to adapt Drill to use
an existing one. We took Tshark as an example. It already comes with 1000s
of dissectors.
We approached the problem from a different
Hi,
I need to develop unit test of our storage plugins and if possible I
would like to borrow from the tests done in "TestCsvHeader.java" and other
classes in that package.
Those tests depends on BaseTestQuery, DrillTest and ExecTest classes which
are not packaged in the Drill release
Hi,
We have been having client-foreman connection and ZkConnection issue few
months ago. It went from annoying to a show stopper when we moved from a 12
nodes cluster to a 220 nodes cluster.
Nodes specs
- 8 cores total (2 x E5620)
- 72 GB RAM Total
- Other applications share the same hardware.
that
> is usually harder to restructure the data than system settings.
>
> --Andries
>
>
>
> On 6/29/17, 7:39 AM, "François Méthot" <fmetho...@gmail.com> wrote:
>
> Hi,
>
> I am investigating issue where we are started getting Out of Heap
>
Hi,
I am investigating issue where we are started getting Out of Heap space
error when querying parquet files in Drill 1.10. It is currently set to 8GB
heap, and 20GB off -heap. We can't spare more.
We usually query 0.7 to 1.2 GB parquet files. recently we have been more on
the 1.2GB side. For
ps://github.com/apache/drill/blob/master/exec/java-
> exec/src/test/java/org/apache/drill/test/package-info.java
> [4] https://github.com/apache/drill/blob/master/exec/java-
> exec/src/test/java/org/apache/drill/test/ExampleTest.java
>
>
> > On Apr 20, 2017, at 11:23 AM, François Méth
Hi,
I have been using drill for more than year now, we are running 1.10.
My queries can spend from 5 to 10 minutes for planning because I am dealing
with lots of file in HDFS. (then 5 min to 60 min for execution)
I maintain a rolling window of data partitionned by the epoch seconds
rounded
Thanks Padma,
Would we benefits at all from running metadata on directories that we know
we will never modify?
We would end up with:
/mydata/3/(Metadata generated...)
/mydata/4/(Metadata generated...)
/mydata/.../(Metadata generated...)
/mydata/109/(Metadata generated...)
/mydata/110/(Current
Hi,
Congrat for the 1.11 release, we are happy to have our suggestion
implemented in the new release (automatic HDFS block size for parquet
files).
It seems like we are pushing the limit of Drill with new type query...(I am
learning new SQL trick in the process)
We are trying to aggregate a
sValue(out.rootAsMap());
firstSeen.value=1;
}
}
@Override
public void output()
{
}
@Override
public void reset()
{
out.clear();
firstSeen.value=0;
}
}
}
On 30 August 2017 at 16:57, François Méthot <fmetho...@gmail.com> w
Hi again,
I am running into an issue on a query done on 760 000 parquet files
stored in HDFS. We are using Drill 1.10, 8GB heap, 20GB direct mem. Drill
runs with debug log enabled all the time.
The query is standard select on 8 fields from hdfs.`/path` where this =
that
For about an
Hi,
Is there a workaround for this Jira issue:
Error: DATA_READ ERROR: Error parsing JSON - You tried to start when you
are using a ValueWriter of type NullableVarCharWriterImpl.
File /tmp/test.json
Record 2
Fragment 0:0
https://issues.apache.org/jira/browse/DRILL-4520
I tried Union with a
better off just using something like a CSV format.
>
>
>
> -----Original Message-
> From: François Méthot [mailto:fmetho...@gmail.com]
> Sent: Tuesday, October 17, 2017 10:35 AM
> To: dev@drill.apache.org
> Subject: log flooded by "date values definitively CORRECT"
Hi all,
Drill 1.12 has been serving us well for far, we are now interested in
Kafka adhoc query support and decided to upgrade to Drill 1.16.
I have a query that involve multiple embedded select statement that now
fails after the update.
It uses our custom function regexExtract that parses each
Hi,
When using Drill (1.15) with Kafka Topics containing Json data, if the
Message Value is null, the JsonMessageReader is not able to process the row
and stop the query.
Error: DATA_READ_ERROR: Failure while reading message from Kafka.
RecordReader was atrecord 1
null
Fragment 1:0
Hi,
I am looking for an explanation to a workaround I have found to an issue
that has been bugging my team for the past weeks.
Last June we moved from Drill 1.12 to Drill 1.19... Long overdue upgrade!
Not long after we started getting the issue described below.
We run a query daily on about
44 matches
Mail list logo
