Multithreading 通过Akka应用程序中的上下文切换实现高CPU使用率

我正在维护和开发两个Akka Scala应用程序，它们与串行设备接口以收集传感器信息。两者之间的主要区别在于，一个（我的二氧化碳传感器应用程序）使用1%的CPU，而另一个（我的功率传感器应用程序）使用250%的CPU。Linux机器（Raspberry Pi 3）和我的Windows桌面PC上都是如此。代码方面的主要区别是CO2直接使用串行库（），而功率传感器应用程序通过一层中间件将串行库的输入/输出流转换为Akka源/接收器：

  val port = SerialPort.getCommPort(comPort)

  port.setBaudRate(baudRate)
  port.setFlowControl(flowControl)
  port.setComPortParameters(baudRate, dataBits, stopBits, parity)
  port.setComPortTimeouts(timeoutMode, timeout, timeout)

  val isOpen = port.openPort()

  if(!isOpen) {
    error(s"Port $comPort could not opened. Use the following documentation for troubleshooting: https://github.com/Fazecast/jSerialComm/wiki/Troubleshooting")

    throw new Exception("Port could not be opened")
  }

  (reactive.streamSource(port.getInputStream), reactive.streamSink(port.getOutputStream))

当我看到如此高的CPU使用率时，我立即用分析器（VisualVM）对其进行了攻击，它告诉我以下内容：

在谷歌搜索Unsafe.park后，我找到了以下答案：-使用此信息，我检查了有无功率传感器应用程序的上下文切换量，结果非常清楚问题的根本原因：

pi@dex:~ $ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
10  0  32692  80144  71228 264356    0    0     0     5    7    8 38  5 55  2  0
 1  0  32692  80176  71228 264356    0    0     0    76 12932 18856 59  6 35  0  0
 1  0  32692  80208  71228 264356    0    0     0     0 14111 20570 60  8 32  0  0
 1  0  32692  80208  71228 264356    0    0     0     0 13186 16095 65  6 29  0  0
 1  0  32692  80176  71228 264356    0    0     0     0 14008 23449 56  6 38  0  0
 3  0  32692  80208  71228 264356    0    0     0     0 13528 17783 65  6 29  0  0
 1  0  32692  80208  71228 264356    0    0     0    28 12960 16588 63  6 31  0  0

pi@dex:~ $ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0  32692 147320  71228 264332    0    0     0     5    7    8 38  5 55  2  0
 0  0  32692 147296  71228 264332    0    0     0    84  963 1366  0  0 98  2  0
 0  0  32692 147296  71228 264332    0    0     0     0  962 1347  1  0 99  0  0
 0  0  32692 147296  71228 264332    0    0     0     0  947 1318  1  0 99  0  0

正如您所看到的，仅通过关闭我的应用程序，上下文切换的数量就减少了约12000次/秒。我继续检查哪些线程正在执行此操作，Akka似乎真的很想执行以下操作：

这里的评论和另一个问题都指向调整Akka的并行度设置。我在application.conf中添加了以下内容，但没有结果

akka {
  log-config-on-start = "on"
  actor{
    default-dispatcher {
      # Dispatcher is the name of the event-based dispatcher
      type = Dispatcher
      # What kind of ExecutionService to use
      executor = "fork-join-executor"
      # Configuration for the fork join pool
      default-executor {
        fallback = "fork-join-executor"
      }
      fork-join-executor {
        # Min number of threads to cap factor-based parallelism number to
        parallelism-min = 1
        # Parallelism (threads) ... ceil(available processors * factor)
        parallelism-factor = 1.0
        # Max number of threads to cap factor-based parallelism number to
        parallelism-max = 1
      }
      # Throughput defines the maximum number of messages to be
      # processed per actor before the thread jumps to the next actor.
      # Set to 1 for as fair as possible.
      throughput = 1
    }
  }
  stream{
    default-blocking-io-dispatcher {
      type = PinnedDispatcher
      executor = "fork-join-executor"
      throughput = 1

      thread-pool-executor {
        core-pool-size-min = 1
        core-pool-size-factor = 1.0
        core-pool-size-max = 1
      }
      fork-join-executor {
        parallelism-min = 1
        parallelism-factor = 1.0
        parallelism-max = 1
      }
    }
  }
}

这似乎可以提高CPU使用率（100%->65%），但CPU使用率仍然过高

更新21-11-'16 问题似乎在我的图表中。不运行图形时，CPU使用率会立即降至正常水平。图表如下所示：

val streamGraph = RunnableGraph.fromGraph(GraphDSL.create() { implicit builder =>
  import GraphDSL.Implicits._

  val responsePacketSource = serialSource
    .via(Framing.delimiter(ByteString(frameDelimiter), maxFrameLength, allowTruncation = true))
    .via(cleanPacket)
    .via(printOutput("Received: ",debug(_)))
    .via(byteStringToResponse)

  val packetSink = pushSource
    .via(throttle(throttle))

  val zipRequestStickResponse = builder.add(Zip[RequestPacket, ResponsePacket])
  val broadcastRequest = builder.add(Broadcast[RequestPacket](2))
  val broadcastResponse = builder.add(Broadcast[ResponsePacket](2))

  packetSink ~> broadcastRequest.in
  broadcastRequest.out(0) ~> makePacket ~> printOutput("Sent: ",debug(_)) ~> serialSink
  broadcastRequest.out(1) ~> zipRequestStickResponse.in0

  responsePacketSource ~> broadcastResponse.in
  broadcastResponse.out(0).filter(isStickAck) ~> zipRequestStickResponse.in1
  broadcastResponse.out(1).filter(!isStickAck(_)).map (al => {
    val e = completeRequest(al)
    debug(s"Sinking:          $e")
    e
  }) ~> Sink.ignore

  zipRequestStickResponse.out.map { case(request, stickResponse) =>
    debug(s"Mapping: request=$request, stickResponse=$stickResponse")
    pendingPackets += stickResponse.sequenceNumber -> request
    request.stickResponse trySuccess stickResponse
  } ~> Sink.ignore

  ClosedShape
})

streamGraph.run()

---

当从broadcastResponse中删除过滤器时，CPU使用率将降至正常水平。这让我相信zip永远不会发生，因此，图形进入了错误的状态

问题在于Fazecast的JSerialCom库有许多不同的超时模式

static final public int TIMEOUT\u NONBLOCKING=0x00000000；
静态最终公共整数超时\读取\半阻塞=0x00000001；
静态最终公共整数超时\写入\半阻塞=0x00000010；
静态最终公共整数超时\读取\阻塞=0x00000100；
静态最终公共整数超时\写入\阻塞=0x00001000；
静态最终公共整数超时\u扫描器=0x00010000；

---

使用非阻塞

read（）

方法（

TIMEOUT\u NONBLOCKING

）与Akka流的

InputStreamPublisher

结合使用时，会导致非常高的CPU使用率。要防止这种情况，只需使用

TIMEOUT\u READ\u SEMI\u BLOCKING

或

TIMEOUT\u READ\u BLOCKING

减少默认调度程序和阻塞io调度程序的并行数。如果您的工作负载通常不受CPU约束，请考虑切换到线程池执行器。@ ViktorKlang编辑了我的问题，以反映我在调试调度器时没有重新配置默认阻塞IO的尝试。dispatcher@ViktorKlang更新-似乎有一些改进，但CPU使用率仍然非常高（65%）