Yes, Asterisk PBX is multicore capable. Asterisk, being an open-source telecommunications software, can utilize multiple cores or processors in a system. Starting from version 1.8, Asterisk introduced significant improvements in its multicore support. These improvements allow for more efficient distribution of workload across multiple CPU cores, resulting in enhanced performance and processing capacity.
With each subsequent version, Asterisk has continued to enhance its multicore capabilities. However, it’s important to note that the extent to which Asterisk effectively utilizes multicore resources can vary depending on factors such as system configuration, workload, and specific optimization for the deployment environment. Additionally, not all Asterisk modules and components may be specifically designed to fully leverage multiple cores. Some tasks, such as audio transcoding or processing certain protocols, may still be more dependent on a single core.
In general, Asterisk can utilize multiple cores to distribute workload and improve performance in appropriately configured environments. However, the actual effectiveness of multicore capabilities will depend on the aforementioned factors and how the system is configured and optimized for multicore usage.
The number of concurrent calls that Asterisk can support depends on various factors, including hardware capabilities, system configuration, network conditions, and the specific configuration of the Asterisk server.
Asterisk is known for its scalability and ability to handle many concurrent calls. With proper hardware and configuration, Asterisk can handle hundreds or even thousands of concurrent calls on a single server.
The specific number of concurrent calls that Asterisk can support will vary based on factors such as:
It’s worth noting that for high-volume or enterprise-grade deployments, it’s common to use load balancing techniques, distributed architectures, and multiple Asterisk servers to handle many concurrent calls efficiently.
In summary, the exact number of concurrent calls that Asterisk can support is highly dependent on various factors, including hardware resources, network conditions, codec selection, and system configuration. With proper hardware and optimization, Asterisk can handle a significant number of concurrent calls on a single server.
To carry out the tests of how many concurrent calls Asterisk supports depending on the hardware, we set ourselves the task of making a script and with it carry out the tests.
Next, we describe how the script works:
These are the descriptions of each column in the result:
After carrying out a series of tests on vultr.com servers, we reached the following conclusions:
“FRACK!, Failed assertion Excessive refcount 100000 reached on ao2 object”
If we go to the Asterisk source code and edit the files, we could have more concurrent calls.
# file main/astobj2.c
EXCESSIVE_REF_COUNT 900000
# file include/asterisk/taskprocessor.h
AST_TASKPROCESSOR_HIGH_WATER_LEVEL 20000
Although we do not recommend this practice since we believe that it is more than enough for a server to have 4,500 concurrent calls.
nano /etc/Asterisk/vitalpbx/asterisk__20-options.conf
[options](+)
Maxload=3
Then you must restart Asterisk
systemctl restart asterisk
To perform the tests, we recommend you go to the following link:
https://github.com/VitalPBX/VitalPBX-Stress-Test
Test results on Bare Metal Servers:
Test results on Dedicated vCPU Virtual Servers:
As we can see the results when using Bare Metal were much better than with Virtualization.
We do not recommend using shared CPU virtualization in production, since the results will depend a lot on the environment (neighbors) where the server resides.
To carry out your own tests and have a gift of US$ 100.00 at vultr.com we recommend the following link:
https://www.vultr.com/?ref=9472294-8H
We also recommend you watch the following video, where the concurrent call capability is shown manually on a Raspberry PI 3 and PI 4.
Below we show a detail of the result of one of the tests:
Virtual
Model name: AMD EPYC-Rome Processor
CPU MHz: 2000
CPU(s): 4
Thread(s) per core: 2
Core(s) per socket: 2
Mem: 8Gb
Disk: 50GB NVMe
Cost: US$ 80.00/month
While the load of Asterisk calls may be distributed evenly across 4 cores in many scenarios, there are situations where one core might become overloaded:
Non-Asterisk Processes: Other processes and applications on the system might be consuming significant resources on a specific core. While the operating system should efficiently distribute the load, there could be situations where this doesn’t occur optimally.
CPU Affinity or Pinning: On some systems, it’s possible to set a process’s “affinity” to run on a specific core (known as “CPU pinning”). If Asterisk or one of its subprocesses is accidentally (or deliberately) set to run only on a specific core, that core might become overloaded.
Tasks That Aren’t Inherently Parallelizable: While Asterisk is multi-threaded, not all tasks can be efficiently parallelized. If there’s a particular operation that requires a specific sequence or can’t be broken down into smaller tasks, this operation might end up running on a single core.
Older Versions or Configuration: Older versions of Asterisk might not have the optimizations present in newer releases to fully take advantage of multi-core systems. Additionally, certain configurations or modules might impact how Asterisk uses cores.
Operating Systems and Scheduling: How the operating system handles the scheduling of processes and threads on cores can influence how the load is distributed. In most cases, modern systems are good at distributing, but there are specific situations or configurations that could lead to imbalance.
Interrupts and Hardware Handling: System interrupts, especially those related to hardware (like network cards or telephony cards), might be handled preferentially by a specific core. If there’s a high volume of interrupts, this could lead to a disproportionate load on one core.
To diagnose and address issues of overload on a single core, it’s essential to:
top, htop, or mpstat to observe the load distribution.
If a single core is overloaded, it can lead to audio problems in Asterisk. Here’s why:
Real-time Processing: Audio handling in a PBX system like Asterisk is a real-time task. This means that audio packets must be processed and transmitted within a specific timeframe to ensure continuous audio flow. If a core is overloaded and cannot process these packets in time, you could experience audio disruptions.
Dropped Packets: Overloading can cause the system to drop RTP (Real-time Transport Protocol) packets. RTP is the protocol Asterisk uses to transmit audio. Dropped packets result in gaps or jitter in the audio stream.
Increased Latency: An overloaded core can introduce delays in processing, leading to increased audio latency. In voice communications, even small delays can be noticeable and disruptive.
Transcoding Delays: If Asterisk is configured to transcode audio (convert from one codec to another), this process requires CPU resources. An overloaded core can struggle with real-time transcoding, causing audio issues.
Effects on Other Processes: Asterisk performs numerous tasks other than audio processing, such as call signaling, call routing, handling of various modules, and more. If a core is overloaded, the performance of these tasks can also be affected, indirectly influencing audio quality. For instance, if the core is too busy to handle signaling properly, it might not set up, modify, or tear down calls efficiently.
Echo Cancellation: Some tasks, like echo cancellation, are CPU-intensive. An overloaded CPU might not perform these tasks efficiently, leading to poor audio quality.
To mitigate audio problems due to CPU overload:
Monitor System Performance: Regularly monitor your system’s performance using tools like top, htop, and mpstat. Keep an eye on CPU usage, load averages, and context switches.
Optimize Configuration: Ensure that Asterisk’s configuration is optimized. This includes using appropriate codecs, minimizing unnecessary transcoding, and optimizing dialplan scripts.
Consider Hardware Upgrades: If you’re consistently facing performance issues, it might be worth upgrading to a more powerful server or adding additional servers and distributing the load.
Load Balancing: If you have a high call volume, consider implementing a load balancer to distribute the SIP traffic across multiple Asterisk servers.
Avoid Running Other Intensive Applications: Ensure that other CPU-intensive applications are not running on the same server as Asterisk, especially if you’re facing performance issues.
In summary, yes, an overloaded core can lead to audio problems in Asterisk because of the real-time nature of audio processing. Regular monitoring and optimization are key to ensuring smooth and clear voice communication.
After having carried out stress tests on VitalPBX-Asterisk for several days, we reached the following conclusions:
Therefore, while bandwidth is important, factors such as latency, jitter, packet loss, QoS implementation, and hardware performance need to be considered to ensure quality VoIP transmission. A comprehensive approach to addressing these aspects will contribute to a better calling experience.
Migrating from VitalPBX 4 to 4.5 follows a similar approach to the migration process from version 3 to 4. Below is a detailed guide to
Introduction In this guide, we will walk you through the process of building a highly available and distributed file server using GlusterFS on three Debian
Prerequisites for Implementing MariaDB Galera with VitalPBX Before setting up MariaDB Galera with VitalPBX, ensure you have the following:+ 1. Infrastructure Requirements: At least three
VitalPBX provides a robust and scalable platform, which will allow you to manage your PBX in an easy and intuitive way.
2292 NW 82nd Ave HB 002998 Miami, Florida 33198.
Email: sales@vitalpbx.com
At VitalPBX, your feedback is crucial. If our system has benefited your business, please leave us a review on Trustpilot. Thank you!