Home › Forums › WoodMart support forum › CPU usage increate due to Price filter
CPU usage increate due to Price filter
- This topic has 1 reply, 2 voices, and was last updated 2 weeks, 1 day ago by
Artem Temos.
-
AuthorPosts
-
August 25, 2025 at 4:04 pm #681952
dev-9059ParticipantHi support
This below code is given by godaddy team… here is some sql query make CPU usage 100% which cause my site getting down can you please fix this from your end with theme code.
Site URL: https://www.staging.watertreatmentsupply.com/shop/
Check godaddy support code:
We have continued to be alerted to high CPU usage stemming from MySQL on the WTS server. This is ultimately due to the following query running on the dom26790_fhra1 database which is very inefficient: SELECT min( min_price ) as min_price, MAX( max_price ) as max_price FROM zh9q_wc_product_meta_lookup WHERE product_id IN ( SELECT ID FROM zh9q_posts LEFT JOIN zh9q_term_relationships ON (zh9q_posts.ID = zh9q_term_relationships.object_id) LEFT JOIN zh9q_term_relationships AS tt1 ON (zh9q_posts.ID = tt1.object_id) LEFT JOIN zh9q_term_relationships AS tt2 ON (zh9q_posts.ID = tt2.object_id) LEFT JOIN zh9q_term_relationships AS tt3 ON (zh9q_posts.ID = tt3.object_id) LEFT JOIN zh9q_term_relationships AS tt4 ON (zh9q_posts.ID = tt4.object_id) LEFT JOIN zh9q_term_relationships AS tt5 ON (zh9q_posts.ID = tt5.object_id) LEFT JOIN zh9q_term_relationships AS tt6 ON (zh9q_posts.ID = tt6.object_id) LEFT JOIN zh9q_term_relationships AS tt7 ON (zh9q_posts.ID = tt7.object_id) LEFT JOIN zh9q_term_relationships AS tt8 ON (zh9q_posts.ID = tt8.object_id) LEFT JOIN zh9q_term_relationships AS tt9 ON (zh9q_posts.ID = tt9.object_id) LEFT JOIN zh9q_term_relationships AS tt10 ON (zh9q_posts.ID = tt10.object_id) LEFT JOIN zh9q_term_relationships AS tt11 ON (zh9q_posts.ID = tt11.object_id) LEFT JOIN zh9q_term_relationships AS tt12 ON (zh9q_posts.ID = tt12.object_id) LEFT JOIN zh9q_term_relationships AS tt13 ON (zh9q_posts.ID = tt13.object_id) LEFT JOIN zh9q_term_relationships AS tt14 ON (zh9q_posts.ID = tt14.object_id) WHERE zh9q_posts.post_type IN (‘product’) AND zh9q_posts.post_status = ‘publish’ AND ( ( zh9q_posts.ID NOT IN ( SELECT object_id FROM zh9q_term_relationships WHERE term_taxonomy_id IN (7) ) AND zh9q_term_relationships.term_taxonomy_id IN (411,436,437,439,440,441,455,759,789) ) AND ( ( tt1.term_taxonomy_id IN (405,406,407,408,410,411,412,413,414,415,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,433,434,435,436,437,439,440,441,483,493,495,777,780) AND ( tt2.term_taxonomy_id IN (436,437,439,440,441) ) ) OR ( tt3.term_taxonomy_id IN (454,455,456,457,757,758,759) AND ( tt4.term_taxonomy_id IN (455,759) ) ) OR ( tt5.term_taxonomy_id IN (462,785,786,787,788,789) AND ( tt6.term_taxonomy_id IN (789) ) ) ) AND ( ( zh9q_posts.ID NOT IN ( SELECT object_id FROM zh9q_term_relationships WHERE term_taxonomy_id IN (7) ) AND tt7.term_taxonomy_id IN (411,436,437,439,440,441,455,759,789) ) AND ( ( tt8.term_taxonomy_id IN (405,406,407,408,410,411,412,413,414,415,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,433,434,435,436,437,439,440,441,483,493,495,777,780) AND ( tt9.term_taxonomy_id IN (436,437,439,440,441) ) ) OR ( tt10.term_taxonomy_id IN (454,455,456,457,757,758,759) AND ( tt11.term_taxonomy_id IN (455,759) ) ) OR ( tt12.term_taxonomy_id IN (462,785,786,787,788,789) AND ( tt13.term_taxonomy_id IN (789) ) ) ) AND tt14.term_taxonomy_id IN (713) ) ) ) Using MySQL’s EXPLAIN FORMAT=JSON statement on the query shows a very high ‘query cost’ due to the subquery being generated as a result of the the nested JOINs: “query_cost”: “40176098982.46” . It also highlights how much data is being joined in succession across these subqueries. Below are the estimated values leading up the final join: “rows_produced_per_join”: 20686423, “data_read_per_join”: “473M” “rows_produced_per_join”: 197792185, “data_read_per_join”: “4G” “rows_produced_per_join”: 1891179904, “data_read_per_join”: “42G” “rows_produced_per_join”: 18082420304, “data_read_per_join”: “404G” “rows_produced_per_join”: 172894130155, “data_read_per_join”: “3T” You and/or your developer, if applicable, will want to review any plugins, themes, or custom code responsible for these queries so that they can be optimized.
August 26, 2025 at 10:05 am #682048
Artem TemosKeymasterHello,
The price filter is a part of the WooCommerce functionality and not related to our theme. You need to contact WooCommerce developers for help on this matter.
Kind Regards
-
AuthorPosts
- You must be logged in to create new topics. Login / Register