You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On 2018-08-27, I had a table that was running at 60 RCU due to short spikes in read traffic (~1min, 100+ RCU). Once the MinimumMinutesBeforeDecreaseAfterIncrease had elapsed since the last increase, the RCU was dropped from 60 RCU to 2 RCU. Manually checking on the consumed capacity for the 20min evaluation window, 2 RCU is a little low, even when ignoring the spike to 117 RCU.
This test replicates the decision that occured at the time of the drop:
The drop to 2 RCU was caused by the following: The polynomial regression returned a forecast of -4.233514 RCU (due to the single spike of 117 consumed RCUs in the 20min window the forecast is based on). This was then limited to 1 RCU. The forecast was then doubled to 2 RCU by the ForecastPaddingRule. Which then got applied to the table.
Since there was read traffic that needed more than 2 RCU, reads to the table started to be throttled and the DCM upped the provisioned RCU within a few minutes. In the end the DCM corrected this "mistake", however it would be good to not have drops like this in the first place.
The text was updated successfully, but these errors were encountered:
On 2018-08-27, I had a table that was running at 60 RCU due to short spikes in read traffic (~1min, 100+ RCU). Once the
MinimumMinutesBeforeDecreaseAfterIncrease
had elapsed since the last increase, the RCU was dropped from 60 RCU to 2 RCU. Manually checking on the consumed capacity for the 20min evaluation window, 2 RCU is a little low, even when ignoring the spike to 117 RCU.This test replicates the decision that occured at the time of the drop:
The drop to 2 RCU was caused by the following: The polynomial regression returned a forecast of -4.233514 RCU (due to the single spike of 117 consumed RCUs in the 20min window the forecast is based on). This was then limited to 1 RCU. The forecast was then doubled to 2 RCU by the ForecastPaddingRule. Which then got applied to the table.
Since there was read traffic that needed more than 2 RCU, reads to the table started to be throttled and the DCM upped the provisioned RCU within a few minutes. In the end the DCM corrected this "mistake", however it would be good to not have drops like this in the first place.
The text was updated successfully, but these errors were encountered: