drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sudheesh Katkam (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DRILL-4046) Performance regression in some tpch queries with 1.3rc0 build
Date Sat, 07 Nov 2015 01:44:11 GMT

    [ https://issues.apache.org/jira/browse/DRILL-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14994858#comment-14994858
] 

Sudheesh Katkam edited comment on DRILL-4046 at 11/7/15 1:43 AM:
-----------------------------------------------------------------

The only thing that is consistent about these regressions is that there are a lot of fragments
in this state (waiting to get the ISOChronology instance):
{code}
"29c6bb10-3447-65c9-1e7c-985afdcb83ea:frag:7:137" daemon prio=10 tid=0x00007f593290e000 nid=0x2132
waiting for monitor entry [0x00007f58998f2000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at org.joda.time.chrono.ISOChronology.getInstance(ISOChronology.java:104)
        - waiting to lock <0x000000060d627e90> (a java.util.HashMap)
        at org.joda.time.chrono.ISOChronology.getInstance(ISOChronology.java:86)
        at org.joda.time.DateTimeUtils.getChronology(DateTimeUtils.java:283)
        at org.joda.time.format.DateTimeFormatter.selectChronology(DateTimeFormatter.java:942)
        at org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:851)
        at org.joda.time.DateTime.parse(DateTime.java:144)
        at org.apache.drill.exec.test.generated.FiltererGen87.doEval(FilterTemplate2.java:144)
        at org.apache.drill.exec.test.generated.FiltererGen87.filterBatchNoSV(FilterTemplate2.java:99)
        at org.apache.drill.exec.test.generated.FiltererGen87.filterBatch(FilterTemplate2.java:72)
        at org.apache.drill.exec.physical.impl.filter.FilterRecordBatch.doWork(FilterRecordBatch.java:80)
        at org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:93)
        at org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:147)
...
{code}

This has been fixed in the latest version of [ISOChronology|https://github.com/JodaOrg/joda-time/commit/634066471f2941eddfcca3ed2a62c9d254cabccb].
What I don't understand is why DRILL-3242 (or patches around that) would make this bug appear
more frequently.


was (Author: sudheeshkatkam):
The only thing that is consistent about this regressions is that there are a lot of fragments
in this state (waiting to get the ISOChronology instance):
{code}
"29c6bb10-3447-65c9-1e7c-985afdcb83ea:frag:7:137" daemon prio=10 tid=0x00007f593290e000 nid=0x2132
waiting for monitor entry [0x00007f58998f2000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at org.joda.time.chrono.ISOChronology.getInstance(ISOChronology.java:104)
        - waiting to lock <0x000000060d627e90> (a java.util.HashMap)
        at org.joda.time.chrono.ISOChronology.getInstance(ISOChronology.java:86)
        at org.joda.time.DateTimeUtils.getChronology(DateTimeUtils.java:283)
        at org.joda.time.format.DateTimeFormatter.selectChronology(DateTimeFormatter.java:942)
        at org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:851)
        at org.joda.time.DateTime.parse(DateTime.java:144)
        at org.apache.drill.exec.test.generated.FiltererGen87.doEval(FilterTemplate2.java:144)
        at org.apache.drill.exec.test.generated.FiltererGen87.filterBatchNoSV(FilterTemplate2.java:99)
        at org.apache.drill.exec.test.generated.FiltererGen87.filterBatch(FilterTemplate2.java:72)
        at org.apache.drill.exec.physical.impl.filter.FilterRecordBatch.doWork(FilterRecordBatch.java:80)
        at org.apache.drill.exec.record.AbstractSingleRecordBatch.innerNext(AbstractSingleRecordBatch.java:93)
        at org.apache.drill.exec.record.AbstractRecordBatch.next(AbstractRecordBatch.java:147)
...
{code}

This has been fixed in the latest version of [ISOChronology|https://github.com/JodaOrg/joda-time/commit/634066471f2941eddfcca3ed2a62c9d254cabccb].
What I don't understand is why DRILL-3242 (or patches around that) would make this bug appear
more frequently.

> Performance regression in some tpch queries with 1.3rc0 build
> -------------------------------------------------------------
>
>                 Key: DRILL-4046
>                 URL: https://issues.apache.org/jira/browse/DRILL-4046
>             Project: Apache Drill
>          Issue Type: Bug
>            Reporter: Jacques Nadeau
>            Assignee: Jacques Nadeau
>         Attachments: profiles.tar.gz
>
>
> ||commit/query||14||15||18||20||
> |[839f8da|https://github.com/apache/drill/commit/839f8dac2e2d0479a1552701a5274ebe8416fea6]|10,253|14,642|32,993|21,251|
> |[e7db9dc|https://github.com/apache/drill/commit/e7db9dcacbc39c4797de1aa29b119a7428451dea]|85,061|211,400|900,020|34,066|
> (Time in milliseconds; 900 second timeout)
> + These regressions are not consistent i.e. on multiple runs, some runs do not vary from
the baseline.
> + TPCH 18 did not regress without timing out (on runs until now).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message