关于elixir:elixir-0080-读-erlang-开发团队博客-之-N-对-1-并行消息的性能优化

7次阅读

共计 1481 个字符,预计需要花费 4 分钟才能阅读完成。

自从 erlang OTP 团队开设技术博客以来,很多高质量的文章让咱们有机会可能理解 erlang 外部的各种机制。譬如最近的这篇 https://www.erlang.org/blog/p…,就讲述了在 erlang 虚拟机中是如何对“N 对 1”的过程消息传递进行性能优化的。

本文只是站在笔者的角度对文章内容进行转述,如有了解谬误或者不到位的中央,敬请在评论中指出。

下面这张图很直观地体现了优化的成果,这是在多核机器上,很多过程同时向一个过程发送短消息的性能比照。其中横轴是过程数量,纵轴是每秒操作数。能够看到在优化后,曾经实现了程度扩大,即过程数量越多,每秒操作数越多。而在优化之前,过程数越多,性能越低。

在深刻理解这个优化是如何做到的之前,先来理解一下 erlang 虚拟机中的信号(signal)机制。

在 erlang 虚拟机中,实体 (entity) 代表所有并发执行的货色,包含过程、Port 等等。一般的过程音讯也是一种信号。信号的程序遵循以下规定:

如果实体 A 先发送信号 S1 给 B, 而后发送 S2 给 B。那么 S1 保障不会在 S2 之后达到。

艰深地讲,设想一条 N 个车道的公路,不容许超车,那么在同一条车道上,汽车的程序是肯定的;而不同车道之间,汽车的前后总是在变动。

下图是在优化之前,一个过程内简略构造。

过程发送音讯的步骤是这样的:

  1. 调配一个链表的节点,其中蕴含信号
  2. 获取外信号队列(OuterSinalQueue)的锁
  3. 将信号节点增加到外信号队列的前面
  4. 开释锁。

过程收取音讯的步骤是这样的:

  1. 获取外信号队列的锁
  2. 将外信号队列的内容增加到内信号队列(InnerSinalQueue)前面
  3. 开释锁。

以上是选项 {message_queue_data, off_heap} 开启时的机制。而默认的选项是 {message_queue_data, on_heap}, 本次的这个优化其实只作用于 off_heap 的状况,也就是如果咱们没有对 message_queue_data 这个选项进行配置,那么这个优化就和咱们无关。那么默认状况下的消息传递步骤是什么呢?尽管和这个优化无关,但文章里还是具体介绍了一下:

发送音讯的步骤:

  1. 尝试用 try_lock 来获取主过程锁(MainProcessLock)。
    如果胜利:
    1. 在过程的主堆(main heap)上为信号调配空间,并将信号复制到那里
    2. 调配一个链表节点,蕴含指向那个信号的地位的指针
    3. 获取外信号队列锁
    4. 将信号节点增加到外信号队列的前面
    5. 开释外信号队列锁
    6. 开释主过程锁
    如果失败:
    1. 调配一个链表的节点,其中蕴含信号
    2. 获取外信号队列锁
    3. 将信号节点增加到外信号队列的前面
    4. 开释外信号队列锁。

能够看出 on_heap 的益处就是在获取主过程锁胜利的状况下,信号数据被间接复制到了过程的主堆上。害处就是须要获取主过程锁,来避免在这个过程中产生垃圾回收。所以,在十分多的过程同时给一个过程发消息的时候,off_heap具备更好的扩展性,因为不须要去争抢接收者的主过程锁。

尽管如此,外信号队列锁仍旧是一个性能瓶颈。

上面咱们能够聊聊如何优化了。

回顾咱们之前提到的 erlang 虚拟机对于信号程序的要求,能看出咱们须要的是一条 N 车道的公路,当初却只有一个收费站(接收者的外信号队列锁),车全堵在这了。优化的计划显然也跃然纸上了,就是减少“收费站“的数量。通过简略地对发送者过程的 pid 做哈希,将信号分流到 64 个 slot 队列中。

只有在同时获取外信号队列的过程数量超过肯定阈值的时候,此优化才会被触发。

此优化为咱们在多核机器上进行 N 对 1 的大量消息传递提供了更好的性能。更多的细节请参见原文。

正文完
 0