This repository has been archived by the owner on Jul 23, 2020. It is now read-only.
SQL causing 100% CPU usage on stage (not seen on prod yet, stage has more data) #4124
Open
1 of 4 tasks
Labels
Comments
kwk
added a commit
to fabric8-services/fabric8-wit
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.
|
@mvulavak why is this assigned to the platform team when really it is a planner issue in the search query engine? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
originally reported here fabric8-services/fabric8-wit#2210 by @aslakknutsen
The text was updated successfully, but these errors were encountered: