山东住房和城乡建设部网站,昆明网站建设要多少钱,啥叫优化,公司要怎么注册maxevents 参数大小一般不超过64必须够了 maxevents 个事件#xff0c;才会传到用户空间吗#xff1f;可见#xff0c;只要有事件就可以传到用户空间。一台服务器可以支撑多少个链接https://blog.csdn.net/mijichui2153/article/details/81331345 0、两台虚拟机的初始状态如…maxevents 参数大小一般不超过64必须够了 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.670.5M。10000个连接的时候客户端内存消耗627.5-588.638.0M。考虑截图误差人为减了0.91.2三万个连接的时候30000个连接的时候服务端消耗了647.1-433.0214.1M30000个连接的时候客户端消耗了627.5-500.4127.1M之后这个数据保持的相当稳定。2、分析0、根据测试结果计算出来的内存占用如下服务端214.1M219238.4KB每个连接占用内存219238.4KB/300007.31KB客户端127.1M130150.4KB每个连接占用内存130150.4KB/300004.34KB这个数靠谱吗验证如下我们知道一个TCP连接主要内存消耗为文件描述符、读缓冲、写缓冲。1、服务端、客户端的读写缓冲区大小均如下cat /proc/sys/net/ipv4/tcp_rmem 4096 4096 16777216 #TCP读缓存大小单位是字节第一个是最小值4K第二个是默认值85K第三个是最大值16M。cat /proc/sys/net/ipv4/tcp_wmem4096 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/81331345C/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以下:一个连接的内存消耗是444416K4G/16K26.2万并发假如网络包的大小都可以控制在8K以下, 假设所有连接的网络都不会拥堵, 或者拥堵时候的总量在8K以下一个socket的内存占用介于 24K ~ 32K之间, 保守的按照32K算 4G/32K13.1万并发, 这个在生产环境作为一个纯网络层面的内存消耗, 是可以作为参考的.假如使用默认配置, 假如所有连接的网络都出现严重拥堵, 不考虑逻辑上的发送队列的占用,使用默认配置是2M2M88 ~ 4M4G/4M1024并发 ( …如果考虑到发送队列也拥堵的话 自己脑补.如果只是为了跑分 为了并发而优化, 没有常驻的逻辑缓冲区 并且socket的网络吞吐量很小并且负载平滑, 把socket buffer size设置系统最低.那么是4G/8K 52.4万并发 这个应该是极限值了.
