FreeSWITCH 性能优化与调优实战（高并发场景）
在呼叫中心或大规模语音平台中，FreeSWITCH 的性能瓶颈通常不是单点，而是CPU、网络、线程模型、媒体处理链路 的综合结果。调优的核心目标是：降低延迟、提升并发、稳定长时间运行。
本文从硬件、网络、配置调优三个层面，给出可直接落地的优化策略。
一、硬件优化：决定性能上限
1. CPU：优先高主频 + 多核
FreeSWITCH 是多线程模型 + 实时处理，对 CPU 要求：
- 优先选择高主频（单核性能很关键）
- 多核用于并发通话分摊
- 避免低频多核（如某些云主机）
👉 推荐：
- Intel Xeon 高主频系列 / AMD EPYC
- 关闭 CPU 节能模式（避免频繁降频）
2. 内存：不是越大越好，而是要"够快"
- 建议 ≥ 16GB（中型系统）
- 大规模并发建议 32GB+
- 使用 DDR4/DDR5 高频内存
关键点：
- 避免 swap（交换内存会导致通话卡顿）
- 调整：
bash
vm.swappiness = 103. 磁盘：日志与录音分离
- 系统盘：SSD/NVMe
- 录音文件：独立磁盘或对象存储
- 避免 IO 阻塞影响 RTP
二、网络优化：决定通话质量
1. 网络延迟与抖动控制
语音对网络要求极高：
| 指标 | 建议值 |
|---|---|
| 延迟 | < 50ms |
| 抖动 | < 20ms |
| 丢包率 | < 1% |
2. 内核网络参数优化（Linux）
bash
# 增大缓冲区
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
# 提高队列
net.core.netdev_max_backlog = 5000
# 减少TIME_WAIT
net.ipv4.tcp_tw_reuse = 1应用：
bash
sysctl -p3. 网卡优化
- 启用多队列（multi-queue）
- 关闭不必要的 offload（某些场景 RTP 会受影响）
bash
ethtool -K eth0 gro off4. RTP 端口范围合理规划
xml
<param name="rtp-start-port" value="16384"/>
<param name="rtp-end-port" value="32768"/>避免：
- 端口过小 → 并发受限
- 端口冲突 → 丢包
三、FreeSWITCH 配置优化（核心）
1. SIP Profile 调优（mod_sofia）
限制最大并发
xml
<param name="max-sessions" value="2000"/>调整 SIP 线程
xml
<param name="inbound-late-negotiation" value="true"/>作用：
- 减少不必要的编解码协商
- 降低 CPU 开销
关闭无用功能
xml
<param name="enable-100rel" value="false"/>2. RTP 优化
开启 RTP 自动调整
xml
<param name="rtp-autoflush" value="true"/>调整 jitter buffer（抖动缓冲）
xml
<action application="set" data="jitterbuffer_msec=60"/>根据网络情况调整：
- 网络差 → 增大
- 网络好 → 减小（降低延迟）
3. 编解码优化（极其关键）
CPU 消耗排名（从高到低）：
G729 > OPUS > PCMU/PCMA建议：
- 内网：使用 PCMU/PCMA（无压缩，低CPU）
- 外网：使用 OPUS（平衡带宽与质量）
限制 codec：
xml
<param name="codec-prefs" value="PCMU,PCMA"/>👉 避免开启过多 codec（协商成本高）
4. 线程与调度优化
FreeSWITCH 使用线程池模型：
xml
<param name="core-db-pool-size" value="50"/>系统级优化：
bash
ulimit -n 200000避免：
- 文件描述符耗尽
- 连接失败
5. 关闭不必要模块（减少资源占用）
编辑：
conf/autoload_configs/modules.conf.xml关闭：
xml
<!-- <load module="mod_av"/> -->
<!-- <load module="mod_flite"/> -->
<!-- <load module="mod_python"/> -->👉 原则：只加载用到的模块
四、媒体处理优化（高阶）
1. 避免转码（最重要优化点）
转码 = CPU 杀手
优化策略：
- 统一 codec
- 网关侧处理转码
- FreeSWITCH 只做交换
2. 使用 bypass media
xml
<action application="set" data="bypass_media=true"/>效果：
- RTP 不经过 FreeSWITCH
- 直接点对点
👉 极大降低 CPU 和带宽压力
3. 使用 proxy media（折中方案）
xml
<action application="set" data="proxy_media=true"/>适用于：
- NAT 场景
- 需要控制 RTP 但不转码
五、数据库与缓存优化
1. 使用内存数据库（高性能场景）
xml
<param name="core-db-dsn" value="sqlite://:memory:"/>2. 外部数据库优化（如 PostgreSQL）
- 使用连接池
- 避免频繁查询
- 业务数据与核心信令分离
六、压测与容量规划
推荐工具
- sipp（标准 SIP 压测工具）
压测指标：
- CPS（Calls Per Second）
- 并发通话数
- 呼叫建立时延（PDD）
七、典型性能瓶颈分析
| 问题 | 原因 |
|---|---|
| CPU 100% | 转码 / codec 过多 |
| 通话卡顿 | 网络抖动 / buffer 设置不合理 |
| 呼叫失败 | 文件描述符不足 |
| 延迟高 | jitter buffer / 网络问题 |
八、生产级优化总结
核心原则：
- 减少转码（最关键）
- 控制模块数量
- 优化线程与文件句柄
- 网络优先级高于一切
- 尽量使用 bypass media
九、一个工程级结论
在大规模系统中：
FreeSWITCH 更适合做"信令交换 + 控制层"，而不是"重媒体处理节点"
如果你的架构是：
- ASR / TTS / LLM / 录音 / 转码
👉 建议拆分为：
- FreeSWITCH（信令层）
- Media Server（媒体处理）
- AI 服务层
结语
FreeSWITCH 的性能调优，本质是：
用架构解决问题，而不是只靠参数优化
如果你下一步要做：
- 分布式 FreeSWITCH 集群
- 万级并发呼叫中心
- ASR/LLM 融合实时语音系统