[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5

["Tanmay Ambre (Jira)" <ji...@apache.org>]

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

Tanmay Ambre commented on IGNITE-13270:
---------------------------------------

[~zstan] - we dont have distributed joins. the query I provided uses the affinity key to join - hence i think the joins will be collocated. 

also regarding passing integers to query statements. we dont do that. Our input is a text string. 

 

Hope this helps. I was not able to understand your comment completely. Hence unable to answer in detail. 

> Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
> --------------------------------------------------------------
>
>                 Key: IGNITE-13270
>                 URL: https://issues.apache.org/jira/browse/IGNITE-13270
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>    Affects Versions: 2.8, 2.8.1
>            Reporter: Tanmay Ambre
>            Priority: Major
>         Attachments: IDX13270.java, IgniteSqlDistributedJoinSelfTest.java
>
>
> After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes are above 80%. On 2.7.5 the same query was performing very nicely. 
> The query is a join with 3 tables having same affinity key. however, we dont know the affinity key when we are querying and there this results in a merge scan. 
> Query:
> select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C
> where
> A.A_ID = B.A_ID AND
> B.B_ID = C.B_ID AND
> A.AFFINITYKEY = B.AFFINITYKEY AND
> B.AFFINITYKEY = C.AFFINITYKEY AND
> B.B_ID = ? AND
> C.C_ID = ?
>  
> Performance:
> 2.7.5 ~ 2 to 5 ms
> 2.8.0 ~ 6 to 12 seconds
> 2.8.1 ~ within 3 seconds
>  
> Volume (we have a EDA based system where messages come in burst. One burst has approx. 150K events - each event correspond to one query). 
>  
> throughput of our java based processor (that fires this query):
> 2.7.5 ~ 750 transactions per second
> 2.8.0 ~ 3 transactions per second
> 2.8.1 ~ 6 transactions per second
>  
> CPU burn
> 2.7.5 ~ 10 to 15% on each node
> 2.8.0 ~ 100% on 2 nodes other nodes are idling
> 2.8.1 ~ 80 to 90% on each node
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)