erlang - 什么时候适合从零增加异步线程大小？

Question

我一直在阅读文档，试图了解何时通过 +AN 开关增加异步线程池大小是有意义的。

我完全准备好进行基准测试，但我想知道是否有一个经验法则，当人们应该怀疑将池大小从 0 增加到 N（或 N 到 N+M）会有所帮助时。

谢谢

Answer 1

BEAM 在调用调度程序的特殊线程中运行 Erlang 代码。默认情况下，它将为处理器中的每个内核启动一个调度程序。这可以控制和启动时间，例如，如果您不想在所有内核上运行 Erlang，而是“保留”一些用于其他事情。通常，当您执行文件 I/O 操作时，它会在调度程序中运行，并且由于文件 I/O 操作相对较慢，它们会在运行时阻塞该调度程序。这会影响实时属性。通常你不会做那么多的文件 I/O，所以这不是问题。

异步线程池是用于 I/O 操作的操作系统线程。通常池是空的，但如果您+A在启动时使用，那么 BEAM 将为该池创建额外的线程。然后这些线程将仅用于文件 I/O 操作，这意味着调度程序线程将不再阻塞等待文件 I/O，并且实时属性得到改善。当然，这是因为操作系统线程不是免费的。线程不会混合，因此调度程序线程只是调度程序线程，而异步线程只是异步线程。

如果您正在为端口编写链接驱动程序，这些驱动程序也可以使用异步线程池。但是您必须自己检测它们何时启动。

您需要多少取决于您的应用程序。默认情况下没有启动。像@demeshchuk 一样，我也听说 Riak 在打开许多文件时喜欢拥有一个大型异步线程池。我唯一的建议是尝试并测量。与所有优化一样？

Answer 2

默认情况下，正在运行的 Erlang VM 中的线程数等于处理器逻辑核心数（当然，如果您使用的是 SMP）。

根据我的经验，当您同时进行许多文件 I/O 操作时，增加 +A 参数可能会提高一些性能。而且我怀疑增加 +A 可能会提高整体流程的性能，因为 BEAM 的调度程序非常快速且经过优化。

说到确切的数字——我认为这完全取决于你的应用程序。比如说，在 Riak 的情况下，打开文件的最大数量或多或少是可预测的，您可以将 +A 设置为这个最大值，或者如果它太大（默认为 64，顺便说一句），则可以少几倍。如果您的应用程序包含数百万个文件，并且您将它们提供给 Web 客户端 - 那是另一回事；最有可能的是，您可能希望使用自己的代码和自己的环境运行一些基准测试。

最后，我相信我从来没有见过+A超过一百。并不意味着你不能设置它，但它可能没有意义。