Mysql high load

I suggest using the Query Monitor plugin to help you determine what sort of query is causing such a high load by how long it takes to complete. Using the plugin will itself increase server load, but once you find the problem queries you can deactivate the plugin.

The nature of the problem queries will indicate the best solution. Sometimes the query can be optimized, or maybe your DB needs to be optimized. Sometimes a good caching scheme will be indicated.

@bcworkz I tried to see but I didn’t get what to do. There are a lot of sleep process. and some were wp_posts, wp_postmeta etc and I checked those were not indexed in sql then I have added in index but still there is high load. Can you please give me any command so that I can run and provide you details to see? Or do you have any premium plan in which you can help me to fix high load? I am really very tired of these high load from a week. I am totally helpless.

I don’t think there’s a way to get Query Monitor to do what you want to provide details. Let’s try this:
Open the Query monitor panel and go to the Database Queries screen. Sort the Time column so the longest queries are at the top. Get a screen grab image of what you see and post it to any public image sharing site, then provide the resulting link here.

In sql process I sort by time and couldn’t find more than 6. some are 1, some are 3. max I saw 6. but in php I noticed this:

29-Aug-2024 03:38:16] WARNING: [pool www] child 568643, script ‘/www/wwwroot/domain.com/wp-admin/admin-ajax.php’ (request: “POST /wp-admin/admin-ajax.php?action=as_async_request_queue_runner&nonce=9046a8f559”) executing too slow (31.062470 sec), logging
[29-Aug-2024 03:38:16] NOTICE: child 568643 stopped for tracing
[29-Aug-2024 03:38:16] NOTICE: about to trace 568643
[29-Aug-2024 03:38:16] NOTICE: finished trace of 568643

The queue_runner process belongs to WooCommerce. Nothing wrong with that, but what’s odd is the fact something is invoking a tracing process. It might be due to Query Monitor, I’m not sure. In any case, while tracing may degrade overall performance, it would not affect the SQL load. The fact that the queue_runner process timed out only reinforces the fact that something is taking too long to execute. We already know that ??

You have SQL queries taking 3-6 seconds?? That is a very long time for a query to run! They usually run in the millisecond range. For example, all 30 queries on my test site took a total of 0.100 seconds to complete. My test site DB is relatively small, so it’s not realistic comparison. The point is that 6 seconds is orders of magnitude longer than expected for a single query.

Please post the SQL of a couple of the queries that took such a relatively long time.