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;
thread = Thread::getThread("CycleManager::cycleManager");
// Only sleep if there is nothing to do.
if ( recordVersionPurgatory || recordPurgatory
|| valuePurgatory || bufferPurgatory)
cycleSleepTime = MIN_CYCLE_SLEEP;
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))
> 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.