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 |
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 |
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 |
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,
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: ObjectLogEntry objectLog inspect. From Seaside there is a WAObjectLog component which is very nice for browsing it. With tODE via command "ol view".
Yes. Unless you explicitly disable that (very new feature we added with Dale into Transcript).
Errors, continuations, traces, etc.
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
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 |
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 ? `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 |
Free forum by Nabble | Edit this page |