scala - Akka IO 应用占用 100% CPU

Question

我正在尝试分析一个 CPU 使用率一直处于或接近 100% 的 Akka 应用程序。我使用 visualvm 采集了一个 CPU 样本。该示例表明有 2 个线程占 CPU 使用率的 98.9%。 79% 的 cpu 时间花在了名为 sun.misc.Unsafe 的方法上。 Other answers on SO说它只是意味着一个线程正在等待但是在 native 实现层(在 jvm 之外)。

在与我类似的问题中，人们一直在 told to look elsewhere没有给出具体细节。我应该在哪里寻找导致 cpu 峰值的原因？

该应用程序是一个服务器，主要使用 Akka IO 来监听 TCP 套接字连接。

Answer 1

如果没有看到任何源代码，甚至不知道您在谈论什么 IO channel (套接字、文件等)，这里的任何人都无法提供给您的见解。

不过我确实有一些相当笼统的建议。

首先，您应该在您的应用程序中使用响应式(Reactive)技术和响应式(Reactive) IO。出现此问题的原因可能是您在紧密循环中轮询某些资源的状态，或者在以下情况下使用阻塞调用你应该使用 react 性的。这往往是一种反模式和性能消耗，因为您可以将 CPU 周期用于“积极等待”之外的任何事情。我建议仔细检查:

• 资源轮询
• 拦截电话
  • 系统调用
  • 磁盘刷新
  • 正在等待 Future什么时候适合 map相反

其次，您不应该在您的应用程序中使用互斥体或其他线程同步。如果是这样，那么您可能会遇到活锁。与死锁不同，活锁表现为 100% CPU 使用率等症状，因为线程不断锁定和解锁并发原语以试图“捕获所有”。 Wikipedia对活锁的外观有很好的技术描述。有了 Akka，您就不需要使用 Mutexes 或任何线程同步原语。如果是，那么您可能需要重新设计您的应用程序。

第三，您应该限制 IO(以及重新连接尝试等错误处理)。出现此问题的原因可能是您的系统缺乏有效的限制。对于数据通道，我们通常不会限制其带宽。然而，当该 channel 达到 100% 饱和并开始从系统的其他部分窃取资源时，这可能会成为一个问题。例如，如果您在没有合理限制的情况下移动大文件，就会发生这种情况。

或者，您还需要在遇到任何错误时限制连接重试，而不是立即重试。如果失去连接，许多系统将尝试重新连接到服务器。虽然通常是可取的，但如果您使用天真的重新连接策略，这可能会导致有问题的行为。例如，想象一个这样写的网络客户端:

class MyClient extends Client {
... other code...
  def onDisconnect() = {
    reconnect()
  }
}

每次客户端因任何原因断开连接时，它都会尝试重新连接。您可以看到，如果 Wifi 中断或网络电缆被拔掉，这将如何导致错误处理代码和客户端之间的紧密循环。

第四，您的应用程序应该有明确定义的数据源和接收器。您的问题可能是由“数据循环”引起的，即一组 Akka actor 只是将消息发送到下一个链中的参与者，最后一个参与者将消息发送回链中的第一个参与者。确保您有清晰明确的方式让消息进入和退出您的系统。

第五，为您的应用程序使用适当的分析和检测。使用 Kamon 检测您的应用程序或 Coda Hale 的指标库。

找到合适的分析器将更加困难，因为我们作为一个社区还有很长的路要走才能为响应式(Reactive)应用程序开发成熟的工具。我个人找到了visualvm有用，但对于检测受 CPU 限制的代码路径并不总是非常有用。问题是采样分析器只能在 JVM 到达安全点时收集数据。这有可能使某些代码路径产生偏差。解决方法是使用支持 AsyncGetStackTrace 的分析器.

祝你好运!如果可以，请添加更多上下文。