Hardware: Difference between revisions

From VoIPmonitor.org
(Add 10000-15000 concurrent calls hardware recommendations - recommends separate database and sensor hosts with 128GB+ RAM, 32-64 CPU cores, NVMe SSD for DB, 10Gbit/s NIC, SATA/SAS acceptable for PCAP with TAR archiving)
(Review: přidán architektonický diagram, Note/Tip šablony pro lepší vizualizaci)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
= hardware sizing examples =
= Hardware Sizing Examples =


== 17000 concurrent calls peak ==
This page provides real-world hardware sizing examples for VoIPmonitor deployments at various scales, from 50 to 17000+ concurrent calls.


network throughput ~2.8Gbit
== 10000-15000 Concurrent Calls (Very High Load) ==


=== hardware ===
'''Recommended for: 10000, 11000, 12000, 13000, 14000, or 15000 concurrent calls'''
2x Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
Intel 82599ES 10-Gigabit SFI/SFP+
 
=== voipmonitor.conf ===
savesip = yes
savertp = yes
pcap_dump_zip_rtp = lzo (default RTP LZO compression)
 
 
=== CPU used ===
==== voipmonitor process ====
~1300% (13 cpu cores)
 
 
==== mysql process ====
~300% (3 cpu cores)
 
=== memory used ===
~7000MB for voipmonitor process
 
=== disk usage ===
==== mysql ====
90 days - 1.5TB
 
==== spool pcap ====
 
8 days RTP+SIP - 21TB
 
== 10000-15000 concurrent calls (very high load) ==


'''Recommended Architecture:''' Split database and traffic processing onto separate dedicated hosts.
'''Recommended Architecture:''' Split database and traffic processing onto separate dedicated hosts.
Line 46: Line 17:
| '''CPU''' || 32-64 CPU cores (AMD EPYC or Dual Intel Xeon Gold/Silver)
| '''CPU''' || 32-64 CPU cores (AMD EPYC or Dual Intel Xeon Gold/Silver)
|-
|-
| '''RAM''' || 128GB to 256GB (using all memory channels)
| '''RAM''' || 128GB to 256GB (using all memory channels). For 128GB RAM, set <code>innodb_buffer_pool_size</code> to 80-96GB.
|-
|-
| '''Storage''' || High-performance NVMe SSD array for database
| '''Storage''' || High-performance NVMe SSD array for database
Line 68: Line 39:
|}
|}


'''Note:''' For traffic exceeding 3Gbit/s, consider using [[DPDK]] or other kernel-bypass solutions.
{{Note|1=For traffic exceeding 3Gbit/s, consider using [[DPDK]] or other kernel-bypass solutions.}}
 
=== Architecture Diagram ===
 
<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 40}}}%%
flowchart TB
    subgraph SENSOR["Sensor Host (32-64 cores, 128GB RAM)"]
        S1[VoIPmonitor Sniffer]
        S2[PCAP Storage<br/>SATA/SAS]
    end
 
    subgraph DB["Database Host (32-64 cores, 128-256GB RAM)"]
        D1[MySQL/MariaDB]
        D2[NVMe SSD Storage]
    end
 
    NET[Network Traffic<br/>10Gbit+] --> S1
    S1 --> S2
    S1 -->|CDR Data| D1
    D1 --> D2
</kroki>
 
== High-Performance Example: 17000 Concurrent Calls Peak ==
 
{| class="wikitable"
|-
! Parameter !! Value
|-
| '''Network Throughput''' || ~2.8 Gbit/s
|-
| '''CPU''' || 2x Intel Xeon E5-2650 v2 @ 2.60GHz
|-
| '''Network Card''' || Intel 82599ES 10-Gigabit SFI/SFP+
|}


== 200 concurrent calls ==
=== Configuration ===


=== hardware ===
<syntaxhighlight lang="ini">
savesip = yes
savertp = yes
pcap_dump_zip_rtp = lzo
</syntaxhighlight>


Intel(R) Xeon(R) CPU          E5520  @ 2.27GHz
=== Resource Usage ===


