What could be the root cause of the issue with the marketing campaign?
It exhausted the I/O credit balance due to provisioning low disk storage during the setup phase.
It caused the data in the tables to change frequently, requiring indexes to be rebuilt to optimize queries.
It exhausted the maximum number of allowed connections to the database instance.
It exhausted the network bandwidth available to the RDS for MySQL DB instance.
Explanations:
The I/O performance of an Amazon RDS for MySQL instance can be limited by the provisioned storage type. General Purpose SSD storage has a specific I/O credit model where I/O operations per second (IOPS) are based on the size of the provisioned storage. With only 100 GB of storage, the maximum IOPS available may be insufficient to handle increased demand during the marketing campaign, leading to exhausted I/O credits and increased latency.
Frequent changes in data would lead to performance issues, but these typically manifest as increased CPU utilization or locking issues rather than excessive response times. Index rebuilding can help performance but would not directly cause timeouts if there are sufficient resources available. Since the CPU and memory are at 40%-50%, this is not a primary concern in this scenario.
Although exhausting the maximum number of allowed connections can lead to performance degradation, the provided application server logs show no connectivity issues. Since users reported timeouts rather than connection errors, this option is less likely to be the root cause.
While network bandwidth can impact performance, the metrics show that CPU and memory utilization are not maxed out, suggesting that the issue is not primarily related to network bandwidth. Additionally, if there were bandwidth issues, it would likely be reflected in other metrics, such as latency in network packets rather than purely database response times.
From my perspective, the answer is:
It exhausted the I/O credit balance due to provisioning low disk storage during the setup phase.