Thanks Paul and Kunal,
I think I have the right information now. With Paul's changes (and fixing
up a zoo.cfg error) it isn't crashing, rather failing. Logs attached, still
blowing past memory limits. It does the same thing when re-running the
query from the web console so presumably its not actual
And with logs as attachments.
On Sun, Jan 28, 2018 at 9:40 PM, Francis McGregor-Macdonald <
fran...@mc-mac.com> wrote:
> Thanks Paul and Kunal,
> I think I have the right information now. With Paul's changes (and fixing
> up a zoo.cfg error) it isn't crashing, rather failing. Logs attached, still
I run drill in single-node cluster mode (vs standalone) on macOS and use the
installation procedure in this gist to install/run it (change the drill d/l
version since it's still at 10) :
https://gist.github.com/hrbrmstr/82a3f74b0b353a63a09061207e9f2725
> On Jan 26, 2018, at 3:32 AM, te...@penti
Hi all,
A physical plan attached ... all memory appears to be 0.0 which seems odd?
Thanks
On Sun, Jan 28, 2018 at 10:37 PM, Francis McGregor-Macdonald <
fran...@mc-mac.com> wrote:
> And with logs as attachments.
>
> On Sun, Jan 28, 2018 at 9:40 PM, Francis McGregor-Macdonald <
> fran...@mc-mac.
Hi Francis
Looks like the logs didn’t get attached.
As for the physical plan, ignore the “memory = 0.0” ; because it is a physical
plan and not the actual executed query’s profile.
What you want to do to debug the possible area where the memory is being
consumed is in the query’s profile page.
