You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@asterixdb.apache.org by "Wenhai (JIRA)" <ji...@apache.org> on 2016/05/11 15:08:12 UTC

[jira] [Updated] (ASTERIXDB-1433) Multiple cores with huge memory slow down in the big fact table aggregation.

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

Wenhai updated ASTERIXDB-1433:
------------------------------
    Summary: Multiple cores with huge memory slow down in the big fact table aggregation.  (was: Multiple cores slow down.)

> Multiple cores with huge memory slow down in the big fact table aggregation.
> ----------------------------------------------------------------------------
>
>                 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 scale of 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)