FreeRADIUS CPU占用100% 高并发下登录失败、radacct表重复问题排查

场景现状 #

已部署的FreeRADIUS服务器对接本地热点认证业务，平台覆盖约1000名可通过热点接入完成认证的用户。当活跃接入的热点用户规模超过400人时，会触发两类典型异常：

• 用户无法正常完成登录认证流程
• radacct计费表生成重复条目，直接导致统计的用户实际计费会话时长仅为真实值的一半
  当前约束：服务器长期面向在线用户提供服务，无法停机切换到debug模式开展故障排查，相关服务器与热点的运行状态可参考配套的运行截图

无业务中断的排障操作路径 #

无中断采集调试日志的操作 #

不需要把FreeRADIUS切到前台debug模式（这种模式会暂停服务，仅处理单连接请求，直接影响在线用户），直接通过配置热加载的方式开启调试日志即可：

• 找到对应版本的FreeRADIUS主配置文件radiusd.conf，将认证、计费模块的日志输出等级调整为调试级，执行systemctl reload freeradius让配置生效，全程不会中断现有在线用户的连接
• 仅在用户接入高峰时段开启调试日志，无需长期全量开启，避免高并发下日志写入占满磁盘IO，反而引发服务异常

两类异常的核心定位方向 #

高并发下认证失败的常见根因

• 系统资源配额不足：检查radiusd进程的文件句柄上限，默认ulimit配置下，单进程可打开的文件数若低于512，当活跃连接数超过阈值时，会直接出现新认证请求无法建立连接的失败问题，可通过命令cat /proc/$(pidof radiusd)/limits直接查看当前进程的句柄配额
• 内核接收队列溢出：检查配置文件中RADIUS监听端口段的recv_buff参数，默认值通常为64KB，高并发下请求堆积超过缓存上限时，系统会直接丢弃认证请求，表现为用户认证超时无响应

radacct重复条目生成的常见根因

• 网络层重传触发重复写入：热点侧的AC/AP设备在未收到FreeRADIUS返回的计费响应报文时，会触发计费报文重传机制。当FreeRADIUS负载过高未及时响应重传的计费开始报文时，会向数据库写入两条完全相同的会话记录
• 数据库约束缺失：radacct表若未将Acct-Session-ID设置为唯一索引，重复上报的计费报文会生成两条独立的会话记录，最终统计会话时长时，两个条目分摊完整的上线周期，表现为统计值仅为真实时长的一半

临时缓解措施 #

• 调整FreeRADIUS的并发处理能力：将配置中的max_servers参数从默认值4提升到16，可将单节点的并发处理上限提升至支撑800以上活跃接入的规模
• 从数据库层避免重复写入：执行SQL命令ALTER TABLE radacct ADD UNIQUE INDEX idx_acct_session (acctsessionid)，给radacct表补充Acct-Session-ID字段的唯一约束，杜绝重复会话条目

内容的提问来源于stack exchange，提问作者Evan TM