NumaRing: Topology-Aware Routing for NUMA-Local MPMC Queues, and What Broke When We Optimized It

现代计算机的构建方式就像繁忙的城市，拥有多个区域，每个区域都设有自己的处理能力和内存。当一个程序需要执行工作时，它会向特定的区域发送请求。如果它所需的数据已经存在于该区域的本地内存中，任务就会瞬间完成。但如果请求必须前往另一个区域去获取信息，旅程就会变得显著漫长。这种由区域间物理距离造成的延迟，是这些机器构建方式的一个基本限制。几十年来，软件工程师一直试图编写能够让数据与其使用者保持在同一区域的程序，希望能避免这些缓慢的跨区旅行。挑战在于，当许多工作者同时尝试访问一份共享的任务列表时，他们制造的交通拥堵可能与距离本身一样具有破坏性。

一位研究人员致力于构建一种更好的管理这些共享列表的方法，特别是针对具有两个不同区域的计算机。他创建了一个名为 NumaRing 的系统，旨在尽可能让工作者及其数据留在各自的区域内。这个想法很简单：如果一个工作者在第一个区域，它就应该只查看第一个区域的列表。如果该列表变满或变空，系统就会一次性将一批任务移动到另一个区域，而不是一个接一个地移动。这种方法承诺在保持快速、本地化交通流的同时，最大限度地减少缓慢的长途旅行。然而，当研究人员对他的系统进行测试时，他发现他的良苦用心隐藏着陷阱。通过以极高的精度测量系统，而非仅仅靠猜测其运作方式，他发现有两个特定的错误比硬件本身更严重地拖慢了速度，并且一条用于修复计算机减速问题的常见建议实际上让情况变得更糟了。

研究人员首先在一部拥有两个区域、每个区域包含十六个虚拟处理器的云端计算机上构建了他的系统。他用源源不断的任务填充了系统，观察一个任务从队列开始到结束所需的时间。在开始阶段，系统出奇地慢。研究人员意识到，每当一个工作者尝试添加或移除任务时，软件都会询问一个问题：“我现在在哪个区域？”这个问题看似无害，但计算答案却需要很长时间。软件每次都在从头开始重新计算位置，尽管工作者的位置很少改变。这种重复计算就像一名司机在每一个路口都要停下来询问方向，尽管他清楚自己要去哪里。这个问题的成本如此之高，以至于它消耗的精力超过了实际移动数据的十一倍以上。

一旦研究人员通过记住位置并仅在必要时才进行检查来修复这个问题，系统速度便大幅提升。每秒处理的任务数量跃升了六到七倍。但故事并未就此结束。当他们向机器中增加更多工作者时，系统撞到了新的墙。工作者们仍然等待时间过长，尤其是在系统承受重压时。通过深入挖掘，他们发现了第二个问题，即工作者之间共享任务的方式。当一个工作者需要从另一个区域抓取一批任务时，每一个工作者都在争夺同一个微小的计数器，以决定谁是下一个执行者。这在门口制造了一个巨大的交通拥堵。通过给每个工作者分配一个私有的计数器，研究人员消除了这个瓶颈。这一改动更为显著，将工作者在队列中间的等待时间缩短了两百多倍。

在落实了这两个主要的修复措施后，研究人员预期他的系统会成为一个冠军。他已经消除了阻碍系统的软件错误。然而，当他用三十二个工作者将机器推向绝对极限时，系统仍然无法达到他最初期望的速度。研究人员随后测试了一种用于解决计算机减速的标准技术，称为“退避”（backoff）。退避背后的理念是，如果一个工作者未能抓取到任务，它应该稍作等待后再尝试，希望此时队列已经疏通。在许多情况下，这种暂停是有帮助的。但在这种特定的、高压的环境下，这种暂停却是一个错误。研究人员测量到，等待实际上使他们的总速度损失了百分之十五到三十。最快的路径是立即继续尝试，因为硬件本身已经足够高效地处理了冲突，等待只会浪费时间。

最终呈现出的景象是成功与硬性限制并存。研究人员成功构建了一个能保持数据本地化并修复了两个导致大规模延迟的主要软件漏洞的系统。他证明了在某些高速场景下，一种常见的优化策略可能会产生负面影响。尽管取得了这些胜利，系统仍然无法像原定设计目标那样快速处理任务。研究人员得出结论，剩余的减速并非可以修复的软件错误，而是机器本身的物理限制。两个区域之间的距离以及连接它们的带宽创造了一个天花板，任何精巧的代码设计都无法突破这个限制。他诚实地报告了他的发现，清晰地展示了系统在何处成功、在何处失败，以及为什么硬件本身才是最终的裁判。他的工作提醒我们，在高速计算的世界里，理解物理机器与编写代码同样重要。