=== voipmonitor.conf ===
{| class="wikitable"
|-
! Resource !! Usage
|-
| '''VoIPmonitor CPU''' || ~1300% (13 CPU cores)
|-
| '''MySQL CPU''' || ~300% (3 CPU cores)
|-
| '''VoIPmonitor Memory''' || ~7000 MB
|}


savesip = yes
=== Disk Usage ===
savertp = yes
pcap_dump_zip_rtp = lzo (default RTP LZO compression)


=== CPU used ===
{| class="wikitable"
|-
! Data Type !! Retention !! Size
|-
| MySQL CDR || 90 days || 1.5 TB
|-
| Spool PCAP (RTP+SIP) || 8 days || 21 TB
|}


==== voipmonitor process ====
== 200 Concurrent Calls ==
~88% (1 cpu cores)


=== Hardware ===


==== mysql process ===
{| class="wikitable"
~2%
|-
! Component !! Specification
|-
| '''CPU''' || Intel Xeon E5520 @ 2.27GHz
|}


=== Configuration ===


=== memory used ===
<syntaxhighlight lang="ini">
~298MB for voipmonitor process
savesip = yes
savertp = yes
pcap_dump_zip_rtp = lzo
</syntaxhighlight>


=== Resource Usage ===


=== disk usage ===
{| class="wikitable"
|-
! Resource !! Usage
|-
| '''VoIPmonitor CPU''' || ~88% (1 CPU core)
|-
| '''MySQL CPU''' || ~2%
|-
| '''VoIPmonitor Memory''' || ~298 MB
|}


==== mysql ====
=== Disk Usage ===


30 days - 7.5GB
{| class="wikitable"
|-
! Data Type !! Retention !! Size
|-
| MySQL CDR || 30 days || 7.5 GB
|}


== 50 concurrent calls ==
== 50 Concurrent Calls ==


=== hardware ===
=== Hardware ===


Modern CPU with single-core performance equal to or greater than Intel Xeon E5520 @ 2.27GHz
Modern CPU with single-core performance equal to or greater than Intel Xeon E5520 @ 2.27GHz.


Examples that would be suitable:
Examples that would be suitable:
Line 113: Line 159:
* Raspberry Pi 5 (for low-power deployments - requires real-world testing)
* Raspberry Pi 5 (for low-power deployments - requires real-world testing)


=== voipmonitor.conf ===
=== Configuration ===


savesip = yes
<syntaxhighlight lang="ini">
savertp = yes
savesip = yes
pcap_dump_zip_rtp = lzo (default RTP LZO compression)
savertp = yes
pcap_dump_zip_rtp = lzo
</syntaxhighlight>


=== CPU used ===
=== Resource Usage ===


==== voipmonitor process ===
{| class="wikitable"
~22% (1 cpu core)
|-
! Resource !! Usage
|-
| '''VoIPmonitor CPU''' || ~22% (1 CPU core)
|-
| '''MySQL CPU''' || <1%
|-
| '''VoIPmonitor Memory''' || ~75 MB
|}


=== Disk Usage ===


==== mysql process ===
{| class="wikitable"
<1%
|-
 
! Data Type !! Retention !! Size
|-
| MySQL CDR || 30 days || ~2 GB
|}


=== memory used ===
= Space Estimation =
~75MB for voipmonitor process


== Spooldir Size (PCAP Records) ==


=== disk usage ===
With default compression settings:
* '''1 MB/minute''' for 2 RTP streams (1 leg with G.711 codec)
* '''2 MB/minute''' for 2 legs per call (SIP + RTP + flow charts)


==== mysql ===
== CDR Space for MySQL ==
Estimated ~2GB per month


= Space estimation =
For database you can estimate approximately '''2 KB per CDR record''' with default table compression enabled (<code>mysqlcompress = yes</code> in <code>/etc/voipmonitor.conf</code>).
== spooldir size - space for packets records ==
with default compression settings of voipmonitor you can count aprox 1MB/1minute of 2RTP streams (1 leg with g711 codec), if you have 2legs per call you can count aprox 2MB/1minute of record (SIP+RTP+flow charts)
== CDR space for mysql's datadir ==
For database you can count very aprox. 2KB per CDR record with default table compression enabled (default mysqlcompress = yes in /etc/voipmonitor.conf)


