asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wenhai (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ASTERIXDB-1433) Multiple cores slow down.
Date Wed, 11 May 2016 14:41:12 GMT

     [ https://issues.apache.org/jira/browse/ASTERIXDB-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Wenhai updated ASTERIXDB-1433:
------------------------------
    Environment: 10 nodes X Linux ubuntu/6 cpu X 4 cores/per cpu, 128 GB memory/per node.
    Description: This is a classic hardware platform that shoes up the TB bytes dataset in
total. AsterixDB does extremely well for the complex query that includes multiple join operators.
However, the running trace results demonstrate that, as compared to the big memory configurations,
the data is always re-loaded from the disk to the actual memory. To this end, why not provide
the strategy to keep the intermediate data of the last completed query into the memory and
free them in case the memory is not  enough for the newly query. In some case, the user will
always trigger the query with the different parameters on the same tables, for example, the
variant-parameter aggregation on the single big fact table.
    Component/s: Hyracks Core
     Issue Type: Improvement  (was: Bug)
        Summary: Multiple cores slow down.  (was: Multiple lscores slow down.)

> Multiple cores slow down.
> -------------------------
>
>                 Key: ASTERIXDB-1433
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-1433
>             Project: Apache AsterixDB
>          Issue Type: Improvement
>          Components: Hyracks Core
>         Environment: 10 nodes X Linux ubuntu/6 cpu X 4 cores/per cpu, 128 GB memory/per
node.
>            Reporter: Wenhai
>
> This is a classic hardware platform that shoes up the TB bytes dataset in total. AsterixDB
does extremely well for the complex query that includes multiple join operators. However,
the running trace results demonstrate that, as compared to the big memory configurations,
the data is always re-loaded from the disk to the actual memory. To this end, why not provide
the strategy to keep the intermediate data of the last completed query into the memory and
free them in case the memory is not  enough for the newly query. In some case, the user will
always trigger the query with the different parameters on the same tables, for example, the
variant-parameter aggregation on the single big fact table.



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

Mime
View raw message