[Glass] [GLASS] Seaside - growing extent - normal?

[Dale Henrichs via Glass]

No problem, the GLASS documentation hasn't been that stellar either:)

Okay with a large db and a relatively small SPC these operations can be 
very slow... the order of things to do is important ... Hold off on 
running things until I can give you a rough sequence of things to do ... 
in a little bit ...

Dale

On 3/25/15 10:18 AM, Lawrence Kellogg wrote:
> Hello Dale,
>
>   Thanks for the help. I’m a terrible system admin when it comes to 
> maintaining a system with one user, LOL.
>
>   I’m not running the maintenance VM and I haven’t been doing regular 
> mark for collects.
>
>   I’m trying to do a fullBackupTo: at the moment, well see if I get 
> through that. Should I have done a markForCollection before the full 
> backup?
>
>   I’ll also try the ObjectLog trick.
>
>   I guess I need to start from a fresh extent, as you said, and the 
> extent file will not shrink. I’m at 48% of my available disk space but 
> it does seem slower than usual.
>
> Best,
>
> Larry
>
>
>
>> On Mar 25, 2015, at 12:58 PM, Dale Henrichs via Glass 
>> <glass at lists.gemtalksystems.com 
>> <mailto:glass at lists.gemtalksystems.com>> wrote:
>>
>> Lawrence,
>>
>> Are you doing regular Mark for collects? Are you running the 
>> maintenance vm along with you seaside servers?
>>
>> Seaside produces persistent garbage (persistent session state that 
>> eventually times out) when it processes requests so if you do not run 
>> the maintenance vm the sessions are not expired and if you do not run 
>> mfc regularly the expired sessions are not cleaned up ...
>>
>> Another source of growth could be the Object Log ... (use 
>> `ObjectLogEntry initalize` to efficiently reset the Object Log ... 
>> pay attention to the mispelling ... thats another story). If you are 
>> getting continuations saved to the object log, the stacks that are 
>> saved, can hang onto a lot of session state, that even though expired 
>> will not be garbage collected because of references from the 
>> continuation in the object log keep it alive ...
>>
>> The best way to shrink your extent (once we understand why it is 
>> growing) is to do a backup and then restore into a virgin extent 
>> ($GEMSTONE/bin/extent0.seaside.dbf)...
>>
>> Dale
>>
>> On 3/25/15 8:34 AM, Lawrence Kellogg via Glass wrote:
>>> Well, Amazon sent me a note that they are having hardware trouble on 
>>> my instance, so they shut it down. It looks like they’re threatening 
>>> to take the thing offline permanently so I’m trying to save my work 
>>> with an AMI and move it somewhere else, if I have to.
>>>
>>> I finally got Gemstone/Seaside back up and running and noticed these 
>>> lines in the Seaside log file. These kind of messages go on once a 
>>> day for weeks. Is this normal?
>>>
>>> --- 03/07/2015 02:44:14 PM UTC ---
>>>   Extent = 
>>> !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
>>>       has grown to 22528 megabytes.
>>>   Repository has grown to 22528 megabytes.
>>>
>>>   Extent = 
>>> !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
>>>       has grown to 22544 megabytes.
>>>   Repository has grown to 22544 megabytes.
>>>
>>> --- 03/08/2015 03:31:45 PM UTC ---
>>>   Extent = 
>>> !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
>>>       has grown to 22560 megabytes.
>>>   Repository has grown to 22560 megabytes.
>>>
>>>   Extent = 
>>> !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
>>>       has grown to 22576 megabytes.
>>>   Repository has grown to 22576 megabytes.
>>>
>>> --- 03/10/2015 03:19:34 AM UTC ---
>>>   Extent = 
>>> !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
>>>       has grown to 22592 megabytes.
>>>   Repository has grown to 22592 megabytes.
>>>
>>> --- 03/10/2015 03:46:39 PM UTC ---
>>>   Extent = 
>>> !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
>>>       has grown to 22608 megabytes.
>>>   Repository has grown to 22608 megabytes.
>>>
>>>   Extent = 
>>> !#dbf!/opt/gemstone/GemStone64Bit2.4.4.1-x86_64.Linux/seaside/data/extent0.dbf
>>>       has grown to 22624 megabytes.
>>>   Repository has grown to 22624 megabytes.
>>>
>>>
>>> My extent has now grown to
>>>
>>> -rw------- 1 seasideuser seasideuser 23735566336 Mar 25 15:31 
>>> extent0.dbf
>>>
>>>
>>> I don’t get a lot of traffic so I’m a little surprised at the 
>>> growth. Should I try to shrink the extent?
>>>
>>> I suppose I should also do a SystemRepository backup, if I can 
>>> remember the commands.
>>>
>>> Best,
>>>
>>> Larry
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150325/14605cec/attachment-0001.html>