If you want, I can try to take a look at the log file and see if anything jumps out at me...like I said, this _could_ end being a Seaside 3.0 leak...
Dale
----- "Sean Allen" <
[hidden email]> wrote:
| I'll take a look tomorrow and see what is there. I saw all the info
| but it didn't mean much to me at the time.
| It means a lot more know. Thanks for the info.
|
| On Thu, Apr 29, 2010 at 5:23 PM, Dale Henrichs
| <
[hidden email]> wrote:
| > Sean,
| >
| > The out of memory condition will occur due to one of these two
| reasons:
| >
| > - accumulation of temporary data
| > - request processing requires more memory than available
| >
| > To determine which of these conditions you are hitting take a look
| at the log and you will likely see a series of smalltalk stack traces
| mentioning that you are almost out of memory.
| >
| > There is also a table of all class/instance count/bytes consumed in
| the different temporary memory regions.
| >
| > Take a look at the stack that caused the error and try to determine
| if the operation being performed should really consume a whole lot of
| memory .... you can cross reference with the table to look at the
| classes that have the most instances and see if it is likely that the
| operation running would be creating them ... if the instances are more
| likely representative of objects that are created a few at a time over
| time and just might be explicitly cached somewhere (in SessionTemps
| for example) then you just might be accumulating lots of temporary
| data on your own...
| >
| > If the data looks an awful lot like Seaside objects then there might
| be "memory leak" in Seaside30 that I'd need to characterize ...
| >
| > Dale
| > ----- "Sean Allen" <
[hidden email]> wrote:
| >
| > | as this is just running seaside apps, how would one commit more
| > | frequently?
| > |
| > | On Thu, Apr 29, 2010 at 12:23 PM, James Foster
| > | <
[hidden email]> wrote:
| > | > On Apr 29, 2010, at 9:16 AM, Sean Allen wrote:
| > | >
| > | >> beta6. gemstone 2.4
| > | >>
| > | >> just got this error in the logs. what should be the take away
| from
| > | this?
| > | >
| > | > Increase the gem's temporary object space, commit more
| frequently,
| > | modify fewer objects, ...
| > | >
| > | >> GemStone: Error Fatal
| > | >> VM temporary object memory is full
| > | >> , almost out of memory, too many markSweeps since last
| successful
| > | >> scavenge
| > | >> Error Category: 231169 [GemStone] Number: 4067 Arg Count: 1
| Context
| > | : 20
| > | >> Arg 1: 20
| > | >
| > | >
| >
Locked
