作为全球IPPBX潜力股，vitalpbx一直为Asterisk开源社区做着非常大的贡献。vitalpbx已经多次分享了在使用Asterisk开发IPPBX方面的技术经验，帮助Asterisk用户解决了很多技术疑惑。回到标题的提问，其实这个问题需要回答N次，答案是：是的，Asterisk PBX 支持多核功能。作为开源电信软件，Asterisk 可以利用系统中的多个核心或处理器。从 1.8 版本开始，Asterisk 在其多核支持方面进行了显著改进。这些改进允许更高效地将工作负载分布在多个 CPU 核心上，从而提升性能和处理能力。

硬件资源：运行Asterisk的服务器的处理能力（CPU）、内存和网络容量会影响其能处理的并发呼叫数量。硬件性能越强的服务器通常能处理更多的呼叫。

网络状况：可用带宽和网络稳定性也会影响Asterisk能处理的并发呼叫数量。带宽不足或网络拥堵会限制并发呼叫的数量。

编解码器选择：呼叫中使用的编解码器选择也会影响并发呼叫数量。一些编解码器需要更多的处理能力，因此选择高效的编解码器可以增加并发呼叫数量。

系统配置：Asterisk的配置，包括媒体处理、呼叫路由和呼叫处理相关的设置，会影响并发呼叫的容量。适当的优化和调整可以提高Asterisk的性能和可扩展性。

呼叫录音：录音功能会影响Asterisk的并发呼叫容量。当启用呼叫录音时，Asterisk需要分配额外的资源来捕捉和存储每个录音呼叫的音频数据，这会消耗CPU、内存和磁盘I/O资源，从而减少总体并发呼叫容量。

值得注意的是，对于高容量或企业级部署，通常会使用负载均衡技术、分布式架构和多台Asterisk服务器来高效处理大量并发呼叫。

总之，Asterisk能支持的具体并发呼叫数量受多种因素影响，包括硬件资源、网络状况、编解码器选择和系统配置。在适当的硬件和优化下，Asterisk可以在单台服务器上处理大量的并发呼叫。

测试

为了测试Asterisk在不同硬件条件下支持的并发呼叫数量，我们需要编写一个脚本并通过它进行测试。

以下是脚本工作原理的描述：

服务器，需要两台服务器，一台用于执行测试，另一台用于发送测试呼叫。执行测试的服务器是我们的源服务器，发送呼叫的服务器是目标服务器。目标服务器的硬件容量必须不低于源服务器。

本地IP，由于两台服务器之间需要建立中继连接，并且通过IP进行身份验证，因此需要知道源服务器的IP地址。

远程IP，因为需要从源服务器访问目标服务器以创建IP中继，所以需要知道目标服务器的IP。在第一次开始测试时，系统会提示输入目标服务器的root密码。

SSH远程端口（默认是22），某些服务器出于安全原因可能使用不同的SSH端口，因此请求输入此端口信息。

网络接口名称（例如：eth0），这是两台服务器互连的网络接口。这些数据非常重要，因为还需要测量带宽的消耗。可以使用命令“ip a”来获取接口名称。

协议（1.-SIP，2.-IAX，3.-PJSIP），尽管协议选择对测试结果影响不大，因为主要工作负载在呼叫建立后的RPT数据包上，但我们仍将其作为一个选项，以便您进行自己的测试。

编解码器（1.-无，2.-G79，3.- GSM），用于测试的编解码器。目前，由于互联网连接的改善，不再需要使用压缩编解码器。

录音（是，否），如果需要录制呼叫，请选择“是”。呼叫录音会严重降低服务器的并发呼叫能力，因为它需要大量CPU处理。

测试结果  

以下是结果中每列的描述：  

步骤，测试每N秒进行的次数。  

通话数，测试生成的通话数量。  

Asterisk通话数，Asterisk当前正在进行的通话数量。  

CPU负载，CPU使用的百分比，若CPU有多个核心，则已经考虑该百分比。  

负载，最后一分钟的CPU平均负载。如果这个数字大于CPU核心数，意味着进程在队列中等待，这会严重影响通话。  

内存，正在使用的内存百分比。  

上传带宽，通话中上传带宽（kb/s）。  

下载带宽，通话中下载带宽（kb/s）。  

在vultr.com服务器上进行了一系列测试后，我们得出以下结论：  

Asterisk支持多核，并在单个进程中利用线程，这使其非常高效。  

我们用一台48核物理服务器进行了测试，并在46% CPU占用率下达到了4,542个并发通话的最大值。这个限制是由于Asterisk不允许更多的并发通话；不过，你可以修改源代码来移除这个限制。我们收到的错误如下：   

“FRACK!, Failed assertion Excessive refcount 100000 reached on ao2 object”  

如果我们编辑Asterisk的源代码文件，可以实现更多的并发通话。

# file main/astobj2.cEXCESSIVE_REF_COUNT 900000# file include/asterisk/taskprocessor.hAST_TASKPROCESSOR_HIGH_WATER_LEVEL 20000br

虽然我们不推荐这种做法，因为我们认为服务器同时处理4,500次呼叫已经足够了。

如果我们想在PBX中保持良好的音频质量，并避免影响整个系统的过载情况，建议使用Asterisk参数maxload。当配置这个参数后，Asterisk在超过这个参数时将不再允许更多的呼叫。为了更好地理解这个参数，需要考虑以下几点：

所有服务器都有一个负载记录，负载平均值是指在特定时间段内处于可运行（或等待执行）状态的进程的平均数量。它提供了系统工作负载或需要CPU时间的进程数量的指示。Asterisk取最后一分钟的负载平均值，当这个负载平均值超过maxload时，Asterisk将停止处理呼叫。

请注意，允许的负载平均值与CPU核心数直接相关。在拥有4个CPU核心的系统中，最大值可以达到4而不会影响系统的处理能力。如果值超过4，意味着有进程在等待，对于数据这不是问题，但对于语音则是问题，因为语音包可能会出现切割或丢失的情况。

因此，我们建议将maxload的值设置为CPU核心数减1（适用于4到12个CPU的系统）。以确保一切正常工作。

要考虑到这个负载平均值是最后一分钟的平均负载，并不是实时的。因此，即使应用了CPU核心数减1的配置（适用于4到12个CPU的系统），我们仍可能会遇到语音问题。

配置这个参数的文件在：

nano /etc/Asterisk/vitalpbx/asterisk__20-options.conf[options](+)Maxload=3br

正如我们所见，使用裸机的结果比虚拟化要好得多。

我们不建议在生产环境中使用共享CPU虚拟化，因为结果会受到服务器所在环境（邻居）的很大影响。