Scaling: Difference between revisions

From VoIPmonitor.org
(Review: oprava konfigurace voipmonitor.conf (odstranění neplatné sekce [general], oprava mysqluser→mysqlusername), zkrácení AI Summary)
(Rewrite: konsolidace, zkrácení duplicit, lepší struktura)
 
Line 2: Line 2:
[[Category:Administration]]
[[Category:Administration]]


This guide provides a comprehensive overview of performance tuning and scaling for VoIPmonitor. It covers the three primary system bottlenecks and offers practical, expert-level advice for optimizing your deployment for high traffic loads.
This guide covers performance tuning for high-traffic VoIPmonitor deployments, addressing the three primary system bottlenecks.


== Understanding Performance Bottlenecks ==
== Understanding Performance Bottlenecks ==
A VoIPmonitor deployment's maximum capacity is determined by three potential bottlenecks. Identifying and addressing the correct one is key to achieving high performance.
 
A VoIPmonitor deployment's capacity is limited by three potential bottlenecks:


<kroki lang="plantuml">
<kroki lang="plantuml">
Line 11: Line 12:
skinparam shadowing false
skinparam shadowing false
skinparam defaultFontName Arial
skinparam defaultFontName Arial
skinparam rectangle {
  BorderColor #4A90E2
  BackgroundColor #FFFFFF
}


title VoIPmonitor Performance Bottlenecks
title VoIPmonitor Performance Bottlenecks
Line 22: Line 19:
rectangle "RTP/SIP\nProcessing" as PROC #E6FFE6
rectangle "RTP/SIP\nProcessing" as PROC #E6FFE6
rectangle "PCAP Files\nStorage" as DISK #FFF3E6
rectangle "PCAP Files\nStorage" as DISK #FFF3E6
database "MySQL/MariaDB\nDatabase" as DB #E6E6FF
database "MySQL/MariaDB" as DB #E6E6FF


NIC -right-> T0 : "1. CPU\nBottleneck"
NIC -right-> T0 : "1. CPU"
T0 -right-> PROC
T0 -right-> PROC
PROC -down-> DISK : "2. I/O\nBottleneck"
PROC -down-> DISK : "2. I/O"
PROC -right-> DB : "3. Database\nBottleneck"
PROC -right-> DB : "3. Database"


note bottom of T0
note bottom of T0
   Monitor: t0CPU in syslog
   Monitor: t0CPU
   Limit: Single CPU core
   Limit: 1 CPU core
end note
end note


note bottom of DISK
note bottom of DISK
   Monitor: iostat, ioping
   Monitor: iostat
   Solution: SSD, TAR archives
   Solution: SSD, TAR
end note
end note


note bottom of DB
note bottom of DB
   Monitor: SQLq in syslog
   Monitor: SQLq
   Solution: Partitioning, tuning
   Solution: RAM, tuning
end note
end note
@enduml
@enduml
</kroki>
</kroki>


The three bottlenecks are:
{| class="wikitable"
# '''Packet Capturing (CPU & Network Stack):''' The ability of a single CPU core to read packets from the network interface. This is often the first limit encountered.
|-
# '''Disk I/O (Storage):''' The speed at which the sensor can write PCAP files to disk. Critical when call recording is enabled.
! Bottleneck !! Description !! Monitor
# '''Database Performance (MySQL/MariaDB):''' The rate at which the database can ingest CDRs and serve data to the GUI.
|-
| '''1. Packet Capture''' || Single CPU core reading packets from NIC || <code>t0CPU</code> in syslog
|-
| '''2. Disk I/O''' || Writing PCAP files to storage || <code>iostat</code>, <code>ioping</code>
|-
| '''3. Database''' || CDR ingestion and GUI queries || <code>SQLq</code> in syslog
|}
 
'''Capacity:''' A modern server (24-core Xeon, 10Gbit NIC) can handle '''~10,000 concurrent calls''' with full RTP recording, or '''60,000+''' with SIP-only analysis.


On a modern, well-tuned server (e.g., 24-core Xeon, 10Gbit NIC), a single VoIPmonitor instance can handle up to '''10,000 concurrent calls''' with full RTP analysis and recording, or over '''60,000 concurrent calls''' with SIP-only analysis.
== Optimizing Packet Capture (CPU & Network) ==


== Optimizing Packet Capturing (CPU & Network) ==
The packet capture thread (t0) runs on a single CPU core. If <code>t0CPU</code> approaches 100%, you've hit the capture limit.
The most performance-critical task is the initial packet capture, handled by a single, highly optimized thread (t0). If this thread's CPU usage (<code>t0CPU</code> in logs) approaches 100%, you are hitting the capture limit.


=== Use a Modern Linux Kernel & VoIPmonitor Build ===
=== Prerequisites ===
Modern Linux kernels (3.2+) and VoIPmonitor builds include '''TPACKET_V3''' support, a high-speed packet capture mechanism. This is the single most important factor for high performance.


'''Recommendation:''' Always use a recent Linux distribution (AlmaLinux, Rocky Linux, or Debian) and the latest VoIPmonitor static binary. With this combination, a standard Intel 10Gbit NIC can often handle up to 2 Gbit/s of VoIP traffic without special drivers.
* '''Linux kernel 3.2+''' with TPACKET_V3 support
* '''Latest VoIPmonitor static binary'''


=== Network Stack & Driver Tuning ===
With a modern kernel and VoIPmonitor build, a standard Intel 10Gbit NIC handles up to 2 Gbit/s VoIP traffic without special drivers.
For high-traffic environments (>500 Mbit/s), fine-tuning the network driver and kernel parameters is essential.


==== NIC Ring Buffer ====
=== NIC Tuning (>500 Mbit/s) ===
The ring buffer is a queue between the network card driver and VoIPmonitor. A larger buffer prevents packet loss during short CPU usage spikes.


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Check maximum size
# Increase ring buffer (prevents packet loss during CPU spikes)
ethtool -g eth0
ethtool -g eth0                 # Check max size
 
ethtool -G eth0 rx 16384         # Set to max
# Set to maximum (e.g., 16384)
ethtool -G eth0 rx 16384
</syntaxhighlight>
 
==== Interrupt Coalescing ====
This setting batches multiple hardware interrupts into one, reducing CPU overhead.


<syntaxhighlight lang="bash">
# Enable interrupt coalescing (reduces CPU overhead)
ethtool -C eth0 rx-usecs 1022
ethtool -C eth0 rx-usecs 1022
</syntaxhighlight>
</syntaxhighlight>


