Cost anomaly mySQL 76% Memory, "Paid IO LRS IO Rate Operations" at $20/m for inactive (dev) wordpress website

Question

For a Wordpress website in development almost inactive, the cost of the Azure Database MySQL is at IOPS CA$20/month, and it says the CPU at 7% but Memory constantly at 74% , and the bulk of the cost comes from "Paid IO LRS IO Rate Operations"... I don't see where the 5k or 5M whatever operations would come from on a development website...

In summary, for a production wordpress website with 1000 users I would therefore literally have to pay $20000 per month for the database? This is ridiculous, where is the anomaly problem here?

Answer 1

@Christopher Mary At this time, you can define the max IOPs limit only with provisioned IOPs but not with Auto scale IOPs.

Auto-scaling IOPs (also referred to as Paid IO LRS IO Rate Operations) does not violate or generate IO operation on its own but it is driven by the workload, when you switch to provisioned IOPs and define the max limit, you are optimizing for cost by introducing throttling(slowness) on your workload for budget-friendly setup.

With auto-scaling IOPs, you are optimizing for throughput and response time (query performance). As you had shared in your previous charts below, your workload was driving 3M-4M queries per seconds, with frequent IO requests going up to 1M IOs daily in last 30 days due to limited memory (1GB) on the compute node.

When you switched to provisioned IOPs and defined the max IOPs, the additional IO requests from your workload will now have to wait as you have gated to allow only 400 ios per second.

With the new setting in place, your throughput (queries per second) which you can drive might have gone down compared to your previous configuration and your response time would have increased, which is an informed decision you took to optimize for cost.

Please let me know if I am missing something which you are trying to highlight but as according to us, the feature is working as expected. If you believe the system is generating artificial IOPs, please stop the workload and monitor IO count which should drop to <50 and it should tell us if the workload is driving IOPs or if the system is generating by itself.

One feedback and learning we take from your experience is to provide a Max IOPs limit setting in Auto-scaling IOPs so you can enjoy the right balance between performance and cost.

I hope this information helps

Regards

Geetha

Answer 2

Hello,

I'm here because I have similar issues and questions as TS. I'm running a MySQL Flexible server on a Standard_B1ms server with 40GiB storage. It has 420 - 640 IOPS, which I had set to scaling.

This server has a price of $20.01/month. If I set IOPS to max it would cost $33.21. In our case however we had to pay around $65,-. Nowhere in the metrics could I find a reason why we had to pay this much extra, I can only see it goes to "Paid IO LRS IO Rate Operations". This server started in december 2023.

Then I found this threat. I switched off auto IOPS, I manually set the IOPS to 500, in stead of 420, and now the server price went from €2.10 per day to €0.75 per day. There is NO notable reduction in speed.

When I look at the metrics of the day I switched off auto IOPS I see something weird:

Storage IO percentage was max only 10% with auto IOPS turned on. Now it's around 60% with manual IOPS. So something is off here, and Microsoft really needs to look at this. We had to pay 2 to 3 times the price off what seemed to be expected.

Finally:

TS shows a graph with up to 3-4M queries/day. MSFT reads it as 3-4M queries/second.