关于我 我的名字是马克·布鲁克。我喜欢构建能正常工作的东西，并做一些很酷的事情。我喜欢构建大型项目。我还涉足机械加工、焊接、烹饪和滑雪。我是在亚马逊云计算服务（AWS）工作的工程师，地点在西雅图，我专注于自主AI，尤其是自主AI的安全和政策。在此之前，我曾在EC2、EBS、数据库、无服务器和无服务器数据库方面工作。所有观点均为我个人观点。 链接 我的出版物和视频 @marcbrooker在Mastodon @MarcJBrooker在推特 这个博客是由AI写的吗？ 漂亮的图片帮助我们学习，也许？ 我热爱使用LLM的其中一项用途是帮助我更好地理解系统。在我写的Strands Decider帖子中，我提到我经常询问自己问题，以检查我是否理解这一点。我现在喜欢的另一种技术，并且看到我周围的人也在使用，是构建动画。动画可以帮助我们建立对系统如何以及为何工作，或者如何以及为何失败的直觉。这是一个例子：你知道如果集群中的任何一个成员的存储层关于fsync()虚假信息，Raft集群可能会丢失写入吗？ 你的浏览器不支持视频标签。 当我构建Stability Sim时，我希望帮助工程师更好地理解亚稳态故障。这在抽象层面上效果不错（例如，重试和队列使得亚稳态非常容易触发），但我仍然听到对这些行为在真实系统中发生的怀疑。毕竟，那些真实系统是经过生产验证的，如果这些行为确实存在，我们难道不会早已发现它们吗？ 让我们从Postgres开始。 你的浏览器不支持视频标签。 在这个示例中，从真实的Postgres 16运行的真实MicroVM捕获的跟踪中可以看到。在负载激增之前，数据库能够轻松处理其每秒20个查询的负载，这要归功于整个工作集在页面缓存中。但在负载激增之后，由于查询占用了很多内存（每个查询需要12MB），它们运行得更慢，因为它们是从磁盘而不是页面缓存提供的。我喜欢这个例子，因为它表明即使是简单的、非分布式系统也存在这些行为。 那etcd呢？ 你的浏览器不支持视频标签。 同样，我们的负载激增触发了亚稳态。这次是写入。在这种情况下，过载的对等体看起来不可用，这触发了一阵应用层重发。我喜欢这个例子，因为etcd是广泛使用的优质软件。运营经验似乎并没有有效地消除这些类型的问题。当我写《垃圾收集与亚稳态》时，一位知名的系统学者告诉我这是幻想。我在野外看到过这种情况，以至于我无法分享，我也可以理解人们不相信这种事情会发生，因为博客中有一些空洞的说辞。所以有一个真实的例子再次挑出etcd，真是不错。 你的浏览器不支持视频标签。 在开始时，我们的读取速度为每秒500次，然后负载激增到每秒1000次读取。读取激增增加了垃圾收集中花费的时间，增加了平均存活时间，并使得可用于读取工作负载的CPU减少。这是一个自我强化的循环，系统在没有干预的情况下无法恢复。我相信在没有垃圾收集的运行时中同样的事情可能会发生，因为分配器中的工作增加，但我还不能重现这个情况。 这里的所有动画都是使用Kiro和KiroCrew生成的，主要使用Opus 5.5。实际结果来自一个真实的测试环境，该环境捕捉了支持动画的跟踪。