From: Kevin Lewis
Date: April 15 2009 9:49pm
Subject: Re: CycleManager suggestion
List-Archive: http://lists.mysql.com/falcon/690
Message-Id: <49E6567E.2040700@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 7BIT

Jim,  I'll take that as a definite maybe.

If things are really busy, rollbacks can keep committed older records 
from being pruned because they put detached record pointing back to the 
commited records onto recordVersionPurgatory.  Having shorter cycles 
will help scavenging be more responsive.  And I think that most of the 
time for the CycleManager thread will still be waiting for the shared 
locks to clear.

Maybe I should also decrease the sleep time after a no-sleep cycle.
Then after a shorter time, increase the sleep time until the next 
no-sleep cycle.  Something like this...

static const int MAX_CYCLE_SLEEP		= 2000;
static const int MIN_CYCLE_SLEEP		= 200;
static const int CYCLE_SLEEP_INCREMENT		= 200;

void CycleManager::cycleManager(void)
{
    thread = Thread::getThread("CycleManager::cycleManager");

    while (!thread->shutdownInProgress)
       {
       // Only sleep if there is nothing to do.
       if (   recordVersionPurgatory || recordPurgatory
           || valuePurgatory || bufferPurgatory)
          cycleSleepTime = MIN_CYCLE_SLEEP;
       else
          {
          thread->sleep(cycleSleepTime);

          if (cycleSleepTime < MAX_CYCLE_SLEEP)
             cycleSleepTime += CYCLE_SLEEP_INCREMENT;
          }



Jim Starkey wrote:
> Kevin Lewis wrote:
>> Jim, Do you think this is a good idea to do in the CycleManager?
>>        while (!thread->shutdownInProgress)
>>       {
>> +     // Only sleep if there is nothing to do.
>> +     if (!(recordVersionPurgatory || recordPurgatory ||
>> +           valuePurgatory || bufferPurgatory))
>>         thread->sleep(CYCLE_SLEEP);
>>
> Beats me.  In one case you speed time sleeping, in the other you spend 
> time waiting for the locks to go away.  I suppose your scheme would get 
> memory released sooner, which isn't a bad thing.
>