问题现象
在进行网络性能测试或高并发业务运行期间，发现网络收发性能未达预期（如吞吐量受限、延迟增加）。
通过检查netstat -s命令的输出，发现 "packet pruned from receive queue because of socket buffer overrun" ：
$ netstat -s | grep "socket buffer overrun"
1617 packets pruned from receive queue because of socket buffer overrun问题原因
直接原因
当网络包到达的速度超过了应用程序从套接字接收缓冲区（Receive Buffer）读取数据的速度时，接收队列（Receive Queue）会逐渐填满。
内核行为
当前接收队列长度 + 当前收包大小 > 接收队列最大长度：
内存规整（Pruning/Collapsing）： Linux 内核会尝试对接收队列进行内存规整（例如合并小包、释放乱序包的元数据结构），以腾出空间接收新包。
性能影响： 规整操作消耗CPU资源，且如果规整后仍无空间，数据包将被丢弃，导致 TCP 重传，进而导致网络延迟增加和吞吐量下降。
根本原因
当前系统的套接字接收缓冲区配置（内核参数或应用设置）无法满足当前业务流量的突发需求或吞吐量需求。
解决方案
场景一：应用程序使用系统默认缓冲区
如果应用程序没有显式调用setsockopt(SO_RCVBUF) 设置缓冲区大小，Linux内核会根据tcp_rmem参数自动调节TCP接收窗口大小（Auto-tuning）。
调整方法：
调整 /proc/sys/net/ipv4/tcp_rmem 中的三个值（单位：字节）。这三个值分别代表：min（最小）、default（默认）、max（最大）。
查看当前值。
sysctl net.ipv4.tcp_rmem # 输出示例: 4096 87380 4194304 (分别为 4KB, 87KB, 4MB)适当增大max值（第三个数字），以允许内核在内存充足时分配更大的接收缓冲区。
# 示例：将最大值调整为16MB (具体数值请根据服务器内存和业务需求设定) sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"持久化配置（写入/etc/sysctl.conf）。
echo "net.ipv4.tcp_rmem = 4096 87380 16777216" >> /etc/sysctl.conf sysctl -p
场景二：应用程序手动设置了缓冲区 (setsockopt)
如果应用程序代码中调用了setsockopt(socket, SOL_SOCKET, SO_RCVBUF, ...)，则内核的自动调节机制（Auto-tuning）会被禁用，缓冲区大小将被固定。
方法一（推荐）：修改应用代码
移除代码中的 setsockopt(SO_RCVBUF) 调用，让内核接管缓冲区管理，从而利用内核高效的自动调节机制。方法二：增大应用设置的值 & 调整内核上限
如果应用程序必须手动设置，需在代码中增大设定的值。应用程序通过setsockopt设置的最大值受到内核参数net.core.rmem_max的限制。例如：应用申请1MB，但rmem_max只有256KB，实际只会分配256KB。因此，必须同步调整内核上限：# 查看当前上限 sysctl net.core.rmem_max # 调大上限 (例如调整为 16MB) sysctl -w net.core.rmem_max=16777216
验证修复
调整配置并重启应用程序（或重新建立连接）后，重新进行压力测试，并监控指标：
检查计数器是否停止增长：
watch -d "netstat -s | grep 'socket buffer overrun'"如果数值不再增加或增加频率大幅降低，说明调整有效。
观察业务性能：
确认网络吞吐量是否提升，延迟是否平稳。
注意事项
估算内存消耗：TCP接收缓冲区使用的是系统物理内存（非swap）。如果并发连接数非常多（如数万个），将缓冲区上限设置得过大可能导致系统耗尽内存，触发OOM Killer杀掉业务进程。
内存消耗估算：连接数 × 平均缓冲区大小。
应用读取开销：虽然较大的缓冲区可以减少丢包，但如果缓冲区远大于应用程序一次能读取的数据量，可能会造成内存浪费，且对缓存命中率有一定影响（尽管相比丢包，这个影响通常次要）。
生效范围
net.ipv4.tcp_rmem仅影响TCP套接字。
net.core.rmem_default和net.core.rmem_max影响所有类型的套接字（包括 UDP、Unix Domain Socket 等）。