epoll 注册事件的时候,一个tcp占用多少内存

qixiang2013

已于 2023-03-24 10:31:07 修改

阅读量984

点赞数

分类专栏：服务端 c linux 文章标签：服务器 Powered by 金山文档

于 2023-02-20 10:37:41 首次发布

本文链接：https://blog.csdn.net/qixiang2013/article/details/129119408

版权

c 同时被 3 个专栏收录

18 篇文章 0 订阅

订阅专栏

服务端

11 篇文章 0 订阅

订阅专栏

linux

9 篇文章 0 订阅

订阅专栏

文章通过实验分析了TCP连接对服务器和客户端内存的影响，发现每个连接占用的内存远小于理论上的最小8KB。服务器端的内存消耗比客户端多，原因可能在于未及时读取缓冲区数据。同时，讨论了epoll事件注册对内存的影响以及如何根据内存计算服务器的最大并发连接数。

摘要由CSDN通过智能技术生成

maxevents 参数大小一般不超过64

必须够了 maxevents 个事件，才会传到用户空间吗？

可见，只要有事件就可以传到用户空间。

一台服务器可以支撑多少个链接

https://blog.csdn.net/mijichui2153/article/details/81331345

https://zhuanlan.zhihu.com/p/25241630#comment-254537238

0、两台虚拟机的初始状态如下：

服务端初始状态内存占用330.8M左右，剩余内存647.1M。

客户端初始状态内存占用350.4M左右，剩余内存627.5M。

服务端：

客户端：

1、开始建立TCP连接设定连接数为三万。

建立三万个连接，经过测试确实是吃内存的。

1.1、一万个连接的时候

10000个连接的时候服务端内存消耗：647.1-576.6=70.5M。

10000个连接的时候客户端内存消耗：627.5-588.6=38.0M。（考虑截图误差人为减了0.9）

1.2三万个连接的时候

30000个连接的时候服务端消耗了：647.1-433.0=214.1M

30000个连接的时候客户端消耗了：627.5-500.4=127.1M

之后这个数据保持的相当稳定。

2、分析：

0、根据测试结果计算出来的内存占用如下：

服务端：214.1M=219238.4KB；每个连接占用内存=219238.4KB/30000=7.31KB

客户端：127.1M=130150.4KB；每个连接占用内存=130150.4KB/30000=4.34KB

这个数靠谱吗？？验证如下

我们知道一个TCP连接主要内存消耗为文件描述符、读缓冲、写缓冲。

1、服务端、客户端的读写缓冲区大小均如下：

cat /proc/sys/net/ipv4/tcp_rmem

4096 4096 16777216 #TCP读缓存大小，单位是字节：第一个是最小值4K，第二个是默认值85K，第三个是最大值16M。

cat /proc/sys/net/ipv4/tcp_wmem

4096 4096 16777216 #TCP写缓存大小，单位是字节：第一个是最小值4K，第二个是默认值64K，第三个是最大值16M。

也就是说一个TCP在三次握手建立连接后，最小的内存消耗在8K左右，最大的内存消耗在32M左右。（注：这是错的）

然后问题就来了，为毛客户端我算出来的每个TCP连接只有4.34k，即时是服务端也只有7.31k而已？？？？

1.1难道是建立的TCP连接数不对？验证之

netstat -nat|grep -i "12345"|wc -l %12345为端口号

结果如下是服务端30001个、客户端30000个：

看来连接数不存在问题，确实是3万个TCP连接。

1.2、实在想不到原因了只能怀疑网上说的最低8K了。

果然：目光再次转向了陈硕大神在知乎上的一篇帖子。陈硕大神贴

“8K论”说法错误的原因在于 TCP 连接在建立时并不会真的去分配接收缓冲区和发送缓冲区，此时只有socket文件描述符占用内存，一个socket大约3k。3K具体怎么来的可以参考上面陈硕的那个链接。

对于接收缓冲区和发送缓冲区，如果没有数据，是不占内存的。具体来说，对于接收缓冲区，只有当有数据可读但应用程序尚未读取的时候才占内存（就是 epoll_wait 返回 EPOLL_IN之后，程序调用 read() 之前的那一小段时间）。换句话说，只要服务器总是及时读取数据，接收缓冲区基本不占内存。对于发送缓冲区，只有等待发送的数据和发送之后尚未收到 ACK 的数据才占用内存，在稳态下，发送缓冲区占用的内存等于 BDP。

1.3、至此为什么小于8K的问题解决了。那为什么服务端TCP连接占用的内存比客户端多很多呢？？？？

说到这儿就要结合上一段话和之前的 CPU占用率和Load Average区别的文章。

我们知道在我们之前的压力测试中性能瓶颈来源于服务端的CPU，具体来说是CPU的Load Average大于1，导致的较多待处理task排队。在结合上一段陈硕的话“对于接收缓冲区，只有当有数据可读但应用程序尚未读取的时候才占内存（就是 epoll_wait 返回 EPOLL_IN之后，程序调用 read() 之前的那一小段时间）”。所以接受端平均内存占用达到7.31K的原因应该就是因为应用程序并没有每次都立刻读取缓冲区中的数据。从而导致缓冲区确实占用了部分内存的情况。

1.4.注册一个epoll事件会占用内存空间吗？

按照epoll的实现机制事件是注册到内核事件表的，这个表应该是由红黑树实现的。按照《Linux高性能服务器编程》的说法一个事件会消耗160字节的内核空间。也就是说这个事件对象的本身占用的应该不是内存空间，当然epoll_wait的调用和返回可能会占用一些内存空间。

在说一遍：读缓存是一个动态变化的、实际用到多少才分配多少的缓冲内存，当这个连接非常空闲时，且用户进程已经把连接上接收到的数据都消费了，那么读缓存使用内存就是0。写缓存也是同样道理。... 因此，写缓存也是动态变化的，空闲的正常连接上，写缓存所用内存通常也为0。”

https://blog.csdn.net/mijichui2153/article/details/81331345