[Glass] Fwd: [GLASS] Seaside - growing extent - normal?
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Wed Apr 8 08:50:45 PDT 2015
Yes, the one session that expired was the one that we had already
manually expired, so running again should expire the whole lot .. and if
not we'll need to dig deeper.
for some reason it appears that a certain collection of applications did
not have the expiration scan run against them at all ... like this
one)... the case that was supposed to show up "missing" is the most
likely explanation for such a phenomenon, but that was not the case with
the WASession that we looked at in detail ...
If the second run yields good results, I'd like to try a few more
experiments to try to characterize why we had these troubles, but it may
not be worth spending too much more time on this (your call) if we have
a formula for slashing the size of your repo...
Dale
On 4/8/15 7:51 AM, Lawrence Kellogg wrote:
> Answers below...
>
>
>> On Apr 8, 2015, at 10:34 AM, Lawrence Kellogg <mac.hive at me.com
>> <mailto:mac.hive at me.com>> wrote:
>>
>>
>>
>>
>>
>> Begin forwarded message:
>>
>>> *From:* Dale Henrichs <dale.henrichs at gemtalksystems.com
>>> <mailto:dale.henrichs at gemtalksystems.com>>
>>> *Date:* April 7, 2015 at 6:50:32 PM EDT
>>> *To:* Lawrence Kellogg <mac.hive at me.com <mailto:mac.hive at me.com>>
>>> *Cc:* "glass at lists.gemtalksystems.com
>>> <mailto:glass at lists.gemtalksystems.com>"
>>> <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>>
>>> *Subject:* *Re: [Glass] [GLASS] Seaside - growing extent - normal?*
>>>
>>> Larry,
>>>
>>> Here's the workspace to use if the size of the cache seems to be
>>> reasonable:
>>>
>
> From the previous code, the cache size is 2568
>
> I thought that was reasonable so I ran this code
>
>
>>> | app cache objectsByKey |
>>> app := WADispatcher default handlers at: 'UserInformationInterface'.
>>> cache := app cache.
>>> objectsByKey := cache instVarAt: 3.
>>> {(objectsByKey size).
>>> (cache gemstoneReap)}
>>>
>
>
> and got:
>
>
>
>>> If 'UserInformationInterface' appears to be too big, poke around in
>>> the WAApplication instances that show up in `WADispatcher default
>>> handlers` and see if you can find the smallest cache, and then run
>>> the above workspace against that app ... also I'd like to see the
>>> result array which gives us the number of entries in the cache and
>>> the number of entries expired ...
>>>
>>> If they turn out to be significantly different, then try a second
>>> run ...
>>>
>
>
> Well, this does not seem to be good, having 2568 sessions and only one
> expired.
>
> Thoughts?
>
> Run it again?
>
> Larry
>
>
>>> I'm also tempted to ask you to edit the gemstoneReap method to
>>> reduce the amount of logging (but this would be optional):
>>>
>>> WACache>>gemstoneReap,
>>>
>>> gemstoneReap
>>> "Iterate through the cache and remove objects that have expired."
>>>
>>> "In GemStone, this method is performed by a separate maintenance VM,
>>> so we are already in transaction (assumed to be running in
>>> #autoBegin
>>> transactionMode) and do not have to worry about acquiring the
>>> TransactionMutex.
>>> Since we are using reducedConflict dictionaries in the first
>>> place, we will remove the keys
>>> and values from the existing dictionaries without using the mutex."
>>>
>>> | expired count platform |
>>> expired := UserGlobals at: #'ExpiryCleanup' put: OrderedCollection
>>> new.
>>> platform := GRPlatform current.
>>> platform doCommitTransaction.
>>> count := 0.
>>> objectsByKey
>>> associationsDo: [ :assoc |
>>> (self expiryPolicy isExpiredUpdating: assoc value key: assoc key)
>>> ifTrue: [
>>> self notifyRemoved: assoc value key: assoc key.
>>> count := count + 1.
>>> expired add: assoc.
>>> count \\ 100 == 0
>>> ifTrue: [platform doCommitTransaction ].
>>> count \\ 1000 == 0
>>> ifTrue: [Transcript cr; show: 'Scan progress: ' , count
>>> printString.] ] ].
>>> Transcript cr; show: 'finished scan: ' , count printString.
>>> platform doCommitTransaction.
>>> count := 0.
>>> (UserGlobals at: #'ExpiryCleanup' )
>>> do: [ :assoc |
>>> count := count + 1.
>>> objectsByKey removeKey: assoc key ifAbsent: [].
>>> keysByObject removeKey: assoc value ifAbsent: [ ].
>>> count \\ 100 == 0
>>> ifTrue: [ platform doCommitTransaction ].
>>> count \\ 1000 == 0
>>> ifTrue: [ Transcript cr; show: 'Expire progress: ' , count
>>> printString.]].
>>> platform doCommitTransaction.
>>> UserGlobals removeKey: #'ExpiryCleanup'.
>>> platform doCommitTransaction.
>>> Transcript show: 'Leaving gemstoneReap: ',expired size printString.
>>> ^ expired size
>>>
>>> If you do make these edits then I'd like you to capture the
>>> transcript after each run completes ...
>>>
>>> Dale
>>>
>>> On 04/07/2015 03:20 PM, Dale Henrichs wrote:
>>>> Larry,
>>>>
>>>> Okay, I cannot think of a reason that the earlier scans could not
>>>> work, so I'm thinking that I'd like to pick a smaller subset of the
>>>> whole system that runs faster and then try to understand why the
>>>> scan isn't working ...
>>>>
>>>> So I'll start by finding out if UserInformationInterface will make
>>>> a likely candidate, so let's find out how big the cache is:
>>>>
>>>> | app cache objectsByKey assoc expired1 expired2 timeout
>>>> lastAccessTable entry |
>>>> app := WADispatcher default handlers at: 'UserInformationInterface'.
>>>> cache := app cache.
>>>> objectsByKey := cache instVarAt: 3.
>>>> objectsByKey size
>>>>
>>>> I'll put together another workspace for doing a scan on a per
>>>> application basis in th emean time ...
>>>>
>>>> Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150408/afd1b709/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 28412 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150408/afd1b709/attachment-0001.png>
More information about the Glass
mailing list