Brakes with MySQL. Could it be an SSD?

Question

MySQL

A week ago, brakes suddenly began to appear in the processing of requests. From time to time in slow log heaps of requests which normally fulfilled earlier fall. Analyzing one of these blunts, we saw that the brake starts during a mass update of a plate of 240 thousand lines. The query was optimized, but earlier it all went smoothly - without slowing down everything else, and slowdowns appear during the execution of other requests.
The server is quite powerful 24 cores and 128 Gb of memory. The database itself fits entirely in memory.
This is my first server with an SSD. I want to somehow make sure that the reason is not in the disks, or vice versa to confirm that it is the disks that are messing up. They looked at SMART, like nothing critical.
What do you advise?

Answer 1

Everything turned out to be completely different. The base did not slow down, the web servers slowed down.
The chain is approximately the following
. At rush hour, the response time on the web servers begins to increase. From 50-100ms to 1000-1500ms.
Each query hangs longer than usual and takes longer to connect to MySQL. As a result, all possible connections are selected and everything rests on max_mysql_connection
Web servers, although they work more slowly, still move slowly. At them the quantity of admissible processes is higher than a maximum of connections to a DB. As a result, we thought that the base was slowing down. There were still some number of slow requests, but they apparently always were, just until there were errors, we did not pay attention to them.
We solve the problem as follows
1. We slightly rebalanced the distribution of the load on the web servers so that the processor is used more evenly
2. Ordered another web server
3. We optimize "heavy" pages
PS Nevertheless, TRIM is still needed on the database servers and we will strongly ask the hosting engineers to enable it

Answer 2

do you disable indexes before the update?
if not, then during a mass update, you need to disable the indexes, and after the update is completed, turn it back on.

Answer 3

Does the system even know that this drive is an SSD? TRIM does it support? Without it, write performance may drop when free sectors run out, and a drive without TRIM will not know which are free.
Well, do not write many times in the same sectors, but do it in droves, for an SSD this is critical.

Answer 4

look at the utilization of the disk subsystem,
if there is a disk problem, then in top it will be seen that there is a lot of cpu wait
, you can still turn on iostat -x 3 and watch the load in real time while executing requests.