==== Applying Settings Persistently ====
'''Persistent settings''' (Debian/Ubuntu <code>/etc/network/interfaces</code>):
To make these settings permanent, add them to your network configuration. For Debian/Ubuntu using <code>/etc/network/interfaces</code>:
 
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
auto eth0
auto eth0
Line 94: Line 88:
</syntaxhighlight>
</syntaxhighlight>


Note: Modern systems using NetworkManager or systemd-networkd require different configuration methods.
=== Configuration Optimizations ===


==== Configuration-Level Optimizations ====
{| class="wikitable"
Before investing in kernel-bypass solutions, ensure your <code>voipmonitor.conf</code> is optimized for performance. Several configuration parameters can significantly reduce CPU load and improve packet capture efficiency.
|-
! Parameter !! Purpose !! Recommendation
|-
| <code>interface_ip_filter</code> || IP-based filtering || More efficient than BPF <code>filter</code>
|-
| <code>pcap_dump_writethreads_max</code> || Compression threads || Set to CPU core count
|-
| <code>jitterbuffer_f1/f2/adapt</code> || Jitter simulation || Disable to save CPU (loses MOS metrics)
|}


;Use interface_ip_filter Instead of filter
<syntaxhighlight lang="ini">
:If you need to filter by IP address or subnet, use <code>interface_ip_filter</code> instead of the general BPF <code>filter</code> option. The <code>interface_ip_filter</code> directive is more efficient and reduces CPU overhead compared to complex BPF filters.
# /etc/voipmonitor.conf


<syntaxhighlight lang="ini">
# Efficient IP filtering (replaces BPF filter)
# More efficient IP-based filtering
interface_ip_filter = 192.168.0.0/24
interface_ip_filter = 192.168.0.0/24
interface_ip_filter = 10.0.0.0/8
interface_ip_filter = 10.0.0.0/8


# Less efficient BPF filtering (avoid if possible)
# Compression scaling
# filter = udp and (host 192.168.0.0/24 or host 10.0.0.0/8)
</syntaxhighlight>
 
{{Note|See [[Sniffer_configuration]] for the complete reference and description of <code>interface_ip_filter</code> (Interface Selection section).}}
 
;Optimize PCAP Compression Threads
:For systems with high call recording rates, PCAP compression can become CPU-intensive. VoIPmonitor can automatically scale compression threads.
 
<syntaxhighlight lang="ini">
# /etc/voipmonitor.conf
# Initial compression threads (auto-scales based on load)
pcap_dump_writethreads = 1
pcap_dump_writethreads = 1
# Maximum compression threads (adjust based on CPU cores)
pcap_dump_writethreads_max = 32
pcap_dump_writethreads_max = 32
# Asynchronous PCAP writing (enabled by default)
pcap_dump_asyncwrite = yes
pcap_dump_asyncwrite = yes
</syntaxhighlight>
</syntaxhighlight>


