2010/9/13 Bret S. Lambert <bret.lamb...@gmail.com>: > yes, because you've soaked up all the memory that's available for > handling incoming/outgoing network traffic; you've got a bunch of > processes that try to grab a limited number of resources, fail to > get all they need, and sleep while holding already-allocated mbufs, > meaning that nobody else can get them, and none of your processes > can advance.
yes, I understand. but kernel must resolve this situation somehow. Isn't it? > That said, the pool_get that's failing in the re driver is set as > non-blocking, so it should fail. However, it's hard to see how > you're tickling this without seeing the source that you're running, > since we don't know how you're cornholing the network stack. oh, here is the source http://gist.github.com/576851 it is rather ugly, collected from pieces of another programs. my english is bad so I cut out my comments. I need the instrument to do a brief test of server under load. so this "penetrator" was planned as simply (yes, ugly but...) and quickly created instrument. -- antonvm
