I saw a new "chunk" concept was introduced in innodb buffer pool in
mysql-5.5 version, from the comment it is used to resize the buffer
pool. So I think innodb team have been working on this feature
On Tue, Feb 9, 2010 at 11:19 PM, Elena Kasyanova <degifter@stripped> wrote:
> 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.
> Thanks, Elena
> 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
>> // 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
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?unsub=1