You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Tanmay Ambre (Jira)" <ji...@apache.org> on 2020/07/20 12:18:00 UTC

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

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

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

Due to confidentiality of the application and data - can't share the exact query and data. 

However,

Table A has approx. 0.75 million records

Table B has approx. 1.13 million records

Table C has approx. 1.17 million records

> 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
>
> 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)