= Practical Storage Capacity Estimation =
= Practical Storage Capacity Estimation =
Line 148: Line 205:
For accurate storage planning, run a representative capture to measure actual usage in your environment.
For accurate storage planning, run a representative capture to measure actual usage in your environment.


=== Step 1: Run Full Capture for One Week ===
== Step 1: Run Full Capture for One Week ==


Run VoIPmonitor in full capture mode for at least one week to capture a representative sample of your actual traffic patterns. This accounts for:
Run VoIPmonitor in full capture mode for at least one week to capture a representative sample of your actual traffic patterns. This accounts for:
Line 156: Line 213:
* Call duration distribution
* Call duration distribution


=== Step 2: Check Total Spool Directory Size ===
== Step 2: Check Total Spool Directory Size ==


After the capture period, check the total storage used:
After the capture period, check the total storage used:
Line 165: Line 222:


Example output:
Example output:
<pre>
<syntaxhighlight lang="text">
524G    /var/spool/voipmonitor
524G    /var/spool/voipmonitor
</pre>
</syntaxhighlight>


=== Step 3: Analyze Per-Day Usage ===
== Step 3: Analyze Per-Day Usage ==


Check storage usage by day to identify patterns and calculate daily average:
Check storage usage by day to identify patterns and calculate daily average:
Line 178: Line 235:


Example output:
Example output:
<pre>
<syntaxhighlight lang="text">
75G    /var/spool/voipmonitor/2025-01-04
75G    /var/spool/voipmonitor/2025-01-04
82G    /var/spool/voipmonitor/2025-01-05
82G    /var/spool/voipmonitor/2025-01-05
Line 186: Line 243:
85G    /var/spool/voipmonitor/2025-01-09
85G    /var/spool/voipmonitor/2025-01-09
93G    /var/spool/voipmonitor/2025-01-10
93G    /var/spool/voipmonitor/2025-01-10
</pre>
</syntaxhighlight>


Calculate the average: 524GB &divide; 7 days = ~75GB/day
Calculate the average: 524GB ÷ 7 days = ~75GB/day


=== Step 4: Project Future Storage Needs ===
== Step 4: Project Future Storage Needs ==


Use the average daily usage to calculate required storage capacity:
Use the average daily usage to calculate required storage capacity:


<syntaxhighlight lang="bash">
<syntaxhighlight lang="text">
# Formula: Average daily usage × Retention days = Total storage needed
# Formula: Average daily usage × Retention days = Total storage needed
75GB/day × 30 days = 2.25TB
75GB/day × 30 days = 2.25TB
Line 212: Line 269:
The '200 concurrent calls' example uses an Intel Xeon E5520 @ 2.27GHz, which consumed ~88% of one CPU core. You can use this as a baseline to calculate CPU requirements:
The '200 concurrent calls' example uses an Intel Xeon E5520 @ 2.27GHz, which consumed ~88% of one CPU core. You can use this as a baseline to calculate CPU requirements:


* '''50 concurrent calls ~22% of one core''' - Suitable for low-end hardware, Raspberry Pi 5, or virtual machines
* '''50 concurrent calls (~22% of one core)''' - Suitable for low-end hardware, Raspberry Pi 5, or virtual machines
* '''200 concurrent calls ~88% of one core''' - Suitable for mid-range hardware
* '''200 concurrent calls (~88% of one core)''' - Suitable for mid-range hardware
* '''17000 concurrent calls ~13 cores''' - Requires multi-socket server hardware
* '''17000 concurrent calls (~13 cores)''' - Requires multi-socket server hardware


=== Single vs. Dual Socket ===
=== Single vs. Dual Socket ===
Line 221: Line 278:
* '''Dual socket''' - Ensure at least 4 memory channels per CPU for acceptable performance
* '''Dual socket''' - Ensure at least 4 memory channels per CPU for acceptable performance


