linux - Linux中套接字的内存消耗和压缩行为

Question

我们的系统的内存占用量逐渐增加。
在使用探查器进行过多调试之后，没有达到确切的问题点。
现在，在验证了系统上的随机事物之后，它就陷入了我们所使用的Web套接字中。
这些套接字在其队列中有很多未读消息。内存使用量与消息数量成正比。通过清除队列中的消息，可以回收大量内存。
问题:
经测试的操作系统版本:CentOS 7.5

我尝试使用'/proc/net/sockstat'检查套接字占用的内存
mem列显示内存为〜300mb

使用 netstat -tunp 测量的recv-Q〜6mb的总内存(将recv-Q中的数字视为字节)

但是，当我清理未读邮件时，我获得了约1.5gb的内存。 (使用 免费命令)
还有其他要检查的信息以获取套接字的正确内存使用情况吗？
这是Linux造成的不必要的内存使用吗？如何进一步调试套接字使用的内存？
为什么像 top 这样的Linux工具没有列出套接字的内存使用情况？它向我们显示了进程，缓存和缓冲区的内存，但是为什么没有套接字。
额外细节:
将内存分配器更改为jemalloc并没有阻止此内存增长。因此，这不是与glibc相关的问题。
================================================== ===============
编辑信息:使用测试应用程序做一些工作之后
将我们的问题转换成一个简单的测试程序，并在具有不同内核版本的服务器中运行了它。
测试程序:每分钟5000个套接字和4个传入消息(每个消息3个字节)。在使用ss -tm来清楚地了解缓冲区内存行为方面也做了一些工作。
机器1:内核:2.6.32
/proc/sys/net/core/rmem_max = 124928
开始时:免费内存:2.5gb
对于每个传入的消息，ss -tm中的mem每个套接字增加512字节。
在某些时候，套接字的内存使用量突然下降。
内存下降之前:

free -m : free memory: 1.1G

sockstat: TCP: inuse 6 orphan 1 tw 161 alloc 5265 mem 114138

ss -tm : mem:(r112784,w0,f1904,t0)

内存下降后:

free -m free memory: 2.3G

sockstat TCP: inuse 6 orphan 1 tw 157 alloc 5266 mem 8042

ss -tm mem:(r9528,w0,f952,t0)

recv-Q中的值随着期望值的增加而不断增加。
在这一点上，“r”值达到大约等于core/rmem_max
好像在那里发生了压实过程。
机器2:内核:3.10.0
/proc/sys/net/core/rmem_max = 212992
在这里，我预计内存将在〜212992下降。但是这台机器的升级版本为ss，其本身显示了rb = 367360的大小。因此，等待确切的压缩过程发生。
开始时:

ss -tm : skmem:(r0,rb367360,t0,tb87040,f53248,w0,o0,bl0)

sockstat: TCP: inuse 4 orphan 0 tw 97 alloc 5042 mem 4992

在这里，内存也在以预期的速度增长。在特定时间点内存下降。
在内存放置点1:
内存下降之前:

free : free memory: 2.1gb

sockstat : TCP: inuse 4 orphan 0 tw 89 alloc 5097 mem 354398

ss -tm : skmem:(r290560,rb367360,t0,tb87040,f256,w0,o0,bl0)

内存下降后:

free : free memory: 3.1gb

sockstat : TCP: inuse 4 orphan 0 tw 93 alloc 5099 mem 187542

coming to ss -tm, saw a different behavior this time:

50% of the sockets had compacted values,

skmem:(r4352,rb367360,t0,tb87040,f3840,w0,o0,bl0)

and the remaining had actual values (not compacted)

skmem:(r291072,rb367360,t0,tb87040,f3840,w0,o0,bl0)

因此紧缩发生在“r”值达到“rb”之前
接下来，等到“r”值达到“rb”
内存放置点2
那里发生了下一个内存下降点。压缩了所有套接字缓冲区(除了100个套接字)，并回收了巨大的内存。
================================================== ===============
现在，我的理解是:
我们在服务器中面临的实际问题是:内存占用量持续增长，并且机器开始使用交换空间，并且变慢了速度。现在，在运行测试程序之后，我了解到服务器的可用空间不足以容纳压缩点。
我的问题:

此压缩是套接字缓冲区的内置行为吗？

如果是的话，什么时候会发生，在机器2中，我的经验与在机器1中的经验不同？应该调整哪个值以尽早进行压实？

sockstat中的

“me​​m”值和ss中的“r”值之和加起来得出套接字占用的总内存吗？或者它们是由不同工具列出的相同值。

(根据我的测试，我看到(内存值sockstat + skmem缓冲区值)等于释放的内存。)

Answer 1

Is this compaction a inbuilt behavior of socket buffers?

是的.. tcp_collapse方法可以解决这个问题。为了容纳更多空间，它会将它们压缩。此折叠过程会带来CPU开销，因此应调整tcp参数以避免在正常情况下发生此过程。

Netstat -sn | grep'prune | collapse'给了我们no。折叠/修剪的数据包数量

If yes, when will that happen, in Machine 2, i had different experience than the one in machine 1? Which value should be tuned to bring the compaction early?

通常，这种崩溃是一个占用大量CPU的过程，Linux专家不希望这种情况提早发生。 tcp模块很少有 checkin 操作来延迟崩溃事件。如果存在修剪或折叠的数据包，则说明您的配置或应用逻辑中缺少某些内容。

手册页中解释了控制行为:
/proc/sys/net/core/rmem_max-为所有类型的套接字设置此设置(以页为单位)
/proc/sys/net/ipv4/tcp_rmem-帮助覆盖TCP套接字的限制(以页为单位)