Hardware
hardware sizing examples
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.
High-Performance example: 17000 concurrent calls peak
network throughput ~2.8Gbit
hardware
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
200 concurrent calls
hardware
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
voipmonitor.conf
savesip = yes savertp = yes pcap_dump_zip_rtp = lzo (default RTP LZO compression)
CPU used
voipmonitor process
~88% (1 cpu cores)
= mysql process
~2%
memory used
~298MB for voipmonitor process
disk usage
mysql
30 days - 7.5GB
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)
voipmonitor.conf
savesip = yes savertp = yes pcap_dump_zip_rtp = lzo (default RTP LZO compression)
CPU used
= voipmonitor process
~22% (1 cpu core)
= mysql process
<1%
memory used
~75MB for voipmonitor process
disk usage
= mysql
Estimated ~2GB per month
Space estimation
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
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
To compare CPU performance, use benchmarking websites such as cpuBenchmark.net. Look for CPUs with single-core scores equal to or higher than the Intel Xeon E5520 (approximately 1400-1500 mark in benchmarks).
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
Always conduct real-world testing to validate performance, especially 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, 11000 concurrent calls, 12000 concurrent calls, 13000 concurrent calls, 14000 concurrent calls, 15000 concurrent calls, 10Gbit network, innodb_buffer_pool_size 80-96GB, split architecture