Hello Muhammad,
As to your question about how to observe and measure the ‘I/O write or read Operations’, the read operations metric is the number of read operations served from disk that do not come from cache per second and the write operations metric records the number of write operations to disk. As Alexis has pointed out, a larger machine type comes along with a larger cache, making it possible to serve more requests directly from cache instead of from disk, hence reducing the latency as well as the read operations to disk.
From the screenshots you shared, you could monitor the amount of the operations within a specified time frame. This might help to locate any peak value or pattern abnormalities in order to diagnose related issues. One point to pay extra attention is the sampling interval (in your case ‘3 hr interval’) because different time intervals might flatten out some extreme values, possibly hiding important data.
Hope it helps!
Hello Muhammad,
Thanks for your reply.
For spikes of I/O Read Write, it would be helpful to review the operations / queries at the same time period, which might provide some information on what is driving the spike and if it is causing any increase of resource usage (CPU or Memory).
As Alexis has partly explained, Cloud SQL instances are tuned to allow MySQL to use as much of the available memory as possible to store indexes and data. Some of the allocated memory is never released because MySQL re-uses it while it is running. Hence, in general, the overall memory usage may not possibly be an issue if it is stable.
MySQL also exposes server status variables [1] that could be reviewed for any performance issues. And you are also welcome to open tickets to GCP tech support to look into your project and have the issue further investigated.
Hope it helps.