-
Task
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
1
-
False
-
-
False
-
Unset
-
No
-
-
The queries in the response-consumer appear to be driving the load on the database up.
The "select id, status, response_full from runs where org_id = ? and correlation_id = ?" runs for each response the response consumer processes. We use this query to retrieve the run id. Then we run an update that basically runs the same query. Create an index for these queries to speed things up and stop maxing out the cpu on the db.
explain analyze SELECT id, status, response_full FROM runs WHERE (org_id = '11789772') AND (correlation_id = '8322f43e-dfb1-11ee-813e-f4a475071fa2') ORDER BY "runs"."id" LIMIT 1;QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=367425.76..367425.77 rows=1 width=21) (actual time=3334.440..3334.694 rows=0 loops=1) -> Sort (cost=367425.76..367425.77 rows=1 width=21) (actual time=3334.439..3334.691 rows=0 loops=1) Sort Key: id Sort Method: quicksort Memory: 25kB -> Gather (cost=1000.00..367425.75 rows=1 width=21) (actual time=3334.416..3334.668 rows=0 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Seq Scan on runs (cost=0.00..366425.65 rows=1 width=21) (actual time=3325.882..3325.882 rows=0 loops=3) Filter: (((org_id)::text = '11789772'::text) AND (correlation_id = '8322f43e-dfb1-11ee-813e-f4a475071fa2'::uuid)) Rows Removed by Filter: 1201042 Planning Time: 0.384 ms Execution Time: 3334.736 ms (12 rows)
WARNING: The migrations run as a init pod within the response-consumer deployment. This can cause issues when creating an index. Before pushing out an index change, scale down the number of pods in the response-consumer deployment to 1. Then push out the index change. Then scale up the deployment back to 3.
- clones
-
-
- New
-