{{Tip|Set <code>pcap_dump_writethreads_max</code> to the number of CPU cores available for best performance on multi-core systems. Monitor <code>t0CPU</code> to ensure compression threads are not competing with the capture thread.}}
{{Warning|1=Disabling <code>jitterbuffer_*</code> removes MOS/jitter metrics. Only disable if you don't need quality monitoring.}}
 
;Adjust Jitterbuffer Settings Based on Traffic Patterns
:Jitterbuffer simulation adds CPU overhead. For production environments with stable networks, consider adjusting jitterbuffer settings to balance accuracy with performance.
 
<syntaxhighlight lang="ini">
# /etc/voipmonitor.conf
# Fixed 50ms jitterbuffer (default: yes)
jitterbuffer_f1 = yes
 
# Fixed 200ms jitterbuffer (default: yes)
jitterbuffer_f2 = yes
 
# Adaptive jitterbuffer up to 500ms (default: yes)
jitterbuffer_adapt = yes
</syntaxhighlight>


{{Warning|Disabling jitterbuffer analysis reduces CPU load but removes MOS and jitter quality metrics from CDRs. Only disable if you do not require voice quality monitoring.}}
=== Kernel-Bypass Solutions ===


=== Advanced Kernel-Bypass Solutions ===
For extreme loads, bypass the kernel network stack entirely:
If kernel and driver tuning are insufficient, you can offload the capture process entirely by bypassing the kernel's network stack.


{| class="wikitable"
{| class="wikitable"
Line 156: Line 126:
| '''[[DPDK]]''' || Open-source || ~70% || Multi-gigabit on commodity hardware
| '''[[DPDK]]''' || Open-source || ~70% || Multi-gigabit on commodity hardware
|-
|-
| '''PF_RING ZC/DNA''' || Commercial || 90% → 20% || High-volume enterprise
| '''PF_RING ZC''' || Commercial || 90% → 20% || High-volume enterprise
|-
|-
| '''Napatech SmartNICs''' || Hardware || <3% at 10 Gbit/s || Extreme performance requirements
| '''[[Napatech|Napatech SmartNICs]]''' || Hardware || <3% at 10Gbit/s || Extreme performance
|}
|}
;DPDK (Data Plane Development Kit)
:A set of libraries and drivers for fast packet processing. VoIPmonitor can leverage DPDK to read packets directly from the network card, completely bypassing the kernel. See [[DPDK|DPDK guide]] for details.
;PF_RING ZC/DNA
:A commercial software driver from ntop.org that dramatically reduces CPU load by bypassing the kernel.
;Napatech SmartNICs
:Specialized hardware acceleration cards that deliver packets with near-zero CPU overhead.


== Optimizing Disk I/O ==
== Optimizing Disk I/O ==
VoIPmonitor's modern storage engine is highly optimized to minimize random disk access, which is the primary cause of I/O bottlenecks.


=== VoIPmonitor Storage Strategy ===
=== VoIPmonitor Storage Strategy ===
Instead of writing a separate PCAP file for each call (which causes massive I/O load), VoIPmonitor groups all calls starting within the same minute into a single compressed <code>.tar</code> archive. This changes the I/O pattern from thousands of small, random writes to a few large, sequential writes, reducing IOPS by a factor of 10 or more.


'''Typical capacity:''' A standard 7200 RPM SATA drive can handle up to 2,000 concurrent calls with full recording.
VoIPmonitor groups all calls starting within the same minute into a single compressed <code>.tar</code> archive. This changes thousands of random writes into few sequential writes, reducing IOPS by 10x+.
 
'''Typical capacity:''' 7200 RPM SATA handles ~2,000 concurrent calls with full recording.


=== Filesystem Tuning (ext4) ===
=== Filesystem Tuning (ext4) ===
For the spool directory (<code>/var/spool/voipmonitor</code>), using an optimized ext4 filesystem can improve performance.


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Format partition without a journal (use with caution, requires battery-backed RAID controller)
# Format without journal (requires battery-backed RAID)
mke2fs -t ext4 -O ^has_journal /dev/sda2
mke2fs -t ext4 -O ^has_journal /dev/sda2
</syntaxhighlight>


# Add to /etc/fstab for optimal performance
<syntaxhighlight lang="ini">
/dev/sda2   /var/spool/voipmonitor  ext4   errors=remount-ro,noatime,data=writeback,barrier=0 0 0
# /etc/fstab
/dev/sda2 /var/spool/voipmonitor  ext4 errors=remount-ro,noatime,data=writeback,barrier=0 0 0
</syntaxhighlight>
</syntaxhighlight>


{{Warning|Disabling the journal removes protection against filesystem corruption after crashes. Only use this with a battery-backed RAID controller.}}
{{Warning|1=Disabling journal removes crash protection. Only use with battery-backed RAID controller (BBU).}}


=== RAID Controller Cache Policy ===
=== RAID Controller ===
A misconfigured RAID controller is a common bottleneck. For database and spool workloads, the cache policy should be set to '''WriteBack''', not WriteThrough. This applies for RPM disks, not fast SSDs.


'''Requirements:'''
Set cache policy to '''WriteBack''' (not WriteThrough). Requires healthy BBU. Commands vary by vendor (<code>megacli</code>, <code>ssacli</code>, <code>perccli</code>).
* A healthy Battery Backup Unit (BBU) is required
* Specific commands vary by vendor (<code>megacli</code>, <code>ssacli</code>, <code>perccli</code>)
* Refer to vendor documentation for LSI, HP, and Dell controllers


== Optimizing Database Performance (MySQL/MariaDB) ==
== Optimizing Database Performance ==
A well-tuned database is critical for both data ingestion from the sensor and GUI responsiveness.


{{Note|For extreme scenarios (4,000+ concurrent calls, UI lag, high SQL queue, or 1000+ CDRs/sec), see [[High-Performance_VoIPmonitor_and_MySQL_Setup_Manual]] for specialized configurations including innodb_flush_log_at_trx_commit=0, hourly partitioning, and centralized writer architecture.}}
=== Memory Configuration ===


=== Memory Configuration ===
The most critical parameter is <code>innodb_buffer_pool_size</code>.
The most critical database parameter is <code>innodb_buffer_pool_size</code>, which defines how much memory InnoDB uses to cache data and indexes.


{{Warning|On servers running both VoIPmonitor and MySQL, setting <code>innodb_buffer_pool_size</code> too high causes OOM (Out of Memory) killer events, resulting in CDR delays, crashes, and instability. See [[Sniffer_troubleshooting#Check_for_OOM_.28Out_of_Memory.29_Issues|OOM Troubleshooting]] for details.}}
{{Warning|1=Setting too high causes OOM killer events, CDR delays, and crashes. See [[Sniffer_troubleshooting#Check_for_OOM_.28Out_of_Memory.29_Issues|OOM Troubleshooting]].}}


==== Buffer Pool Sizing ====
'''Buffer Pool Sizing:'''


{| class="wikitable"
{| class="wikitable"
|-
|-
! Server Type !! Calculation !! Example (32GB RAM)
! Server Type !! Formula !! Example (32GB RAM)
|-
|-
| '''Shared''' (VoIPmonitor + MySQL) || (Total RAM - VoIPmonitor - OS overhead) / 2 || 14GB
| '''Shared''' (VoIPmonitor + MySQL) || (Total RAM - VoIPmonitor - OS) / 2 || 14GB
|-
|-
| '''Dedicated''' MySQL server || 50-70% of total RAM || 20-22GB
| '''Dedicated''' MySQL server || 50-70% of total RAM || 20-22GB
|}
|}


For shared servers, use this formula:
'''RAM Recommendations:'''
<syntaxhighlight lang="text">
innodb_buffer_pool_size = (Total RAM - VoIPmonitor memory - OS overhead - safety margin) / 2


Example for a 32GB server:
- Total RAM: 32GB
- VoIPmonitor process memory: ~2GB (check with ps aux)
- OS + other services overhead: ~2GB
- Available for buffer pool: 28GB
- Recommended innodb_buffer_pool_size = 14G
</syntaxhighlight>
==== RAM Recommendations ====
{| class="wikitable"
{| class="wikitable"
|-
|-
! Deployment Size !! Minimum RAM !! Recommended RAM
! Deployment Size !! Minimum !! Recommended
|-
|-
| Small (<500 concurrent calls) || 8GB || 16GB
| Small (<500 calls) || 8GB || 16GB
|-
|-
| Medium (500-2000 calls) || 16GB || 32GB
| Medium (500-2000) || 16GB || 32GB
|-
|-
| Large (>2000 calls) || 32GB || 64GB+
| Large (>2000) || 32GB || 64GB+
|}
|}


==== Disable Graphical Desktop ====
=== Key MySQL Parameters ===
A graphical desktop environment consumes 1-2GB of RAM unnecessarily. VoIPmonitor is managed through a web interface and does not require a desktop.
 
<syntaxhighlight lang="bash">
# Disable display manager
systemctl stop gdm          # Ubuntu/Debian with GDM
systemctl disable gdm
 
# Set default to multi-user (no GUI)
systemctl set-default multi-user.target
 
# Verify memory freed
free -h
</syntaxhighlight>
 
=== Other Key Parameters ===


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# /etc/mysql/my.cnf or /etc/mysql/mariadb.conf.d/50-server.cnf
# /etc/mysql/my.cnf or mariadb.conf.d/50-server.cnf
 
[mysqld]
[mysqld]
# Buffer pool size (calculate per above)
innodb_buffer_pool_size = 14G
innodb_buffer_pool_size = 14G
 
innodb_flush_log_at_trx_commit = 2  # Faster, minimal data loss risk
# Flush logs to OS cache, write to disk once per second (faster, minimal data loss risk)
innodb_file_per_table = 1           # Essential for partitioning
innodb_flush_log_at_trx_commit = 2
innodb_compression_algorithm = lz4 # MariaDB only
 
# Store each table in its own file (essential for partitioning)
innodb_file_per_table = 1
 
# LZ4 compression for modern MariaDB
innodb_compression_algorithm = lz4
</syntaxhighlight>
</syntaxhighlight>
{{Warning|For deployments with 4,000+ concurrent calls experiencing UI unresponsiveness, database queue growth (SQLq), or extremely high CDR insertion rates (1000+ CDRs/sec), the intermediate settings above may not be sufficient. See [[High-Performance_VoIPmonitor_and_MySQL_Setup_Manual]] for extreme performance configurations optimized for 10,000+ concurrent calls, including innodb_flush_log_at_trx_commit=0, hourly partitioning, and centralized writer architecture.}}


=== Slow Query Log ===
=== Slow Query Log ===


The MySQL slow query log can consume significant memory and disk I/O on high-traffic systems. If you are experiencing high memory utilization alerts or performance issues with the database server, consider adjusting or disabling the slow query log.
The slow query log can consume significant memory. Consider disabling on high-traffic systems:
 
{{Warning|Disabling the slow query log removes the ability to analyze slow queries for performance optimization. Only disable it temporarily or if you are certain you do not need it.}}


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# /etc/mysql/my.cnf or /etc/my.cnf.d/mysql-server.cnf
[mysqld]
[mysqld]
# Disable slow query log (set to 1 to enable)
slow_query_log = 0
slow_query_log = 0
 
# Or increase threshold: long_query_time = 600
# Alternative: Increase threshold to only log extremely slow queries (e.g., 600 seconds = 10 minutes)
long_query_time = 600
</syntaxhighlight>
</syntaxhighlight>


After changing MySQL configuration, restart the database and dependent services:
=== Database Partitioning ===
 
<syntaxhighlight lang="bash">
# Restart MySQL/MariaDB
systemctl restart mariadb  # or mysql
 
# Restart VoIPmonitor sniffer (depends on database)
systemctl restart voipmonitor
</syntaxhighlight>
 
=== Troubleshooting: Connection Refused Errors ===
 
If the VoIPmonitor GUI or sniffer experiences crashes with "Can't connect to MySQL server" or "Connection refused" errors, verify that MariaDB is configured with adequate memory.


'''Symptoms:'''
VoIPmonitor automatically partitions large tables (like <code>cdr</code>) by day. This is enabled by default and '''highly recommended'''.
* GUI server crashes repeatedly
* MariaDB connection refused errors in logs
* MariaDB service appears to be running (`systemctl status mariadb` shows active)
* Issues occur intermittently during peak call volumes


'''Cause:'''
See [[Data_Cleaning#Database_Cleaning_.28CDR_Retention.29|Database Partitioning]] for details.
When <code>innodb_buffer_pool_size</code> is set too low (e.g., default 128M or 256M), MariaDB may run out of memory for the InnoDB buffer pool during high call volumes or complex database queries. This can cause connection failures even while the database service remains technically running.


'''Solution:'''
=== Troubleshooting: Connection Refused ===
Edit the MariaDB configuration file (path varies by distribution):


<syntaxhighlight lang="bash">
'''Symptoms:''' GUI crashes, "Connection refused" errors, intermittent issues during peak volumes.
# Common configuration file locations:
# Debian/Ubuntu: /etc/mysql/mariadb.conf.d/50-server.cnf
# RHEL/CentOS: /etc/my.cnf.d/mariadb-server.cnf
# Generic: /etc/mysql/my.cnf


# Edit the file and increase innodb_buffer_pool_size
'''Cause:''' <code>innodb_buffer_pool_size</code> too low (default 128M is insufficient).
nano /etc/mysql/mariadb.conf.d/50-server.cnf
</syntaxhighlight>


Set a higher buffer pool size (example for a server with 8-16GB RAM):
'''Solution:''' Increase to 6G+ based on available RAM:


<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
[mysqld]
[mysqld]
# Increase from default 128M to 6G or higher, depending on available RAM
innodb_buffer_pool_size = 6G
innodb_buffer_pool_size = 6G
</syntaxhighlight>
</syntaxhighlight>
Restart MariaDB to apply the change:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
Line 347: Line 233:
</syntaxhighlight>
</syntaxhighlight>


{{Tip|Use the [[#Buffer Pool Sizing|Buffer Pool Sizing formula]] above to calculate the optimal value for your server. For most production deployments with 500-2000 concurrent calls, values between 6G and 14G are typical.}}
== Component Separation (Multi-Host Architecture) ==
 
=== Database Partitioning ===
VoIPmonitor automatically splits large tables (like <code>cdr</code>) into daily partitions. This is enabled by default and '''highly recommended'''.
 
'''Benefits:'''
* Massively improves GUI query performance (only relevant partitions are scanned)
* Allows instant deletion of old data by dropping partitions (thousands of times faster than DELETE)
 
See [[Data_Cleaning#The_Modern_Method:_Partitioning_.28Recommended.29|Database Partitioning]] for configuration details.
 
== Scaling Through Component Separation ==


For deployments requiring high availability and independent scaling of different workloads, VoIPmonitor's three core components (MySQL database, Sensor, and GUI) can be deployed on separate dedicated hosts. This architecture allows each component to be scaled based on its specific resource requirements.
For deployments exceeding 5,000-10,000 concurrent calls, separate VoIPmonitor components onto dedicated hosts.


=== When to Use Component Separation ===
=== Architecture Overview ===
 
Consider separating components when:
* You need to scale packet capture without affecting GUI responsiveness
* Database queries are becoming a bottleneck during peak hours
* You have multiple teams managing different aspects of the system (DBAs, network engineers, web administrators)
* You want to implement different high availability strategies for each component
* Your traffic volume exceeds 5,000-10,000 concurrent calls
 
=== Three-Host Architecture ===
 
In this model, each core VoIPmonitor component runs on a dedicated server:


{| class="wikitable"
{| class="wikitable"
Line 379: Line 243:
! Host !! Component !! Primary Resources !! Scaling Strategy
! Host !! Component !! Primary Resources !! Scaling Strategy
|-
|-
| '''Host 1: MySQL Database''' || MariaDB/MySQL server || RAM (50-70% for buffer pool), fast I/O (SSD/NVMe) || Add RAM, upgrade storage, add read replicas for reporting
| '''Host 1''' || MySQL Database || RAM, fast SSD || Add RAM, read replicas
|-
|-
| '''Host 2: Sensor(s)''' || Packet capture and analysis || Single CPU core (t0 thread), network I/O || Add more sensors for distributed capture, use DPDK/PF_RING
| '''Host 2''' || Sensor(s) || CPU (t0 thread), network || DPDK/PF_RING, more sensors
|-
|-
| '''Host 3: GUI''' || Web interface (PHP + Apache/Nginx) || CPU for database queries, network bandwidth || Horizontal scaling with load balancer, caching
| '''Host 3''' || GUI || CPU, network || Load balancer, caching
|}
|}


=== Configuration Steps ===
=== Configuration ===
 
==== Step 1: Deploy Dedicated MySQL Server ====
 
Configure the database server with proper MySQL/MariaDB tuning for VoIPmonitor. Use the dedicated server buffer pool sizing from [[#Memory_Configuration|Memory Configuration]].


'''MySQL Server:'''
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# /etc/mysql/my.cnf on MySQL Host
# /etc/mysql/my.cnf
[mysqld]
[mysqld]
bind-address = 0.0.0.0 # Allow remote connections
bind-address = 0.0.0.0
innodb_buffer_pool_size = 50G  # 50-70% of total RAM for dedicated DB server
innodb_buffer_pool_size = 50G  # 50-70% RAM for dedicated server
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table = 1
innodb_compression_algorithm = lz4
</syntaxhighlight>
</syntaxhighlight>
Grant access for remote connections:


<syntaxhighlight lang="sql">
<syntaxhighlight lang="sql">
CREATE USER 'voipmonitor'@'%' IDENTIFIED BY 'strong_password';
CREATE USER 'voipmonitor'@'%' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON voipmonitor.* TO 'voipmonitor'@'%';
GRANT ALL PRIVILEGES ON voipmonitor.* TO 'voipmonitor'@'%';
FLUSH PRIVILEGES;
</syntaxhighlight>
</syntaxhighlight>


==== Step 2: Deploy Sensor(s) ====
'''Sensor:'''
 
Install the VoIPmonitor sensor on one or more dedicated capture servers. Configure the sensor to connect to the remote MySQL database.
 
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
# /etc/voipmonitor.conf on Sensor Host
# /etc/voipmonitor.conf
 
id_sensor = 1
id_sensor = 1 # Unique per sensor
mysqlhost = mysql.server.ip
 
# Remote MySQL connection
mysqlhost = mysql.server.ip # IP of dedicated MySQL server
mysqldb = voipmonitor
mysqldb = voipmonitor
mysqlusername = voipmonitor
mysqlusername = voipmonitor
mysqlpassword = strong_password
mysqlpassword = strong_password
# Capture settings
interface = eth0
sipport = 5060,5061
# Performance tuning
pcap_dump_writethreads = 1
pcap_dump_writethreads_max = 32
</syntaxhighlight>
==== Step 3: Deploy Dedicated GUI ====
Install the VoIPmonitor GUI on a separate web server and configure it to connect to the remote MySQL database.
<syntaxhighlight lang="bash">
# Extract GUI package
tar -xzf voipmonitor-gui-latest.tar.gz -C /var/www/html/
# Edit GUI configuration
/var/www/html/voipmonitor/config/system_configuration.php
</syntaxhighlight>
Configure database connection through the GUI interface:
# Open <nowiki>http://gui.server.ip/voipmonitor</nowiki> in a browser
# Navigate to '''Settings > System Configuration > Database'''
# Configure:
# * Host: mysql.server.ip
# * User: voipmonitor
# * Password: strong_password
# * Database: voipmonitor
Alternatively, edit the configuration file directly:
<syntaxhighlight lang="php">
// /var/www/html/voipmonitor/config/system_configuration.php
define('DB_HOST', 'mysql.server.ip');
define('DB_USER', 'voipmonitor');
define('DB_PASS', 'strong_password');
define('DB_NAME', 'voipmonitor');
</syntaxhighlight>
</syntaxhighlight>


==== Network Connectivity Requirements ====
'''GUI:''' Configure via Settings > System Configuration > Database, or edit <code>config/system_configuration.php</code>.
 
Ensure firewall rules allow:


'''Firewall Rules:'''
{| class="wikitable"
{| class="wikitable"
|-
|-
! Source !! Destination !! Port !! Purpose
! Source !! Destination !! Port !! Purpose
|-
|-
| Sensor host || MySQL server || 3306 || Write CDRs to database
| Sensor || MySQL || 3306 || CDR writes
|-
|-
| GUI host || MySQL server || 3306 || Read/Write for queries and configuration
| GUI || MySQL || 3306 || Queries
|-
|-
| User browsers || GUI host || 80, 443 || Access web interface
| GUI || Sensor(s) || 5029 || PCAP retrieval
|-
|-
| (Optional) GUI host || Sensor host(s) || 5029 || Retrieve PCAP files (if using local processing mode)
| Users || GUI || 80, 443 || Web access
|}
|}


=== Advantages of Component Separation ===
{{Note|1=Component separation can be combined with [[Sniffer_distributed_architecture|Client-Server mode]] for multi-site deployments.}}
 
* '''Independent Scaling''' - Each component can be upgraded independently based on load
* '''Resource Optimization''' - Database servers need more RAM, sensors need fast CPUs, GUI needs network and query performance
* '''Isolation''' - Issues on one component do not affect others (e.g., GUI upgrade does not stop packet capture)
* '''Team Specialization''' - DBAs manage database, network engineers manage sensors, web team manages GUI
* '''High Availability Options''' - Different HA strategies for each component:
** MySQL: Galera cluster for multi-master replication
** Sensors: Client-server mode with failover
** GUI: Load balancer with multiple web servers


=== Comparison with Distributed Client-Server Mode ===
== Monitoring Performance ==


The three-host component separation architecture differs from [[Sniffer_distributed_architecture|Client-Server mode]]:
VoIPmonitor logs metrics every 10 seconds:
 
{| class="wikitable"
|-
! Architecture !! Scenario !! Best For
|-
| '''Component Separation (this section)''' || 3 dedicated hosts: MySQL + GUI + Sensor(s) || Single data center, independent scaling needs, centralized database
|-
| '''Client-Server Mode''' || Central server + remote sensors forwarding packets || Multi-site deployments, geographic distribution, low-resource remote sensors
|}
 
Both models can be combined: Use component separation at the central site, while remote sites use client-server mode to forward data.
 
=== Monitoring Component Health ===
 
Monitor each component separately:
 
* '''MySQL Server:''' Check <code>innodb_buffer_pool_size</code>, query throughput, slow queries
* '''Sensor(s):''' Monitor <code>t0CPU</code>, packet drops, SQL queue depth
* '''GUI Server:''' Monitor web server load, PHP-FPM statistics, page response times
 
Use the [[Sniffer_troubleshooting|Sniffer Troubleshooting]] guide for sensor issues and database performance tools for MySQL tuning.
 
== Monitoring Live Performance ==
VoIPmonitor logs detailed performance metrics every 10 seconds to syslog.


<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
# Debian/Ubuntu
tail -f /var/log/syslog | grep voipmonitor
tail -f /var/log/syslog | grep voipmonitor
# CentOS/RHEL
tail -f /var/log/messages | grep voipmonitor
</syntaxhighlight>
</syntaxhighlight>


=== Understanding the Log Output ===
'''Sample output:'''
Sample log line:
<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
voipmonitor[15567]: calls[315][355] PS[C:4 S:29/29 R:6354 A:6484] SQLq[0] heap[0|0|0] comp[54] [12.6Mb/s] t0CPU[5.2%] ... RSS/VSZ[323|752]MB
calls[315][355] PS[C:4 S:29 R:6354] SQLq[0] heap[0|0|0] t0CPU[5.2%] RSS/VSZ[323|752]MB
</syntaxhighlight>
</syntaxhighlight>


{| class="wikitable"
{| class="wikitable"
|-
|-
! Metric !! Description !! Warning Threshold
! Metric !! Description !! Warning Sign
|-
|-
| <code>calls[X][Y]</code> || X = active calls, Y = total calls in memory || -
| <code>calls[X][Y]</code> || Active / total calls in memory || -
|-
|-
| <code>SQLq[C]</code> || SQL queries waiting to be sent to database || Growing consistently = DB bottleneck
| <code>SQLq[N]</code> || SQL queries queued || Growing = DB bottleneck
|-
|-
| <code>heap[A{{!}}B{{!}}C]</code> || Memory usage % for internal buffers || A = 100% → packet drops
| <code>heap[A{{!}}B{{!}}C]</code> || Buffer usage % || A=100% = packet drops
|-
|-
| <code>t0CPU[X%]</code> || '''Main packet capture thread CPU usage''' || >90-95% = capture limit reached
| <code>t0CPU[X%]</code> || Capture thread CPU || >90% = limit reached
|-
|-
| <code>RSS/VSZ[X{{!}}Y]MB</code> || Resident/Virtual memory usage || RSS growing = memory leak
| <code>RSS/VSZ[X{{!}}Y]</code> || Memory usage (MB) || RSS growing = leak
|}
|}


=== Performance Diagrams ===
== See Also ==
 
The following diagrams illustrate the difference between standard kernel packet capture and optimized solutions:


[[File:kernelstandarddiagram.png|thumb|center|600px|Standard kernel packet capture path - packets traverse multiple kernel layers before reaching VoIPmonitor]]
* [[Sniffer_troubleshooting]] - Troubleshooting including OOM issues
 
* [[Data_Cleaning]] - Database and spool retention
[[File:ntop.png|thumb|center|600px|PF_RING/DPDK bypass mode - packets are delivered directly to VoIPmonitor, bypassing the kernel network stack]]
 
== See Also ==
* [[Sniffer_troubleshooting]] - Troubleshooting guide including OOM issues
* [[Data_Cleaning]] - Database and spool retention configuration
* [[Sniffer_configuration]] - Complete configuration reference
* [[Sniffer_configuration]] - Complete configuration reference
* [[DPDK]] - DPDK setup guide
* [[DPDK]] - DPDK setup guide
* [[IO_Measurement]] - Disk I/O benchmarking tools
* [[Sniffer_distributed_architecture]] - Client-Server mode


== AI Summary for RAG ==
== AI Summary for RAG ==
'''Summary:''' Guide to scaling VoIPmonitor for high-traffic environments. Three main bottlenecks: (1) Packet Capturing - TPACKET_V3, NIC tuning (ethtool ring buffer, interrupt coalescing), interface_ip_filter (more efficient than BPF), pcap_dump_writethreads for compression, kernel-bypass (DPDK, PF_RING, Napatech); (2) Disk I/O - TAR-based storage reduces IOPS, ext4 tuning, RAID WriteBack cache; (3) Database - innodb_buffer_pool_size formula for shared servers: (Total RAM - VoIPmonitor - OS) / 2 (e.g., 14GB for 32GB server), dedicated servers use 50-70% RAM. TROUBLESHOOTING: "MariaDB connection refused" = innodb_buffer_pool_size too low, increase to 6G+. For extreme loads (4000+ calls), see [[High-Performance_VoIPmonitor_and_MySQL_Setup_Manual]]. COMPONENT SEPARATION: Deploy MySQL, Sensor, GUI on separate hosts when traffic exceeds 5000-10000 calls. MySQL needs 50-70% RAM + SSD; Sensors need fast CPU (t0 thread); GUI can be load-balanced. Configuration: MySQL bind-address=0.0.0.0, sensors use mysqlhost=<IP>, GUI via Settings or config/system_configuration.php. Firewall: Sensor→MySQL (3306), GUI→MySQL (3306), Users→GUI (80/443), GUI→Sensor (5029). Can combine with Client-Server Mode for multi-site deployments.


'''Keywords:''' scaling, performance tuning, bottleneck, t0CPU, TPACKET_V3, DPDK, PF_RING, ethtool, ring buffer, interface_ip_filter, BPF filter, pcap_dump_writethreads, jitterbuffer, jitterbuffer_f1, jitterbuffer_f2, jitterbuffer_adapt, compression threads, PCAP async write, innodb_buffer_pool_size, OOM killer, shared server memory, database partitioning, SQLq monitoring, slow query log, slow_query_log, long_query_time, UI lag, unresponsive GUI, high performance, 4000 concurrent calls, 5000 concurrent calls, innodb_flush_log_at_trx_commit=0, hourly partitioning, rtpthreads, rtpthreads_start, RTP threads, innodb_io_capacity, innodb_thread_concurrency, innodb_flush_method, extreme performance, High-Performance Manual, component separation, three host architecture, dedicated MySQL server, dedicated GUI server, remote database, mysqlhost configuration, GUI remote database, independent scaling, high availability, Galera cluster, load balancer, DB_HOST, DB_USER, DB_PASS, DB_NAME, bind-address, firewall ports, GUI settings database configuration, connection refused, MariaDB connection refused, GUI crashes, database connection errors, mariadb.conf.d/50-server.cnf, MySQL crash, MariaDB crash, can't connect to MySQL
'''Summary:''' VoIPmonitor scaling guide covering three bottlenecks: (1) Packet Capture - use TPACKET_V3, NIC tuning (ethtool ring buffer/interrupt coalescing), interface_ip_filter instead of BPF, kernel-bypass (DPDK, PF_RING, Napatech); (2) Disk I/O - TAR-based storage, ext4 tuning, RAID WriteBack cache; (3) Database - innodb_buffer_pool_size formula: shared servers = (RAM - VoIPmonitor - OS) / 2, dedicated = 50-70% RAM. Capacity: ~10,000 calls with full RTP, 60,000+ SIP-only. Component separation for >5,000 calls: MySQL/Sensor/GUI on separate hosts. Monitor t0CPU and SQLq in syslog.
 
'''Keywords:''' scaling, performance, bottleneck, t0CPU, SQLq, TPACKET_V3, DPDK, PF_RING, Napatech, ethtool, ring buffer, interrupt coalescing, interface_ip_filter, pcap_dump_writethreads, jitterbuffer, innodb_buffer_pool_size, OOM, database partitioning, component separation, three host architecture, dedicated MySQL, remote database


'''Key Questions:'''
'''Key Questions:'''
* How do I scale VoIPmonitor for thousands of concurrent calls?
* How do I scale VoIPmonitor for thousands of concurrent calls?
* What are the main performance bottlenecks in VoIPmonitor?
* What are the main performance bottlenecks?
* How do I fix high t0CPU usage?
* How do I fix high t0CPU usage?
* What is DPDK and when should I use it?
* What is DPDK and when should I use it?
* How do I calculate innodb_buffer_pool_size for a shared server?
* How do I calculate innodb_buffer_pool_size?
* What happens if innodb_buffer_pool_size is set too high?
* What causes "MariaDB connection refused" errors?
* What causes "MariaDB connection refused" errors in the GUI or sniffer?
* How do I deploy MySQL, GUI, and Sensor on separate servers?
* How do I fix GUI crashes due to MariaDB connection refused errors?
* How do I interpret syslog performance metrics?
* How do I troubleshoot database connection issues with MariaDB?
* How much RAM does VoIPmonitor need?
* How do I interpret the performance metrics in syslog?
* Should I use a dedicated database server for VoIPmonitor?
* How much RAM does a VoIPmonitor server need?
* How can the slow query log affect memory utilization?
* How do I disable or adjust the MySQL slow query log?
* Is interface_ip_filter more efficient than the filter option?
* How do I optimize PCAP compression threads for high traffic?
* Which jitterbuffer settings affect CPU load the most?
* What configuration options reduce CPU overhead?
* How do I deploy VoIPmonitor with MySQL, GUI, and Sensor on separate servers?
* When should I use component separation architecture for VoIPmonitor?
* What is the three host architecture for VoIPmonitor scaling?
* How do I configure the GUI to connect to a remote MySQL database?
* How do I configure sensors to write to a remote MySQL server?
* What are the advantages of separating VoIPmonitor components onto different hosts?
* How do I scale the MySQL database independently from sensors and GUI?
* How do I scale the GUI independently from database and sensors?
* What is the difference between component separation and client-server mode?
* Can I combine component separation with client-server mode for VoIPmonitor?
* How do I configure firewall rules for component separation architecture?
* When should I use a dedicated GUI server for VoIPmonitor?

Latest revision as of 16:50, 8 January 2026


This guide covers performance tuning for high-traffic VoIPmonitor deployments, addressing the three primary system bottlenecks.

Understanding Performance Bottlenecks

A VoIPmonitor deployment's capacity is limited by three potential bottlenecks:

Bottleneck Description Monitor
1. Packet Capture Single CPU core reading packets from NIC t0CPU in syslog
2. Disk I/O Writing PCAP files to storage iostat, ioping
3. Database CDR ingestion and GUI queries SQLq in syslog

Capacity: A modern server (24-core Xeon, 10Gbit NIC) can handle ~10,000 concurrent calls with full RTP recording, or 60,000+ with SIP-only analysis.

Optimizing Packet Capture (CPU & Network)

The packet capture thread (t0) runs on a single CPU core. If t0CPU approaches 100%, you've hit the capture limit.

Prerequisites

  • Linux kernel 3.2+ with TPACKET_V3 support
  • Latest VoIPmonitor static binary

With a modern kernel and VoIPmonitor build, a standard Intel 10Gbit NIC handles up to 2 Gbit/s VoIP traffic without special drivers.

NIC Tuning (>500 Mbit/s)

# Increase ring buffer (prevents packet loss during CPU spikes)
ethtool -g eth0                  # Check max size
ethtool -G eth0 rx 16384         # Set to max

# Enable interrupt coalescing (reduces CPU overhead)
ethtool -C eth0 rx-usecs 1022

Persistent settings (Debian/Ubuntu /etc/network/interfaces): 

auto eth0
iface eth0 inet manual
    up ip link set $IFACE up
    up ip link set $IFACE promisc on
    up ethtool -G $IFACE rx 16384
    up ethtool -C $IFACE rx-usecs 1022

Configuration Optimizations

Parameter Purpose Recommendation
interface_ip_filter IP-based filtering More efficient than BPF filter
pcap_dump_writethreads_max Compression threads Set to CPU core count
jitterbuffer_f1/f2/adapt Jitter simulation Disable to save CPU (loses MOS metrics) 
# /etc/voipmonitor.conf

# Efficient IP filtering (replaces BPF filter)
interface_ip_filter = 192.168.0.0/24
interface_ip_filter = 10.0.0.0/8

# Compression scaling
pcap_dump_writethreads = 1
pcap_dump_writethreads_max = 32
pcap_dump_asyncwrite = yes

⚠️ Warning: Disabling jitterbuffer_* removes MOS/jitter metrics. Only disable if you don't need quality monitoring.

Kernel-Bypass Solutions

For extreme loads, bypass the kernel network stack entirely:

Solution Type CPU Reduction Use Case
DPDK Open-source ~70% Multi-gigabit on commodity hardware
PF_RING ZC Commercial 90% → 20% High-volume enterprise
Napatech SmartNICs Hardware <3% at 10Gbit/s Extreme performance

Optimizing Disk I/O

VoIPmonitor Storage Strategy

VoIPmonitor groups all calls starting within the same minute into a single compressed .tar archive. This changes thousands of random writes into few sequential writes, reducing IOPS by 10x+.

Typical capacity: 7200 RPM SATA handles ~2,000 concurrent calls with full recording.

Filesystem Tuning (ext4)

# Format without journal (requires battery-backed RAID)
mke2fs -t ext4 -O ^has_journal /dev/sda2

# /etc/fstab
/dev/sda2  /var/spool/voipmonitor  ext4  errors=remount-ro,noatime,data=writeback,barrier=0  0 0

⚠️ Warning: Disabling journal removes crash protection. Only use with battery-backed RAID controller (BBU).

RAID Controller

Set cache policy to WriteBack (not WriteThrough). Requires healthy BBU. Commands vary by vendor (megacli, ssacli, perccli).

Optimizing Database Performance

Memory Configuration

The most critical parameter is innodb_buffer_pool_size.

⚠️ Warning: Setting too high causes OOM killer events, CDR delays, and crashes. See OOM Troubleshooting.

Buffer Pool Sizing:

Server Type Formula Example (32GB RAM)
Shared (VoIPmonitor + MySQL) (Total RAM - VoIPmonitor - OS) / 2 14GB
Dedicated MySQL server 50-70% of total RAM 20-22GB

RAM Recommendations:

Deployment Size Minimum Recommended
Small (<500 calls) 8GB 16GB
Medium (500-2000) 16GB 32GB
Large (>2000) 32GB 64GB+

Key MySQL Parameters

# /etc/mysql/my.cnf or mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 14G
innodb_flush_log_at_trx_commit = 2  # Faster, minimal data loss risk
innodb_file_per_table = 1           # Essential for partitioning
innodb_compression_algorithm = lz4  # MariaDB only

Slow Query Log

The slow query log can consume significant memory. Consider disabling on high-traffic systems: 

[mysqld]
slow_query_log = 0
# Or increase threshold: long_query_time = 600

Database Partitioning

VoIPmonitor automatically partitions large tables (like cdr) by day. This is enabled by default and highly recommended.

See Database Partitioning for details.

Troubleshooting: Connection Refused

Symptoms: GUI crashes, "Connection refused" errors, intermittent issues during peak volumes.

Cause: innodb_buffer_pool_size too low (default 128M is insufficient).

Solution: Increase to 6G+ based on available RAM: 

[mysqld]
innodb_buffer_pool_size = 6G

systemctl restart mariadb

Component Separation (Multi-Host Architecture)

For deployments exceeding 5,000-10,000 concurrent calls, separate VoIPmonitor components onto dedicated hosts.

Architecture Overview

Host Component Primary Resources Scaling Strategy
Host 1 MySQL Database RAM, fast SSD Add RAM, read replicas
Host 2 Sensor(s) CPU (t0 thread), network DPDK/PF_RING, more sensors
Host 3 GUI CPU, network Load balancer, caching

Configuration

MySQL Server: 

# /etc/mysql/my.cnf
[mysqld]
bind-address = 0.0.0.0
innodb_buffer_pool_size = 50G  # 50-70% RAM for dedicated server

CREATE USER 'voipmonitor'@'%' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON voipmonitor.* TO 'voipmonitor'@'%';

Sensor: 

# /etc/voipmonitor.conf
id_sensor = 1
mysqlhost = mysql.server.ip
mysqldb = voipmonitor
mysqlusername = voipmonitor
mysqlpassword = strong_password

GUI: Configure via Settings > System Configuration > Database, or edit config/system_configuration.php.

Firewall Rules:

Source Destination Port Purpose
Sensor MySQL 3306 CDR writes
GUI MySQL 3306 Queries
GUI Sensor(s) 5029 PCAP retrieval
Users GUI 80, 443 Web access

ℹ️ Note: Component separation can be combined with Client-Server mode for multi-site deployments.

Monitoring Performance

VoIPmonitor logs metrics every 10 seconds: 

tail -f /var/log/syslog | grep voipmonitor

Sample output: 

calls[315][355] PS[C:4 S:29 R:6354] SQLq[0] heap[0|0|0] t0CPU[5.2%] RSS/VSZ[323|752]MB
Metric Description Warning Sign
calls[X][Y] Active / total calls in memory -
SQLq[N] SQL queries queued Growing = DB bottleneck
B|C] Buffer usage % A=100% = packet drops
t0CPU[X%] Capture thread CPU >90% = limit reached
Y] Memory usage (MB) RSS growing = leak

See Also

AI Summary for RAG

Summary: VoIPmonitor scaling guide covering three bottlenecks: (1) Packet Capture - use TPACKET_V3, NIC tuning (ethtool ring buffer/interrupt coalescing), interface_ip_filter instead of BPF, kernel-bypass (DPDK, PF_RING, Napatech); (2) Disk I/O - TAR-based storage, ext4 tuning, RAID WriteBack cache; (3) Database - innodb_buffer_pool_size formula: shared servers = (RAM - VoIPmonitor - OS) / 2, dedicated = 50-70% RAM. Capacity: ~10,000 calls with full RTP, 60,000+ SIP-only. Component separation for >5,000 calls: MySQL/Sensor/GUI on separate hosts. Monitor t0CPU and SQLq in syslog.

Keywords: scaling, performance, bottleneck, t0CPU, SQLq, TPACKET_V3, DPDK, PF_RING, Napatech, ethtool, ring buffer, interrupt coalescing, interface_ip_filter, pcap_dump_writethreads, jitterbuffer, innodb_buffer_pool_size, OOM, database partitioning, component separation, three host architecture, dedicated MySQL, remote database

Key Questions:

  • How do I scale VoIPmonitor for thousands of concurrent calls?
  • What are the main performance bottlenecks?
  • How do I fix high t0CPU usage?
  • What is DPDK and when should I use it?
  • How do I calculate innodb_buffer_pool_size?
  • What causes "MariaDB connection refused" errors?
  • How do I deploy MySQL, GUI, and Sensor on separate servers?
  • How do I interpret syslog performance metrics?
  • How much RAM does VoIPmonitor need?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Scaling&oldid=10174"