To compare CPU performance, use benchmarking websites such as [https://www.cpubenchmark.net cpuBenchmark.net]. Look for CPUs with single-core scores equal to or higher than the Intel Xeon E5520 (approximately 1400-1500 mark in benchmarks).
{{Tip|To compare CPU performance, use [https://www.cpubenchmark.net cpuBenchmark.net]. Look for CPUs with single-core scores equal to or higher than Intel Xeon E5520 (~1400-1500 mark).}}


=== Supported CPU Families ===
=== Supported CPU Families ===
Line 239: Line 296:
* '''Storage Type:''' SSDs (Solid State Drives)
* '''Storage Type:''' SSDs (Solid State Drives)
* '''Minimum Capacity:''' 4TB
* '''Minimum Capacity:''' 4TB
* '''Requirements''' - High I/O throughput and low latency for database operations
* '''Requirements:''' High I/O throughput and low latency for database operations


=== PCAP File Storage ===
=== PCAP File Storage ===
Line 249: Line 306:
** 3.5" 7200rpm SATA drives
** 3.5" 7200rpm SATA drives
** SAS 2.5" drives
** SAS 2.5" drives
* '''Capacity''' - Calculate based on your retention policy using the practical estimation method above
* '''Capacity:''' Calculate based on your retention policy using the practical estimation method above


=== General Guidelines ===
=== General Guidelines ===


* '''SSD Recommended''' for database and high-performance deployments
* '''SSD Recommended''' for database and high-performance deployments
* '''7200 RPM SATA HDD''' Can handle up to 2,000 concurrent calls according to real-world testing
* '''7200 RPM SATA HDD''' can handle up to 2,000 concurrent calls according to real-world testing
* '''Storage Capacity''' - Calculate based on your retention policy using the formula: 2MB/minute per call × number of concurrent calls × hours per day × retention days
* '''Storage Capacity''' - Calculate based on your retention policy using the formula: 2MB/minute per call × number of concurrent calls × hours per day × retention days


Line 264: Line 321:
== Testing Your Deployment ==
== Testing Your Deployment ==


Always conduct real-world testing to validate performance, especially when:
{{Tip|1=Always conduct real-world testing to validate performance before deploying in production.}}
 
Testing is especially important when:
* Using less powerful hardware (e.g., Raspberry Pi 5)
* Using less powerful hardware (e.g., Raspberry Pi 5)
* Deploying in virtualized environments
* Deploying in virtualized environments
Line 280: Line 339:


== AI Summary for RAG ==
== AI Summary for RAG ==
'''Summary:''' This page contains real-world hardware sizing examples for VoIPmonitor deployments at various scales (50, 200, 10000-15000, 17000 concurrent calls), including CPU, memory, disk usage, and configuration details. The 10000-15000 concurrent calls example recommends splitting database and traffic processing onto separate dedicated hosts: Database Host with 32-64 CPU cores, 128GB-256GB RAM, and NVMe SSD; Sensor Host with 32-64 CPU cores, 128GB RAM, and 10Gbit/s NIC. It provides practical storage capacity estimation using a one-week capture method with du commands, hardware selection guidelines (single vs dual socket, AMD EPYC support), storage recommendations (4TB minimum SSD for database, magnetic drives for PCAP), and hardware performance comparison guidance.


'''Keywords:''' hardware, cpu, memory, disk, sizing, performance, storage, capacity, concurrent calls, rtp, sip, compression, lzo, i/o, network, ssd, hdd, raspberry pi, cpubenchmark, amd epyc, dual socket, single socket, storage estimation, du command, daily usage, high volume, database host, sensor host, separate hosts, nvme, 128GB, 256GB, 10000 concurrent calls, 12000 concurrent calls, 15000 concurrent calls, 10Gbit network
'''Summary:''' This page provides real-world hardware sizing examples for VoIPmonitor deployments at various scales (50, 200, 10000-15000, 17000 concurrent calls). The PRIMARY reference section is "10000-15000 concurrent calls" which applies to 10000, 11000, 12000, 13000, 14000, and 15000 concurrent calls. This section RECOMMENDS splitting architecture: Database Host needs 32-64 CPU cores, 128GB-256GB RAM (with innodb_buffer_pool_size set to 80-96GB for 128GB RAM), and NVMe SSD; Sensor Host needs 32-64 CPU cores, 128GB RAM, 10Gbit/s NIC, with SATA/SAS drives acceptable for PCAP storage (SSD recommended). For traffic exceeding 3Gbit/s, use DPDK. The page also includes storage capacity estimation (du command method), hardware selection guidelines (single vs dual socket, AMD EPYC support), storage recommendations (4TB SSD for database minimum), and the 17000 concurrent call benchmark showing ~13 cores used by voipmonitor and ~3 cores by MySQL.
 
'''Keywords:''' hardware, cpu, memory, disk, sizing, performance, storage, capacity, concurrent calls, rtp, sip, compression, lzo, i/o, network, ssd, hdd, raspberry pi, cpubenchmark, amd epyc, dual socket, single socket, storage estimation, du command, daily usage, high volume, database host, sensor host, separate hosts, nvme, 128GB, 256GB, 10000 concurrent calls, 10Gbit network, innodb_buffer_pool_size, split architecture, DPDK
 
'''Key Questions:'''
* What hardware do I need for 10000+ concurrent calls?
* What are the recommended CPU and RAM specifications for high-volume VoIPmonitor deployments?
* Should I use SSD or HDD for VoIPmonitor storage?
* How much disk space does VoIPmonitor need per day?
* How do I estimate storage requirements for VoIPmonitor?
* What is the recommended architecture for large-scale VoIPmonitor deployment?
* Does VoIPmonitor support AMD EPYC processors?
* What network bandwidth is required for VoIPmonitor?
* How many CPU cores does VoIPmonitor use at 17000 concurrent calls?
* What is the recommended innodb_buffer_pool_size for VoIPmonitor database?

Latest revision as of 18:00, 6 January 2026

Hardware Sizing Examples

This page provides real-world hardware sizing examples for VoIPmonitor deployments at various scales, from 50 to 17000+ concurrent calls.

10000-15000 Concurrent Calls (Very High Load)

Recommended for: 10000, 11000, 12000, 13000, 14000, or 15000 concurrent calls

Recommended Architecture: Split database and traffic processing onto separate dedicated hosts.

Database Host

Component Specification
CPU 32-64 CPU cores (AMD EPYC or Dual Intel Xeon Gold/Silver)
RAM 128GB to 256GB (using all memory channels). For 128GB RAM, set innodb_buffer_pool_size to 80-96GB.
Storage High-performance NVMe SSD array for database
Network 10Gbit/s or better

Sensor Host

Component Specification
CPU 32 or 64 CPU cores (AMD EPYC or Dual Intel Xeon Gold/Silver)
RAM 128GB (utilizing all memory channels)
Network 10Gbit/s network interface card
PCAP Storage Standard SATA/SAS drives acceptable (TAR archiving reduces IOPS); SSD recommended for best performance

ℹ️ Note: For traffic exceeding 3Gbit/s, consider using DPDK or other kernel-bypass solutions.

Architecture Diagram

High-Performance Example: 17000 Concurrent Calls Peak

Parameter Value
Network Throughput ~2.8 Gbit/s
CPU 2x Intel Xeon E5-2650 v2 @ 2.60GHz
Network Card Intel 82599ES 10-Gigabit SFI/SFP+

Configuration

savesip = yes
savertp = yes
pcap_dump_zip_rtp = lzo

Resource Usage

Resource Usage
VoIPmonitor CPU ~1300% (13 CPU cores)
MySQL CPU ~300% (3 CPU cores)
VoIPmonitor Memory ~7000 MB

Disk Usage

Data Type Retention Size
MySQL CDR 90 days 1.5 TB
Spool PCAP (RTP+SIP) 8 days 21 TB

200 Concurrent Calls

Hardware

Component Specification
CPU Intel Xeon E5520 @ 2.27GHz

Configuration

savesip = yes
savertp = yes
pcap_dump_zip_rtp = lzo

Resource Usage

Resource Usage
VoIPmonitor CPU ~88% (1 CPU core)
MySQL CPU ~2%
VoIPmonitor Memory ~298 MB

Disk Usage

Data Type Retention Size
MySQL CDR 30 days 7.5 GB

50 Concurrent Calls

Hardware

Modern CPU with single-core performance equal to or greater than Intel Xeon E5520 @ 2.27GHz.

Examples that would be suitable:

  • Intel Core i3 or better (modern generations)
  • AMD Ryzen 3 or better
  • Raspberry Pi 5 (for low-power deployments - requires real-world testing)

Configuration

savesip = yes
savertp = yes
pcap_dump_zip_rtp = lzo

Resource Usage

Resource Usage
VoIPmonitor CPU ~22% (1 CPU core)
MySQL CPU <1%
VoIPmonitor Memory ~75 MB

Disk Usage

Data Type Retention Size
MySQL CDR 30 days ~2 GB

Space Estimation

Spooldir Size (PCAP Records)

With default compression settings:

  • 1 MB/minute for 2 RTP streams (1 leg with G.711 codec)
  • 2 MB/minute for 2 legs per call (SIP + RTP + flow charts)

CDR Space for MySQL

For database you can estimate approximately 2 KB per CDR record with default table compression enabled (mysqlcompress = yes in /etc/voipmonitor.conf).

Practical Storage Capacity Estimation

For accurate storage planning, run a representative capture to measure actual usage in your environment.

Step 1: Run Full Capture for One Week

Run VoIPmonitor in full capture mode for at least one week to capture a representative sample of your actual traffic patterns. This accounts for:

  • Peak vs. off-peak hours
  • Weekday vs. weekend traffic
  • Typical codec usage (G.711, G.729, Opus, etc.)
  • Call duration distribution

Step 2: Check Total Spool Directory Size

After the capture period, check the total storage used: 

du -hs /var/spool/voipmonitor

Example output: 

524G    /var/spool/voipmonitor

Step 3: Analyze Per-Day Usage

Check storage usage by day to identify patterns and calculate daily average: 

du -h --max-depth=1 /var/spool/voipmonitor | sort -k2,2

Example output: 

75G     /var/spool/voipmonitor/2025-01-04
82G     /var/spool/voipmonitor/2025-01-05
68G     /var/spool/voipmonitor/2025-01-06
42G     /var/spool/voipmonitor/2025-01-07 (Sunday - lower traffic)
79G     /var/spool/voipmonitor/2025-01-08
85G     /var/spool/voipmonitor/2025-01-09
93G     /var/spool/voipmonitor/2025-01-10

Calculate the average: 524GB ÷ 7 days = ~75GB/day

Step 4: Project Future Storage Needs

Use the average daily usage to calculate required storage capacity: 

# Formula: Average daily usage × Retention days = Total storage needed
75GB/day × 30 days = 2.25TB
75GB/day × 90 days = 6.75TB

Add buffer for growth:

  • Add 20-30% buffer for future traffic increase
  • Account for additional compression ratios if configured

Hardware Selection Guidelines

When selecting hardware for your VoIPmonitor deployment, use the performance baseline examples above as reference points and scale accordingly.

CPU Selection

The '200 concurrent calls' example uses an Intel Xeon E5520 @ 2.27GHz, which consumed ~88% of one CPU core. You can use this as a baseline to calculate CPU requirements:

  • 50 concurrent calls (~22% of one core) - Suitable for low-end hardware, Raspberry Pi 5, or virtual machines
  • 200 concurrent calls (~88% of one core) - Suitable for mid-range hardware
  • 17000 concurrent calls (~13 cores) - Requires multi-socket server hardware

Single vs. Dual Socket

  • Single socket (preferred) - Higher memory throughput and lower latency
  • Dual socket - Ensure at least 4 memory channels per CPU for acceptable performance

💡 Tip: To compare CPU performance, use cpuBenchmark.net. Look for CPUs with single-core scores equal to or higher than Intel Xeon E5520 (~1400-1500 mark).

Supported CPU Families

VoIPmonitor supports a wide range of CPU architectures and families:

  • Intel
  • AMD - AMD EPYC servers are fully supported and recommended for high-performance deployments
  • ARM - Raspberry Pi 5 and other ARM-based platforms (test thoroughly for production use)

Storage Selection

Proper storage selection is critical for VoIPmonitor performance. Use different storage types for different data types:

Database Storage

  • Storage Type: SSDs (Solid State Drives)
  • Minimum Capacity: 4TB
  • Requirements: High I/O throughput and low latency for database operations

PCAP File Storage

PCAP files can be stored on magnetic drives to reduce costs:

  • Storage Type: Magnetic (hard disk drives)
  • Recommended Options:
    • 3.5" 7200rpm SATA drives
    • SAS 2.5" drives
  • Capacity: Calculate based on your retention policy using the practical estimation method above

General Guidelines

  • SSD Recommended for database and high-performance deployments
  • 7200 RPM SATA HDD can handle up to 2,000 concurrent calls according to real-world testing
  • Storage Capacity - Calculate based on your retention policy using the formula: 2MB/minute per call × number of concurrent calls × hours per day × retention days

Network Requirements

  • 1 Gbit/s - Sufficient for deployments up to ~2,000 concurrent calls
  • 10 Gbit/s - Recommended for higher volumes or when using mirroring/multiple sensors

Testing Your Deployment

💡 Tip: Always conduct real-world testing to validate performance before deploying in production.

Testing is especially important when:

  • Using less powerful hardware (e.g., Raspberry Pi 5)
  • Deploying in virtualized environments
  • Running additional services on the same server

Monitor the following metrics during testing:

  • CPU usage: <80% per core at peak load
  • Memory usage: No swap usage
  • Disk I/O: Queue depth should remain low
  • Network bandwidth: Should not saturate interface

Additional Resources

See Scaling for more detailed performance tuning and optimization guidance.

AI Summary for RAG

Summary: This page provides real-world hardware sizing examples for VoIPmonitor deployments at various scales (50, 200, 10000-15000, 17000 concurrent calls). The PRIMARY reference section is "10000-15000 concurrent calls" which applies to 10000, 11000, 12000, 13000, 14000, and 15000 concurrent calls. This section RECOMMENDS splitting architecture: Database Host needs 32-64 CPU cores, 128GB-256GB RAM (with innodb_buffer_pool_size set to 80-96GB for 128GB RAM), and NVMe SSD; Sensor Host needs 32-64 CPU cores, 128GB RAM, 10Gbit/s NIC, with SATA/SAS drives acceptable for PCAP storage (SSD recommended). For traffic exceeding 3Gbit/s, use DPDK. The page also includes storage capacity estimation (du command method), hardware selection guidelines (single vs dual socket, AMD EPYC support), storage recommendations (4TB SSD for database minimum), and the 17000 concurrent call benchmark showing ~13 cores used by voipmonitor and ~3 cores by MySQL.

Keywords: hardware, cpu, memory, disk, sizing, performance, storage, capacity, concurrent calls, rtp, sip, compression, lzo, i/o, network, ssd, hdd, raspberry pi, cpubenchmark, amd epyc, dual socket, single socket, storage estimation, du command, daily usage, high volume, database host, sensor host, separate hosts, nvme, 128GB, 256GB, 10000 concurrent calls, 10Gbit network, innodb_buffer_pool_size, split architecture, DPDK

Key Questions:

  • What hardware do I need for 10000+ concurrent calls?
  • What are the recommended CPU and RAM specifications for high-volume VoIPmonitor deployments?
  • Should I use SSD or HDD for VoIPmonitor storage?
  • How much disk space does VoIPmonitor need per day?
  • How do I estimate storage requirements for VoIPmonitor?
  • What is the recommended architecture for large-scale VoIPmonitor deployment?
  • Does VoIPmonitor support AMD EPYC processors?
  • What network bandwidth is required for VoIPmonitor?
  • How many CPU cores does VoIPmonitor use at 17000 concurrent calls?
  • What is the recommended innodb_buffer_pool_size for VoIPmonitor database?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Hardware&oldid=9055"