Akka IO 应用消耗 100% cpu
Akka IO app consumes 100% cpu
我正在尝试分析一个经常处于或接近 100% CPU 使用率的 Akka 应用程序。我使用 visualvm 采集了 CPU 个样本。该示例表明有 2 个线程占 CPU 使用率的 98.9%。 79% 的 cpu 时间花在了名为 sun.misc.Unsafe 的方法上。 Other answers on SO 说它只是意味着一个线程正在等待但是在本机实现层（在 jvm 之外）。
在与我类似的问题中，人们 told to look elsewhere 没有得到具体细节。我应该在哪里寻找导致 cpu 峰值的原因？
该应用程序是一个服务器，主要使用 Akka IO 来侦听 TCP 套接字连接。
在没有看到任何源代码，甚至不知道你在谈论什么 IO 通道（套接字、文件等）的情况下，这里的任何人都无法提供给你的见解。
不过我确实有一些比较笼统的建议。
首先，您应该在您的应用程序中使用反应式技术和反应式 IO。出现此问题的原因可能是您正在紧密循环中轮询某些资源的状态，或者当您应该使用反应式调用时使用阻塞调用。这往往是一种反模式和性能消耗，因为您可以花费 CPU 个周期除了 "actively waiting" 之外什么都不做。我建议仔细检查：
- 资源轮询
- 阻塞调用
- 系统调用
- 磁盘刷新
- 等待
Future 合适的时候 map 改为
其次，您不应该在您的应用程序中使用互斥锁或其他线程同步。如果是这样，那么您可能遇到了活锁。与死锁不同，活锁表现为 100% CPU 使用率等症状，因为线程不断锁定和解锁并发原语以尝试 "catch them all"。 Wikipedia 对活锁的外观有很好的技术描述。有了 Akka，您就不需要使用 Mutexes 或任何线程同步原语。如果是，那么您可能需要重新设计您的应用程序。
第三，您应该限制 IO（以及重新连接尝试等错误处理）。出现此问题的原因可能是您的系统缺乏有效的限制。对于数据通道，我们通常不会限制其带宽。然而，当该通道达到 100% 饱和并开始从系统的其他部分窃取资源时，这可能会成为一个问题。例如，如果您在没有合理限制的情况下移动大文件，就会发生这种情况。
或者，您还需要在遇到任何错误时限制连接重试，而不是立即重试。如果失去连接，许多系统将尝试重新连接到服务器。虽然通常是可取的，但如果您使用天真的重新连接策略，这可能会导致有问题的行为。例如，假设一个这样写的网络客户端：
class MyClient extends Client {
... other code...
def onDisconnect() = {
reconnect()
}
}
每次客户端因任何原因断开连接时，它都会尝试重新连接。您可以看到如果 Wifi 中断或网络电缆被拔掉，这将如何导致错误处理代码和客户端之间的紧密循环。
第四，您的应用程序应该有明确定义的数据源和接收器。您的问题可能是由 "data loop" 引起的，这是一组 Akka actor只是将消息发送给链中的下一个参与者，最后一个参与者将消息发送回链中的第一个参与者。确保您有清晰明确的方式让消息进入和退出您的系统。
第五，为您的应用程序使用适当的分析和检测。使用 Kamon 或 Coda Hale 的指标库检测您的应用程序。
找到合适的分析器将更加困难，因为我们作为一个社区还有很长的路要走才能为响应式应用程序开发成熟的工具。我个人发现 visualvm 很有用，但对于检测 CPU 绑定的代码路径并不总是非常有用。问题是采样分析器只能在 JVM 到达安全点时收集数据。这有可能使某些代码路径产生偏差。解决方法是使用支持 AsyncGetStackTrace.
的分析器
祝你好运！如果可以，请添加更多上下文。
我正在尝试分析一个经常处于或接近 100% CPU 使用率的 Akka 应用程序。我使用 visualvm 采集了 CPU 个样本。该示例表明有 2 个线程占 CPU 使用率的 98.9%。 79% 的 cpu 时间花在了名为 sun.misc.Unsafe 的方法上。 Other answers on SO 说它只是意味着一个线程正在等待但是在本机实现层（在 jvm 之外）。
在与我类似的问题中，人们 told to look elsewhere 没有得到具体细节。我应该在哪里寻找导致 cpu 峰值的原因？
该应用程序是一个服务器，主要使用 Akka IO 来侦听 TCP 套接字连接。
在没有看到任何源代码，甚至不知道你在谈论什么 IO 通道（套接字、文件等）的情况下，这里的任何人都无法提供给你的见解。
不过我确实有一些比较笼统的建议。
首先，您应该在您的应用程序中使用反应式技术和反应式 IO。出现此问题的原因可能是您正在紧密循环中轮询某些资源的状态，或者当您应该使用反应式调用时使用阻塞调用。这往往是一种反模式和性能消耗，因为您可以花费 CPU 个周期除了 "actively waiting" 之外什么都不做。我建议仔细检查：
- 资源轮询
- 阻塞调用
- 系统调用
- 磁盘刷新
- 等待
Future合适的时候map改为
其次，您不应该在您的应用程序中使用互斥锁或其他线程同步。如果是这样，那么您可能遇到了活锁。与死锁不同，活锁表现为 100% CPU 使用率等症状，因为线程不断锁定和解锁并发原语以尝试 "catch them all"。 Wikipedia 对活锁的外观有很好的技术描述。有了 Akka，您就不需要使用 Mutexes 或任何线程同步原语。如果是，那么您可能需要重新设计您的应用程序。
第三，您应该限制 IO（以及重新连接尝试等错误处理）。出现此问题的原因可能是您的系统缺乏有效的限制。对于数据通道，我们通常不会限制其带宽。然而，当该通道达到 100% 饱和并开始从系统的其他部分窃取资源时，这可能会成为一个问题。例如，如果您在没有合理限制的情况下移动大文件，就会发生这种情况。
或者，您还需要在遇到任何错误时限制连接重试，而不是立即重试。如果失去连接，许多系统将尝试重新连接到服务器。虽然通常是可取的，但如果您使用天真的重新连接策略，这可能会导致有问题的行为。例如，假设一个这样写的网络客户端：
class MyClient extends Client {
... other code...
def onDisconnect() = {
reconnect()
}
}
每次客户端因任何原因断开连接时，它都会尝试重新连接。您可以看到如果 Wifi 中断或网络电缆被拔掉，这将如何导致错误处理代码和客户端之间的紧密循环。
第四，您的应用程序应该有明确定义的数据源和接收器。您的问题可能是由 "data loop" 引起的，这是一组 Akka actor只是将消息发送给链中的下一个参与者，最后一个参与者将消息发送回链中的第一个参与者。确保您有清晰明确的方式让消息进入和退出您的系统。
第五，为您的应用程序使用适当的分析和检测。使用 Kamon 或 Coda Hale 的指标库检测您的应用程序。
找到合适的分析器将更加困难，因为我们作为一个社区还有很长的路要走才能为响应式应用程序开发成熟的工具。我个人发现 visualvm 很有用，但对于检测 CPU 绑定的代码路径并不总是非常有用。问题是采样分析器只能在 JVM 到达安全点时收集数据。这有可能使某些代码路径产生偏差。解决方法是使用支持 AsyncGetStackTrace.
祝你好运！如果可以，请添加更多上下文。