遇到“TCP: out of memory”日志，需先排查连接堆积、慢速攻击或应用未及时收包/关连接等根因，再按需合理调整tcp_mem三元组及配套参数，避免盲目调大加剧OOM。
遇到 TCP: out of memory -- consider tuning tcp_mem 内核日志，说明内核 TCP 缓冲区内存分配失败，不是简单调大就完事。需按顺序排查根本原因，避免掩盖真实问题。
确认是否真缺内存（而非瞬时抖动）
该警告常被误读为系统内存不足，其实它只反映 内核为 TCP socket 分配接收/发送缓冲区时，在当前 tcp_mem 限制下无法满足单次申请，和整体可用内存关系不大。
- 运行
cat /proc/net/sockstat，重点看sockets: used和TCP: inuse是否持续高位（如数万以上），同时memory值接近或达到/proc/sys/net/ipv4/tcp_mem的第三个值 - 用
ss -mni抽样几个活跃连接，观察rcv_ssthresh、rmem_alloc、wmem_alloc是否异常偏高（如几百 MB） - 检查
dmesg -T | grep -i "out of memory"是否伴随其他 OOM 相关日志（如 page allocation failure），若有，优先处理整体内存压力
检查是否存在连接堆积或异常流量
tcp_mem 被耗尽，90% 情况源于应用层未及时收包、连接未释放，或遭受慢速攻击（如 Slowloris）。
Audio Upload Aioz Stream Free
下载
基于 AIOZ Stream API 的免费音频上传技能，通过三步流程（Create → Upload Part → Complete）将本地音频文件上传至 AIOZ 流媒体平台。支持默认快速上传方式，使用默认编码配置，上传完成后返回 HLS 流媒体播放链接。使用 API Key (stream-publ...)进行认证。
- 执行
ss -tan state established | wc -l和ss -tan state syn-recv | wc -l，对比正常基线；SYN_RECV 过多可能遭遇 SYN Flood - 用
ss -tan state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10查看连接最多的客户端 IP，结合业务判断是否异常 - 检查应用日志：是否有大量 read timeout、connection reset、或长时间未 close socket 的痕迹（如 Java 应用忘记调用
InputStream.close()）
合理调整 tcp_mem（仅在确认是配置不合理时）
tcp_mem 是三元组：min pressure max，单位为页（通常 4KB）。调整必须保持逻辑关系：min ≤ pressure ≤ max，且 pressure 应设为预期峰值缓冲区用量的 1.2~1.5 倍。
- 先估算：假设平均每个连接缓冲区占用 256KB，峰值连接数 10000，则总需求约 2.5GB → 对应页数 ≈ 2.5 * 1024 * 1024 / 4 ≈ 655360 页；建议设为
131072 262144 786432 - 临时生效：
sysctl -w net.ipv4.tcp_mem="131072 262144 786432" - 永久生效：写入
/etc/sysctl.conf，并运行sysctl -p - ⚠️ 注意：盲目将 max 设得过大（如超物理内存 30%）会导致内核过度保留内存，反而加剧其他子系统 OOM
同步优化配套参数与应用行为
单调 tcp_mem 治标不治本，需配合调整降低单连接内存占用、加快连接回收。
- 减小默认缓冲区：
sysctl -w net.ipv4.tcp_rmem="4096 16384 393216"，net.ipv4.tcp_wmem="4096 16384 393216"（第三个值不宜超过 tcp_mem[2] 的 1/2） - 加速 TIME-WAIT 回收（仅当确认无 NAT 问题时）：
sysctl -w net.ipv4.tcp_tw_reuse=1，net.ipv4.tcp_fin_timeout=30 - 应用层务必启用 keepalive（如 Nginx 的
keepalive_timeout，Java 的Socket.setKeepAlive(true)），并确保业务逻辑显式关闭空闲连接
