企业官网建设流程全解析

链接如下：

https://github.com/kamailio/kamailio/issues/4777

找 AI 解读了一下，质量很高，分享如下

这段对话讨论的是 Kamailio 在运行一段时间后反复出现 TLS 相关错误：

tls: ssl bug #1491 workaround: not enough memory for safe operation

核心结论是：Kamailio 的共享内存 shm 配置太小，运行 60-90 天后共享内存逐渐被消耗到低于 TLS 模块认为安全的阈值，导致新的 TLS 连接被拒绝。重启后共享内存释放，所以暂时恢复。

1. 这个问题现象是什么？

用户ddas-rt报告：

• 使用 Kamailio 6.0.3；
• 启动参数是：

-m256-M32

其中通常：

• -m 256表示 shared memory，共享内存 256 MB；
• -M 32表示 private/pkg memory，每个进程私有内存 32 MB。

问题表现为：

• Kamailio 运行 60-90 天后开始报错；
• 一旦报错，新的 TLS 连接全部失败；
• SIP over TLS 的新呼叫、新转接都无法建立；
• 已经存在的 TLS 连接似乎不受影响；
• 每次有新的 TLS 连接尝试，就会打印一次错误；
• 重启 Kamailio 后问题消失，但过 60-90 天又出现。

错误日志是：

ERROR: tls [tls_server.c:232]: tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=16536160 threshold1=17301504

2. 这条日志是什么意思？

关键部分：

not enough memory for safe operation shm=16536160 threshold1=17301504

意思是：

• 当前 Kamailio 可用共享内存只剩大约：

16536160 bytes ≈ 15.8 MB

• TLS 模块要求至少要有：

17301504 bytes ≈ 16.5 MB

• 当前剩余共享内存低于安全阈值，所以 TLS 模块拒绝继续建立新的 TLS 连接。

这个不是说系统内存不够。

机器上还有很多系统内存：

available 26Gi

但是 Kamailio 自己启动时只分配了 256 MB 的 shared memory。这个 256 MB 是 Kamailio 内部使用的内存池，不会因为系统还有 26GB 可用内存就自动变大。

3. 为什么重启后会恢复？

因为 Kamailio 重启后，内部的 shared memory 会重新初始化。

原来运行过程中被占用、碎片化或泄漏的共享内存都会被释放。于是 TLS 模块又能正常分配内存，新 TLS 连接恢复。

但如果根本原因是：

• shared memory 配置过小；
• 某些模块长期占用共享内存；
• 或者存在缓慢增长的内存泄漏/缓存增长；

那么运行一段时间后还是会再次耗尽，所以 60-90 天后复发。

4. maintainer 的回复是什么意思？

henningw最后回复：

Already tried to increase the shared memory? Probably 256MB is just too little. Increase to 512 or 1024 MB, you are having the memory on the system.

意思是：

你试过增加 shared memory 吗？256MB 可能太小了。你的机器内存很多，可以把 Kamailio 的 shared memory 增加到 512MB 或 1024MB。

也就是说，维护者认为目前最可能的原因是：

-m 256 设置太小

建议改成：

-m512

或者：

-m1024

5. 为什么日志里提到ssl bug #1491？

这个名字容易误导。

ssl bug #1491 workaround不是说 Kamailio 自己出现了某个编号为 1491 的 bug，而是 TLS/OpenSSL 相关历史问题的一个 workaround。

Kamailio TLS 模块里有一段保护逻辑：为了避免在共享内存不足时进入不安全状态，它会在可用 shm 低于某个阈值时拒绝新的 TLS 初始化。

所以真正触发原因是：

shared memory available too low

而不是单纯的 SSL 协议错误。

6. 为什么明明系统有 30GB 内存，还说 not enough memory？

因为这里的 memory 指的是 Kamailio 的 shared memory，不是 Linux 系统总体内存。

系统内存：

30Gi total 26Gi available

Kamailio shared memory：

-m256

也就是 Kamailio 只允许自己使用 256MB 共享内存池。

日志里说的是这个池快没了：

shm=16536160

剩余只有 16MB 左右。

所以不是服务器没内存，而是 Kamailio 的内部共享内存池太小。

7. 应该怎么处理？

首选方案：增大 shared memory

把 Kamailio 启动参数从：

-m256-M32

改成例如：

-m512-M32

或者：

-m1024-M32

如果机器内存充足，建议直接试：

-m1024

也就是给 Kamailio 1GB shared memory。

具体修改位置取决于部署方式，可能在：

/etc/default/kamailio

或 systemd service 文件：

/etc/systemd/system/kamailio.service

或启动脚本中。

修改后重启：

systemctl daemon-reload systemctl restart kamailio

8. 还应该继续检查什么？

虽然维护者建议先增大 shm，但这个问题每 60-90 天出现，也有可能说明存在缓慢的共享内存增长或泄漏。

建议观察 Kamailio 共享内存使用情况。

可以使用：

kamcmd core.shmmem

或者：

kamctl fifo get_statistics shmem:

看类似指标：

• total shared memory；
• used shared memory；
• free shared memory；
• real used memory；
• max used memory；
• fragments。

如果发现 shared memory 持续单调增长，不下降，那么可能还要查：

• dialog 模块是否保存太多 dialog；
• usrloc/location 表是否有过多注册；
• TLS 连接是否异常积累；
• htable 是否无限增长；
• dispatcher、tm、dialog、presence 等模块是否占用大量 shm；
• 是否有内存泄漏。

9. 对这段 issue 的整体解读

这个 issue 的实际意思是：

Kamailio 运行一段时间后，共享内存剩余量低于 TLS 模块安全阈值。TLS 模块为了规避 OpenSSL/SSL 相关 bug，不允许继续建立新的 TLS 连接，于是所有新的 SIP over TLS 连接失败。由于当前 Kamailio 只配置了 256MB shared memory，而服务器本身有大量空闲内存，所以建议将-m增加到 512MB 或 1024MB。

简单说：

不是 AWS 机器内存不够， 不是 TLS 证书问题， 也不是单纯网络问题， 而是 Kamailio shared memory 快耗尽。

最直接解决方案：

-m1024

然后持续监控 shared memory 使用趋势。