ObjectLogEntry considerations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

ObjectLogEntry considerations

GLASS mailing list
Ciao folk,

        I open a new chapter, although aware that it is linked to the previous email.

        Into my deployment system the SystemRepository freeSpace decrease about 50 MB any day.

        But when investigate about it i found that this space is largely relative to the ObjectLogEntry.

        When i do:   ObjectLogEntry _objectLog size   the system answer: 0

        and i think it's all ok,   without error.

        When i do the fullBackup the relative file size is about 4156MB

        After   i do the command: ObjectLogEntry emptyLog

                the size of fullBackup file is about   759MB ( and MFC and relative cleanup running in background ).

        Now my questions are:

                A) how i can view all the data into ObjectLogEntry ?

                B) The Transcript show: ',,,,,,,,, '  call by the methods, are added to the ObjectLogEntry ?

                C) What else is added to the ObjectLogEntry ?

                D) into deployment system when and who reset-clear the ObjectLogEntry

                E) The background process to manage and recover  the freeSpace is very slow ( 5 hours )
                       
                        It's correct ?



        Thanks for any considerations,

                Dario
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ObjectLogEntry considerations

GLASS mailing list
Dario,

What does `ObjectLogEntry objectQueue size` tell you ?

Since you are using the direct accessor #_objectLog to measure the size of the objectLog, the objectLog is not filled from the objectQueue when you access it.
The #empyLog implementation uses #objectLog, so it will empty the objectQueue into the objectLog.

Short answer: do not use #_objectLog but #objectLog message

Resetting and clearing the object log is a manual task, or a task you automate as a regularly-run topaz script (think “crontab” here).
If you have that many items on the object log, I think you need to investigate, or have a regular clean-up job.

cheers
Johan

> On 18 Nov 2015, at 11:13, Trussardi Dario Romano via Glass <[hidden email]> wrote:
>
> Ciao folk,
>
> I open a new chapter, although aware that it is linked to the previous email.
>
> Into my deployment system the SystemRepository freeSpace decrease about 50 MB any day.
>
> But when investigate about it i found that this space is largely relative to the ObjectLogEntry.
>
> When i do:   ObjectLogEntry _objectLog size   the system answer: 0
>
> and i think it's all ok,   without error.
>
> When i do the fullBackup the relative file size is about 4156MB
>
> After   i do the command: ObjectLogEntry emptyLog
>
> the size of fullBackup file is about   759MB ( and MFC and relative cleanup running in background ).
>
> Now my questions are:
>
> A) how i can view all the data into ObjectLogEntry ?
>
> B) The Transcript show: ',,,,,,,,, '  call by the methods, are added to the ObjectLogEntry ?
>
> C) What else is added to the ObjectLogEntry ?
>
> D) into deployment system when and who reset-clear the ObjectLogEntry
>
> E) The background process to manage and recover  the freeSpace is very slow ( 5 hours )
>
> It's correct ?
>
>
>
> Thanks for any considerations,
>
> Dario
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ObjectLogEntry considerations

GLASS mailing list
I forgot to add:

And what does `ObjectLogEntry objectLog size` tell you? (mind the use of #objectLog instead of #_objectLog)

cheers
Johan

> On 18 Nov 2015, at 13:46, Johan Brichau <[hidden email]> wrote:
>
> Dario,
>
> What does `ObjectLogEntry objectQueue size` tell you ?
>
> Since you are using the direct accessor #_objectLog to measure the size of the objectLog, the objectLog is not filled from the objectQueue when you access it.
> The #empyLog implementation uses #objectLog, so it will empty the objectQueue into the objectLog.
>
> Short answer: do not use #_objectLog but #objectLog message
>
> Resetting and clearing the object log is a manual task, or a task you automate as a regularly-run topaz script (think “crontab” here).
> If you have that many items on the object log, I think you need to investigate, or have a regular clean-up job.
>
> cheers
> Johan
>
>> On 18 Nov 2015, at 11:13, Trussardi Dario Romano via Glass <[hidden email]> wrote:
>>
>> Ciao folk,
>>
>> I open a new chapter, although aware that it is linked to the previous email.
>>
>> Into my deployment system the SystemRepository freeSpace decrease about 50 MB any day.
>>
>> But when investigate about it i found that this space is largely relative to the ObjectLogEntry.
>>
>> When i do:   ObjectLogEntry _objectLog size   the system answer: 0
>>
>> and i think it's all ok,   without error.
>>
>> When i do the fullBackup the relative file size is about 4156MB
>>
>> After   i do the command: ObjectLogEntry emptyLog
>>
>> the size of fullBackup file is about   759MB ( and MFC and relative cleanup running in background ).
>>
>> Now my questions are:
>>
>> A) how i can view all the data into ObjectLogEntry ?
>>
>> B) The Transcript show: ',,,,,,,,, '  call by the methods, are added to the ObjectLogEntry ?
>>
>> C) What else is added to the ObjectLogEntry ?
>>
>> D) into deployment system when and who reset-clear the ObjectLogEntry
>>
>> E) The background process to manage and recover  the freeSpace is very slow ( 5 hours )
>>
>> It's correct ?
>>
>>
>>
>> Thanks for any considerations,
>>
>> Dario
>> _______________________________________________
>> Glass mailing list
>> [hidden email]
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ObjectLogEntry considerations

GLASS mailing list
In reply to this post by GLASS mailing list

