It could be a driver bug *if* your talking about a few connections with low message rates (sub 100 connections with message rates of < 5/sec). This specifically references high message rates (> 80000/sec) and/or large numbers of virtual connections (>10000). Under these circumstances with packet sizes being anywhere from 128 to 4k in size and being sent over slow lines (generally 9600 baud and slower), message buffering can easily use up memory.
Besides, the same streams drivers on Solaris, QNX, and other OS's don't have this problem. It is specifically a problem on linux that is a direct result of linux's kernel memory release policy. The point is, that people should be aware that this occurs on linux and could explain strange problems with suddenly not being able to aquire memory.
Either way, this really isn't the place for this discussion and I'll no longer post replies for this thread.
Simon Kenyon wrote:
On Tuesday 11 January 2005 15:57, Michael J. Lynch wrote:
Except from whitepaper:
This poses a problem for anyone wanting to use Linux as a communications
server handling a large number of connections or queueing a large number
of messages. The reason is that calling the kernel memory allocator
from a STREAMS driver will not cause disk buffers to be released to
satisfy the allocation request. Thus, if memory is nearly full of disk
buffers and the like there is only a small amount of memory left for
control blocks and messages.
sounds like a bug in the driver to me -- simon _______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
-- Michael J. Lynch
What if the hokey pokey IS what it's all about -- author unknown
_______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
