So I implemented this feature and tested a bit.
It is ok for memory growth. And reducing the pool size is painlessly
possible till a definite value.
After that changing the size (expectedly) causes deadlocks and segfaults.
Here the real work begins, to make it stable.
On Tue, Feb 9, 2010 at 3:26 PM, Rob Wultsch <wultsch@stripped> wrote:
> On Mon, Feb 8, 2010 at 12:12 PM, Rick James <rjames@stripped> wrote:
>> I'm curious -- what will you do with the RAM you take away from InnoDB's
>> buffer pool? (In a dedicated MySQL server, I seen no reason to alter the
> // I have not read the code.
> I think the use case would generally be growing the buffer pool.
> Off the top of my head I see several reason:
> 1. Non-dedicated servers which were started without a buffer pool
> parameter. 8MB ain't much and downtime sucks.
> 2.Dedicated servers with multiple instances of MySQL.Keeping some RAM
> in reserve that can be allocated to an instance that is acting up
> ain't a bad thing.
> 3.Dedicated servers which have under allocated ram to the buffer pool
> or grown to a point where the value is underallocated. This is not a
> bad thing. See http://bugs.mysql.com/bug.php?id=29847 .
> However, lets say on a dedicate server the buffer pool has been over
> allocated and the server is swapping. Being able to free() memory and
> getting out of swap would be quite useful.
> Rob Wultsch