最近用对完成端口做的服务器程序做压力测试，发现服务器的内存慢慢减少：（

2006-04-23 09:49:22 688 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

客户端用asynselect，一收到服务器的消息就立即发送数据给服务器。中间没有暂停，此时服务器的内存会慢慢减少。如果客户端暂停发送与接收，服务器的内存又会慢慢增加，再接着发送数据服务器的内存又慢慢减少。
请问为什么服务器会产生这样的问题？该如何解决。

...全文

判断素数_Python判断一个数是否为素数素数的定义：一个数如果只能被1和自身整除，则该数为素数。如果用编程的思维思考，则是说，如果一个数被比它小的数（1除外）整除后余数为0，则说明这个数可以被其他数整除，则该数为合数，否则该数为质数。Python代码如下:注释：①range()的起始值应该设为2，如果起始值设为1，则会第一次打印说该数是合数。运行结果如下：可见代码功能基本实现，但是打印了5次相同内容，这是因为每次i从range中取一次值... 阅读详情

LittleStar

网络通信/分布式开发 1,594 成员 32,944 内容

+ 关注 + 加入社区

切换为时间正序

leaber 2006-04-29

打赏
举报

竟然写错了，异步每次投递一个请求都是要分配新的内存的应该是每一个新的连接都是要分配新的内存块。

leaber 2006-04-29

打赏
举报

CPU占用率高吗？异步每次投递一个请求都是要分配新的内存的，如果没及时发送还会发生内存锁定的情况。查一下，只要没有内存泄露就好了。

另，不知道你是否开内存池？频繁的创建内存块会产生内存碎片的，然后稳定性就是个问题了。

constantine 2006-04-29

打赏
举报

学习一下，不太会，只看过一下

LittleStar 2006-04-25

打赏
举报

哎，不清楚怎么写。
昨晚又做了一个简单的wasAsynSelect的客户端进行测试。服务器端是最简单的iocp server。发现连续不断的测试，并没有导致服务器端的内存减少。看来要好好调试一下原来的服务器端程序了。
客户端用send recv连续发送和接收，过一段时间就会堆栈溢出。后来换成wsasend wsarecv就再也不会出现堆栈溢出。

飞天揽月 2006-04-24

打赏
举报

不错，学习！！！

bluesky23 2006-04-24

打赏
举报

shadowfish 2006-04-24

打赏
举报

关注中，最近也在研究完成端口

clasj 2006-04-24

打赏
举报

我觉得你找到的那篇文章说的已经很清楚了，你试过没有啊？

LittleStar 2006-04-24

打赏
举报

没人做iocp吗？

深宇 2006-04-23

打赏
举报

能否贴一些关键性的代码上来，不然别人怎么帮你解决问题呢？

LittleStar 2006-04-23

打赏
举报

搜了一下，发现有文章可能会有帮助，可是我对完成端口粗通皮毛。实在搞不清楚具体的实现方式。
（引自flashboy (爱写程序的小绵羊) ）
一、 WSAENOBUFS 错误问题。

这个问题通常很难靠直觉发现，因为当你第一次看见的时候你或许认为是一个内存泄露错误。假定已经开发完成了你的完成端口服务器并且运行的一切良好，但是当你对其进行压力测试的时候突然发现服务器被中止而不处理任何请求了，如果你运气好的话你会很快发现是因为WSAENOBUFS 错误而影响了这一切。

每当我们重叠提交一个send或receive操作的时候，其中指定的发送或接收缓冲区就被锁定了。当内存缓冲区被锁定后，将不能从物理内存进行分页。操作系统有一个锁定最大数的限制，一旦超过这个锁定的限制，那么就会产生WSAENOBUFS 错误了。

如果一个服务器提交了非常多的重叠的receive在每一个连接上，那么限制会随着连接数的增长而变化。如果一个服务器能够预先估计可能会产生的最大并发连接数，服务器可以投递一个使用零缓冲区的receive在每一个连接上。因为当你提交操作没有缓冲区时，那么也不会存在内存被锁定了。使用这种办法后，当你的receive操作事件完成返回时，该socket底层缓冲区的数据会原封不动的还在其中而没有被读取到receive操作的缓冲区来。此时，服务器可以简单的调用非阻塞式的recv将存在socket缓冲区中的数据全部读出来，一直到recv返回 WSAEWOULDBLOCK 为止。

这种设计非常适合那些可以牺牲数据吞吐量而换取巨大并发连接数的服务器。当然，你也需要意识到如何让客户端的行为尽量避免对服务器造成影响。在上一个例子中，当一个零缓冲区的receive操作被返回后使用一个非阻塞的recv去读取socket缓冲区中的数据，如果服务器此时可预计到将会有爆发的数据流，那么可以考虑此时投递一个或者多个receive来取代非阻塞的recv来进行数据接收。（这比你使用1个缺省的8K缓冲区来接收要好的多。）

总结：

解决方法一：

投递使用空缓冲区的 recevie操作，当操作返回后，使用非阻塞的recv来进行真实数据的读取。因此在完成端口的每一个连接中需要使用一个循环的操作来不断的来提交空缓冲区的receive操作。

解决方法二：

在投递几个普通含有缓冲区的recevie操作后，进接着开始循环投递一个空缓冲区的recevie操作。这样保证它们按照投递顺序依次返回，这样我们就总能对被锁定的内存进行解锁。

最近用对完成端口做的服务器程序做压力测试，发现服务器的内存慢慢减少：（

相关推荐