epoll 笔记

1. maxevents 参数大小一般不超过64

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

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

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

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

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

C/C++ epoll内存计算方法，4G内存服务器epoll并发量最大能达到多少？

https://blog.csdn.net/u012206617/article/details/89304317

按照题主的意思 是根据内存去算一个最大并发的连接数. 那么首先要找出来单个连接消耗内存的地方.

第一个首先是socket buffer. read 和write 分别有一个, 默认大小在。

/proc/sys/net/ipv4/tcp_rmem (for read)

/proc/sys/net/ipv4/tcp_wmem (for write)

默认大小都是87K和16K, 最低是4K和4K, 最高是2M,2M, 实际使用默认值最低也要保留8K,8K.

然后是逻辑IO缓冲区

就是比如你监听了recv事件 事件来了 你要有内存可用(一般都是socket建立起就分配好,断开才会释放的).

这个内存是自己写socket程序时候自己控制的, 最低也要4K,4K, 实际使用8K,8K至少.

现在设定一个优化方案和使用场景, 首先假设4G内存全部为空闲(系统和其他进程也要内存的….

假如网络包的大小都可以控制在4K以下, 假设所有连接的网络都不会拥堵, 或者拥堵时候的总量在4K以下:

一个连接的内存消耗是4+4+4+4=16K

4G/16K=26.2万并发

假如网络包的大小都可以控制在8K以下, 假设所有连接的网络都不会拥堵, 或者拥堵时候的总量在8K以下

一个socket的内存占用介于 24K ~ 32K之间, 保守的按照32K算

4G/32K=13.1万并发, 这个在生产环境作为一个纯网络层面的内存消耗, 是可以作为参考的.

假如使用默认配置, 假如所有连接的网络都出现严重拥堵, 不考虑逻辑上的发送队列的占用,

使用默认配置是2M+2M+8+8 ~= 4M

4G/4M=1024并发 ( …

如果考虑到发送队列也拥堵的话 自己脑补.

如果只是为了跑分 为了并发而优化, 没有常驻的逻辑缓冲区 并且socket的网络吞吐量很小并且负载平滑, 把socket buffer size设置系统最低.

那么是

4G/8K = 52.4万并发 这个应该是极限值了.