Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

SQL causing 100% CPU usage on stage (not seen on prod yet, stage has more data) #2210

Open
aslakknutsen opened this issue Aug 3, 2018 · 3 comments

Comments

@aslakknutsen
Copy link
Contributor

aslakknutsen commented Aug 3, 2018

 SELECT count(*) over () as cnt2 , * FROM "work_items" 
    LEFT JOIN iterations "iter" ON "work_items"."fields" @> concat('{"system.iteration": "', iter.id, '"}')::jsonb 
    WHERE "work_items"."deleted_at" IS NULL 
    AND 
    (
        (
            (
                (
                    (
                        (
                            (
                                "work_items"."space_id" = 'b5948976-22ab-4221-91c5-d70674469fdd'
                            ) 
                            AND 
                            (
                                "work_items"."fields" @> '{"system.iteration" : "6bab05ad-56fd-4f96-bc12-bbfc8f4a1f65"}'
                            )
                        )
                        OR
                        (
                            "work_items"."fields" @> '{"system.labels" : ["6bab05ad-56fd-4f96-bc12-bbfc8f4a1f65"]}'
                        )
                    )
                    OR
                    (
                        "iter"."name" = 'x'
                    )
                )
                AND
                (
                    (
                        NOT 
                        (
                            "work_items"."fields" @> '{"system.state" : "closed"}'
                        )
                        AND NOT
                        (
                            "work_items"."fields" @> '{"system.state" : "Done"}'
                        )
                    )
                    AND NOT 
                    (
                        "work_items"."fields" @> '{"system.state" : "Removed"}'
                    )
                )
            )
        )
    )
    ORDER BY execution_order desc LIMIT 200 OFFSET 0;

This ends up in a full table scan of iterations and loop over each iteration against the workitems table etc. 57000*124000

This basically never returns.

If you add a

AND iter.space_id = $2 

it returns in 0.7ms.

@kwk
Copy link
Collaborator

kwk commented Aug 3, 2018

@aslakknutsen

This ends up in a full table scan of iterations and loop over each iteration against the workitems table etc. 57000*124000

but the

LEFT JOIN iterations "iter" ON "work_items"."fields" @> concat('{"system.iteration": "', iter.id, '"}')::jsonb 

should ensure that only one area is joined to each work item, shouldn't it?

@GeorgeActon
Copy link

@kwk @aslakknutsen if this affects OSIO, can you create a bug on openshifio and link to this.
thats where we get visibility to our team

@kwk
Copy link
Collaborator

kwk commented Aug 3, 2018

@kwk @aslakknutsen if this affects OSIO, can you create a bug on openshifio and link to this.
thats where we get visibility to our team

@GeorgeActon done: openshiftio/openshift.io#4124

kwk added a commit that referenced this issue Aug 7, 2018
This includes an extra-condition in the `ON` part of the table `JOINS` for areas, codebases and iterations to only join those tables filtered by their space ID. I'm not sure though if this really fixes the problem (see #2210 (comment)).

## TODO

As of yesterday's (07.08.2018) discussion with @aslakknutsen we did experiments and found that in order to keep the rows in the search small, we have to establish a condition on the final SQL `WHERE` clause that limits the selection to work items from a particular space. At the moment, the current `/api/search` endpoint is so generic that it doesn't require a limitation by space on the root of the `WHERE` clause. That's why @aslakknutsen and I agreed to create a search endpoint under `/api/spaces/<SPACE-UUID>/search` in order to automatically add the space ID to the query condition. This will be implemented in another PR and is tracked in openshiftio/openshift.io#4124

See #2210.
kwk added a commit to openshiftio/saas-openshiftio that referenced this issue Aug 7, 2018
commit fabric8-services/fabric8-wit@2661cf8
Author: Konrad Kleine <[email protected]>
Date:   Tue Aug 7 15:40:55 2018 +0200

Provide join lock down  (fabric8-services/fabric8-wit#2211)
    
This includes an extra-condition in the `ON` part of the table `JOINS` for areas, codebases and iterations to only join those tables filtered by their space ID. I'm not sure though if this really fixes the problem (see fabric8-services/fabric8-wit#2210 (comment)).
    
## TODO
    
As of yesterday's (07.08.2018) discussion with @aslakknutsen we did experiments and found that in order to keep the rows in the search small, we have to establish a condition on the final SQL `WHERE` clause that limits the selection to work items from a particular space. At the moment, the current `/api/search` endpoint is so generic that it doesn't require a limitation by space on the root of the `WHERE` clause. That's why @aslakknutsen and I agreed to create a search endpoint under `/api/spaces/<SPACE-UUID>/search` in order to automatically add the space ID to the query condition. This will be implemented in another PR and is tracked in openshiftio/openshift.io#4124
    
See fabric8-services/fabric8-wit#2210.
aslakknutsen pushed a commit to openshiftio/saas-openshiftio that referenced this issue Aug 7, 2018
commit fabric8-services/fabric8-wit@2661cf8
Author: Konrad Kleine <[email protected]>
Date:   Tue Aug 7 15:40:55 2018 +0200

Provide join lock down  (fabric8-services/fabric8-wit#2211)
    
This includes an extra-condition in the `ON` part of the table `JOINS` for areas, codebases and iterations to only join those tables filtered by their space ID. I'm not sure though if this really fixes the problem (see fabric8-services/fabric8-wit#2210 (comment)).
    
## TODO
    
As of yesterday's (07.08.2018) discussion with @aslakknutsen we did experiments and found that in order to keep the rows in the search small, we have to establish a condition on the final SQL `WHERE` clause that limits the selection to work items from a particular space. At the moment, the current `/api/search` endpoint is so generic that it doesn't require a limitation by space on the root of the `WHERE` clause. That's why @aslakknutsen and I agreed to create a search endpoint under `/api/spaces/<SPACE-UUID>/search` in order to automatically add the space ID to the query condition. This will be implemented in another PR and is tracked in openshiftio/openshift.io#4124
    
See fabric8-services/fabric8-wit#2210.
@kwk kwk removed their assignment Nov 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants