每隔 5 天左右（包括刚才），我的 web 应用程序就会出现一连串超时错误。
如果我查看我的 SQL 实例在 CloudWatch 中执行的操作，它会报告以下内容：
可用空间：http://cl.ly/NBRM
数据库连接：http://cl.ly/NBLH
写入吞吐量：http://cl.ly/NBFs
读取 IOPS：http://cl.ly/NBp3
写入 IOPS：http://cl.ly/NAre
到底发生了什么？我不认为这与交通有关。我如何知道发生了什么？
**更新：**增量备份每 5 分钟进行一次，每日备份在凌晨 4 点进行（即不是在此时进行）
谢谢
答案1
似乎出现了活动高峰，磁盘队列不太好，但是这完全取决于您使用的存储，如果这是虚拟化的或来自某种 SAN（由于您可能正在使用托管基础设施），队列深度可能毫无意义。即便如此，您确实可以做一些事情，即使这很简单，例如运行 sp_WhoIsAtive 来查看哪些会话处于活动/暂停状态以及它们正在做什么/它们在等待什么。没有足够的信息来做出任何预测，而且 I/O 的峰值不应该导致半个像样的 I/O 子系统出现任何问题。
答案2
有时，云资源会因为其他原因而超时。亚马逊使用 ... 监管器 ...（没有更好的术语）来帮助执行其使用政策。当超出这些限制时，他们很少会告诉你任何事，除非你碰巧支付了高级支持费用。他们只是限制你，让你自己决定发生了什么。
！！！雷神！！！
您在 MSSQL 数据库中使用了多大的 RDS 实例？较小的实例，尤其是那些通常属于免费套餐的实例（即使您为此付费），当您不可避免地超出其资源利用率限制时，就会限制您的使用。尝试让 CPU 100% 的时间都处于忙碌状态，并用 I/O 加载它……它会让您崩溃！同样，它们对平台还有其他几个限制。您可以在特定大小的区域中启动多少个实例，您可以配置多少存储空间……等等。您可以提交支持单，并且通常可以提高这些限制，甚至无需支付支持费用。但是，付费支持请求的处理速度要快得多。
还有一些 AWS 区域因问题而臭名昭著。尝试移动到区域内的其他服务可用区。这有助于停止实例并重新启动它们（与重新启动完全不同！）。正确的停止和启动会将您的实例重新安置在较新的硬件或刚刚进行维护活动的硬件上。因此，当底层硬件自行崩溃并且您的实例在没有警告的情况下重新启动时，奇怪的问题会更少。
这些问题并非 AWS 独有。所有主要的公共云最终都会出现问题。有些会承认这一点。其他人只是说，查看状态页面以获取更多信息，但很少真正了解问题根源背后的细节。尤其是当问题范围仅限于少数客户时。
您正在完全不同的人的数据中心租用其他人的计算机！您期望什么？！
那些非常擅长利用公共云资源的人知道它非常不稳定，并为此做好了计划。了解 Netflix 如何使用 AWS，甚至让软件开始随意终止某些东西，以确保这不会影响他们向客户提供视频的能力。这其实是一件非常棒的事情！