Re: [boost] asio queue OOM stress test -- Windows deadlock

From: Bardur Arantsson (spam_at_[hidden])
Date: 2005-12-16 18:25:27

christopher baus wrote:
>>template <typename Allocator = std::allocator<void> >
[--snip--]
> If I had the limits at construction, I could allocate the necessary
> internal structures when the demuxer is instantiated.  I think this the
> right thing to do for server applications because if the admin configures
> a server to handle n number of connections I want to make my best attempt
> to handle those connections.  If the system doesn't have enough resources
> I think the admin should know about it at startup.
> 
> This allocation strategy should probably be policy based, because for
> clients allocating from the heap is more appropriate.
> 
> I wrote a bit more about this a while back here:
> http://baus.net/memory-management

You're allocating + forcing initialization of memory at startup, yes?

As I understand it, the Linux OOM killer may *still* kill your 
application even if your application is "well behaved" (in the sense 
that it isn't actually responsible for the allocation that causes the 
OOM condition). It certainly doesn't always pick the application that 
caused the allocation failure.

The only reasonable thing to do is to turn off overcommit, or to add 
lots of swap and *pray* that your working set isn't larger than your 
physical memory.

Cheers,

-- 
Bardur Arantsson
<bardurREMOVE_at_[hidden]>
<bardurREMOVE_at_[hidden]>
Sticks and stones may break my bones, but hollow-points expand on
impact.