Akka执行元消息传递延迟

Question

我遇到了在多个请求下扩展应用程序的问题。

每个请求都向一个参与者发送一个ask，然后生成其他参与者。这是很好的，但是，在负载下（一次5个以上的询问），ask会花费大量的时间将消息传递给目标执行元。最初的设计是均匀地隔离请求，但这造成了一个瓶颈。示例：

在此图片中，ask是在查询计划解析程序之后发送的。但是，当执行元接收到此消息时有一个多秒的间隔。这只在负载（5+请求/秒）下才会出现。我最初以为这是一个饥饿的问题。

设计：每个计划执行器都是每个请求的一个独立实例。它每次都生成一个新的“请求接受器”执行元（它在接收到消息时记录“请求分数”）。

• 我为actorsystem提供了一个自定义全局执行器（大执行器）。我注意到，即使在这个巨大的延迟期间，线程的使用也没有超出核心线程池的大小
• 我确保子执行元中的所有ExecutionContext
使用了正确的ExecutionContext
• 确保参与者内部的所有阻塞调用都使用了将来的调用
• 我给父执行元（和所有子执行元）一个核心大小为50且最大大小为100的自定义调度器。即使在这些延迟期间，它也没有请求更多（停留在50个）
• 最后，我尝试为每个请求创建一个全新的Actorsystem（在planner-executor内部）。这也没有明显的影响！

我有点被这个难住了。从这些测试来看，它看起来不像是一个线程饥饿问题。回到起点，我不知道为什么消息需要越来越长的时间来传递我发出的并发请求。到达此点之前的Zipkin跟踪不会随着更多的请求而降级，直到它到达这里的ask。在此之前，服务器能够处理多个步骤，例如veify请求，与db对话，然后最后进入规划器-执行器。所以我怀疑应用程序本身的cpu时间不够用。

Answer 1

我们和Akka也有类似的问题。在peek加载时，我们观察到ask模式将消息传递给目标参与者的延迟很大。

这些问题大多与堆内存消耗有关，而不是因为调度器的使用。

最后，我们通过调整下面的一些配置和更改来解决这些问题。

1）确保停止不再需要的实体/执行元。如果它是一个持久执行元，那么您总是可以在需要时将它带回来。参考:https://doc.akka.io/docs/akka/current/cluster-sharding.html#passivation

3）最小化日志条目（将其设置为info级别）。

4）调整日志以频繁地将消息发布到日志系统。相应地更新批大小、批计数和间隔。以便释放内存。在我们的情况下，巨大的堆内存用于缓冲日志消息并批量发送。如果间隔更长，则可能会填满堆内存，从而影响性能（需要更多的GC活动）。

5）在单独的调度程序上运行阻塞操作。

6）使用自定义序列化器（protobuf）并避免使用JavaSerializer。

7）将以下java_opt添加到jar中

export java_opts=“$java_opts-xx:+UnlockExperimentalVmOptions-xx:+usecGroupMemoryLimitForHeap-xx:MaxRamFraction=2-djava.security.egd=file:/dev/./urandom”

最主要的是xx:maxRamFraction=2，它将占用60%以上的可用内存。默认情况下，它的4意味着您的应用程序将只使用可用内存的四分之一，这可能是不够的。

参见:https://blog.csanchez.org/2017/05/31/running-a-jvm-in-a-container-without-get-kill/

问候,

维诺特