【问题标题】:DynamoDB AutoScaling still throttlesDynamoDB AutoScaling 仍然受到限制
【发布时间】:2017-06-20 19:49:42
【问题描述】:

我有一个使用 DynamoDB 的应用程序,我注意到他们刚刚实现了非常棒的自动缩放。我喜欢这个概念,我的应用程序的时机非常完美。但是,我仍然遇到一些问题,我想知道我是否无法调整设置以删除。

我的应用程序在使用中出现了明显的峰值,所以我认为这是一个理想的使用方式,但是在启用自动缩放的情况下,我仍然会遇到一些限制。这是我过去 12 小时的阅读图表:

如您所见,当它达到峰值时,使用率设置为较低,因此它会限制一两分钟,直到更新启动,然后才能正常工作。没关系,我想这比不缩放要好,但我希望它根本不要节流......

有没有办法告诉 DynamoDB 永远不要限制,除非它超过 100(或 200 或我设置的任何上限)?只是如果它出现激增,则将吞吐量提高 15 分钟或其他任何时间,直到激增结束?

【问题讨论】:

  • 当然 - 将您的最小容量设置得更高。 :) 说到这,您使用什么值来实现目标阈值?当然,说真的,你不能使用实际上不存在的容量。此外,您似乎正在执行大量扫描,这在容量消耗方面相对昂贵。
  • 哈,我想这是真的,但重点是避免额外的费用:)。我被设置为最低 5、最高 200 和 70% 的利用率目标。我将利用率提高到 50% 以查看它的作用...我将查看我的代码并查看我可能会进行哪些过度扫描,谢谢您的提示...

标签: amazon-dynamodb throughput


【解决方案1】:

自动缩放使用 CloudWatch。您可以通过转到 CloudWatch 控制面板来查看这些警报,并在描述中查找包含您的表名称和“请勿编辑或删除”的警报。

我为什么要告诉你这个?

嗯,CloudWatch 有一些最小的周期粒度。目前是1分钟。这意味着在向其侦听器触发任何事件之前,它将至少等待 1 分钟。因此,从负载开始到容量增加至少需要一分钟。实际上它会更多,因为增加容量也需要时间。底线:如果您的峰值非常大,一些请求可能会受到限制,因为自动缩放尚未生效,bursting 可能会被耗尽。

简单但昂贵的解决方案是增加初始容量。

如果您提前知道即将到来的高峰(例如,您有一些工作定期运行,或者客户在特定时间达到高峰),您可以使用 API 以编程方式修改自动缩放。

【讨论】:

  • 嗯。 API 可能是理想的,因为我以前有一个脚本来更改特定计时器的吞吐量,我有可能只在相同的时间范围内更改自动缩放。但是这里的例子都是java,你知道它现在只是java还是你可以用PHP做到这一点?我在 PHP API 中没有看到任何自动缩放类...
  • 我很确定没有直接的 PHP 支持。您可以使用 AWS CLI。我不是很喜欢 PHP,但你能从 PHP 调用 CLI 吗?我在脚本中使用了这种方法。
  • 嗯,不确定。我也有一个网络主机,所以我不知道我是否可以在我的主机上安装 CLI……不过,谢谢你的想法,检查一下……
  • 如果您在 AWS 中运行您的主机(我敢打赌)并且如果您使用的是 Amazon Linux AMI [aws.amazon.com/amazon-linux-ami/],那么您已经预装了 AWS CLI。
  • 没有其他托管公司(InMotion 托管...)
猜你喜欢
  • 1970-01-01
  • 2021-03-28
  • 2012-11-25
  • 2021-08-14
  • 2020-11-27
  • 1970-01-01
  • 2012-11-28
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多