On Wed, Nov 18, 2015 at 7:13 AM, Trussardi Dario Romano via Glass <[hidden email]> wrote:
Ciao folk,

        I open a new chapter, although aware that it is linked to the previous email.

        Into my deployment system the SystemRepository freeSpace decrease about 50 MB any day.

        But when investigate about it i found that this space is largely relative to the ObjectLogEntry.

        When i do:               ObjectLogEntry _objectLog size          the system answer:             0 

        and i think it's all ok,   without error.

        When i do the fullBackup        the relative file size is about         4156MB

        After   i do the command:               ObjectLogEntry emptyLog

                the size of fullBackup file is about   759MB ( and MFC and relative cleanup running in background ).



That MIGHT be related to the fact of RC classes holding up data. 
Read the thread with subject: "RcIdentityBag holding deleted objects via instVar "components"
In that thread I shared the cleanup I end up running as part of my daily cleanup. 
It's very important you run that code WITHOUT any other gem running.
 
        Now my questions are:

                A) how i can view all the data into ObjectLogEntry ?

ObjectLogEntry objectLog inspect. 
From Seaside there is a WAObjectLog component which is very nice for browsing it.
With tODE via command "ol view".
 

                B) The Transcript show: ',,,,,,,,, '  call by the methods,       are added to the ObjectLogEntry ?

Yes. Unless you explicitly disable that (very new feature we added with Dale into Transcript). 
 

                C) What else is added to the ObjectLogEntry ?


Errors, continuations, traces, etc.
 

                D) into deployment system when and who reset-clear the ObjectLogEntry


Depends on your app. With Dale and James we included an example in ObjectLogEntry class exactly for this reason. So that you can customize and create your own. I run that one everyday. See: https://github.com/GsDevKit/GsDevKit/issues/71

 

                E) The background process to manage and recover  the freeSpace is very slow ( 5 hours )


Yes, reclaimAll is very very slow (I/O operations mostly). They say it is faster in 3.2 (I come from 3.1.0.6) but I cannot confirm that. 
 

--

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: ObjectLogEntry considerations

GLASS mailing list
In reply to this post by GLASS mailing list
Both Mariano and Johan are giving you good advice ... I add my 2 cents
below ...

On 11/18/2015 02:13 AM, Trussardi Dario Romano via Glass wrote:

> Ciao folk,
>
> I open a new chapter, although aware that it is linked to the previous email.
>
> Into my deployment system the SystemRepository freeSpace decrease about 50 MB any day.
>
> But when investigate about it i found that this space is largely relative to the ObjectLogEntry.
>
> When i do:   ObjectLogEntry _objectLog size   the system answer: 0
>
> and i think it's all ok,   without error.
>
> When i do the fullBackup the relative file size is about 4156MB
>
> After   i do the command: ObjectLogEntry emptyLog
>
> the size of fullBackup file is about   759MB ( and MFC and relative cleanup running in background ).
>
> Now my questions are:
>
> A) how i can view all the data into ObjectLogEntry ?
I recommend that you use tODE and use the `ol view` command. Look at
`man ol` to see the various operations supported. There is a pretty rich
set of operations that can be performed:

NAME
   ol - View and manipulate object log entries

SYNOPSIS
   ol [--help] <command> [<options>] [ <priority>... ]

DESCRIPTION
   A <priority> is one of the following:

     debug
     error
     fatal
     interaction
     info
     trace
     transcript
     warn

   An empty <priority> implies the entire object log.

   Commands:
     clear Remove object log entries
     view  View object log entries

OPTIONS
   --help [<command>]
     Bring up this man page or a man page for a subCommand.

EXAMPLES
   ol --help

   ol view error
   ol view --inverse transcript
   ol view --age=`1 day` -r transcript
   ol view --continuation
   ol view --continuation --age=`1 month` error

   ol clear debug error trace
   ol clear --inverse transcript
   ol clear --age=`1 month`
   ol clear --continuation
   ol clear --continuation --age=`1 month` error

   NOTE - use the `tode it` menu item to run the examples directly from
this window.

SEE ALSO

edit /tools/gs/bin/ol
   browse method --spec `TDGemStoneTool class>>ol`

   NOTE - use the `tode it` menu item to run the commands directly from
this window.


>
> B) The Transcript show: ',,,,,,,,, '  call by the methods, are added to the ObjectLogEntry ?
Yes they are, but in recent versions of GLASS/GsDevKit, you can control
whether or not the Transcript messages are logged to the gem log or the
object log on a session by session basis.
>
> C) What else is added to the ObjectLogEntry ?
The Transcript entries are the only thing that are added in a standard
GLASS/GsDevKit system. If you are using seaside, then continuations are
added to the object log in the event of errors while handling requests.
Also there are entries added when seaside gems are started and stopped ....

Use tODE and `ol view` to see more.
>
> D) into deployment system when and who reset-clear the ObjectLogEntry
In a deployed system, you should probably be looking for errors on a
daily basis ... how long you keep error continuations is up to you ...
if you use the object log to record import system events, then you may
not want to completely clear the object log and simply clear out the
continuations (which are likely to be consuming the majority of space)
.... if you don't use the object log at all, then clear it as part of
your weekly cleanup ...
>
> E) The background process to manage and recover  the freeSpace is very slow ( 5 hours )
>
> It's correct ?
There are ways to speed up these operations, but the cost is in
increased SPC, faster disks, more extens .... the real question is "is
it acceptable to have the free space reclaimed in 5 hours?" if it is not
acceptable (adverse impact on other parts of the system), then you may
want to invest the time in reading the manual, studying statmon output
and learning ... if there is enough demand it is possible that we could
put on tuning courses of some sort, but usually there is a cost
associated with putting on such class ....

Dale
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass