title: boost fast_pool_allocator sometimes requests a huge allocation
body: <p>I have a highly threaded application that uses boost's fast_pool_allocator (version 1.55) underneath <a href="https://github.com/quickfix/quickfix" rel="nofollow">quickfix</a> (1.13.3). The application allocates a large number of objects over the course of the day, growing more-or-less linearly until we shut it down, using on the order of 32G of virtual memory by the end of the day. Most allocations are on the order of 200MB as we watch the virtual memory footprint of the application grow. But then, at some point usually later in the day, boost decides to do a 6GB allocation, even though the flow of transactions through the application doesn't change materially.</p>
  
  <p>Looking at the allocator code, the first thing boost does after the allocation is set up the new block into chunks. The function is <code>simple_segregated_storage&lt;SizeType&gt;::segregate</code> at simple_segregated_storage.hpp:280. We've attached a debugger to the process, and observed that when the giant allocation happens, that function (unsurprisingly) takes a long time to execute, specifically the for loop at line 302. It takes as long as 20-30 seconds, and that code is mutex protected so every other thread trying to do anything in the allocator blocks. This angers our customers.</p>
  
  <p>Questions:</p>
  
  <ol>
  <li>Why would it suddenly alloc 6GB when it had been constantly asking for ~200MB blocks all day prior to that?</li>
  <li>Can the allocation be capped somehow? I'd rather have it ask for smaller pieces more often.</li>
  <li>Is this the wrong allocator? I suppose that's a question for the quickfix developers, but this appears to be their preferred way to go. The objects that use the allocator are mostly <code>std::map</code> and <code>std::multimap</code>.</li>
  </ol>