Optimizing FreeSWITCH for 5000+ Concurrent Calls
Going Beyond "Out of the Box"
A default FreeSWITCH installation is great for a small office, but if you throw 5,000 concurrent calls (CC) at it, it will choke. The audio will stutter, registration (REG) storms will crash the database, and the kernel will run out of file descriptors.
Here is the tuning checklist I use for high-volume production servers.
1. Linux Kernel Tuning
The operating system limits are your first bottleneck. You need to raise the limits for open files and network backlog.
# /etc/sysctl.conf
fs.file-max = 1000000
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.netdev_max_backlog = 5000
Without increasing netdev_max_backlog, your NIC won't process incoming UDP packets fast enough during a spike, causing dropped calls.
2. FreeSWITCH Core Parameters
In switch.conf.xml, you must specifically tell FreeSWITCH to expect a heavy load.
- max-sessions: Set this to at least 10,000 for a 5k target (always have headroom).
- sessions-per-second: Cap this to avoid crushing the CPU. 30-50 is usually safe; higher requires more cores.
3. Database Performance (SQLite vs. PostgreSQL)
By default, FreeSWITCH uses SQLite files for core session tracking. At 5,000 calls, the disk I/O lock contention on these files is massive.
Move to PostgreSQL (or MariaDB) immediately. Configure the core-db-dsn to point to a properly tuned IP-based SQL server. Even better, run the DB in RAM (tmpfs) if persistence isn't critical for core state, though proper SSDs usually suffice.
4. RTP Timer and Interrupts
Ensure your kernel timer is accurate. I recommend using 1000Hz timer frequency in your kernel build if possible, though modern kernels are mostly "tickless". Check unmasking interrupts on your NIC to specific CPUs to prevent CPU 0 saturation.