[Glass] AlmostOutOfMemory in Seaside but not from GemTools...

[Mariano Martinez Peck]

Thank you both guys. Indeed, it was that. I discovered my seaside gems were
running with a different configuration file:

/opt/gemstone/product/seaside/etc/seaside30.conf

which overrides GEM_TEMPOBJ_CACHE_SIZE..
so I modified that one also and now it works!

btw, it also sets:
GEM_NATIVE_CODE_ENABLED = FALSE;

which would explain why I can still debug in my server. I will test this
later to confirm it.

Paul: yes, I saw that, I remember Dale pointed me to that as well. For sure
my reports will go along this lines in the near future.

In the meanwhile....I need to investigate how to increase upstream timeouts
because Nginx redirects the request to another Gem when it think it gives
timeout so that causes a mess.

Thanks!



On Thu, Dec 12, 2013 at 7:41 PM, Paul DeBruicker <pdebruic at gmail.com> wrote:

> You might want to consider using the ServiceVM for making the report
>
> https://code.google.com/p/glassdb/wiki/ServiceVMExample
>
>
>
> there's also this thread:
>
>
> http://forum.world.st/out-of-temporary-memory-in-fastcgi-adaptor-td3396671.html#a3397101
>
>
> Mariano Martinez Peck wrote
> > Hi guys,
> >
> > I have a "large" report that reads some CSV files, process them and
> output
> > a result.
> > If I run the report from a unit test in GemTools, it works perfect. But
> > when I run it from a Seaside request (it is the same report), my seaside
> > gems are crashed with an out of memory:
> >
> > GemStone: Error         Nonfatal
> > a AlmostOutOfMemory occurred (notification 6013), Session's temporary
> > object memory is almost full
> > Error Category: 231169 [GemStone] Number: 6013  Arg Count: 1 Context :
> > 1745804545 exception : 1745804801
> > Arg 1: [20 sz:0 cls: 76289 UndefinedObject] nil
> >
> > I have placed many "System _tempObjSpacePercentUsed" along my report but
> > up
> > to the last print it was 30% (from seaside)....  When I run it locally, i
> > doesn't go even more than 20%.
> >
> > I did my homework and read almost every chapter related to this topic. My
> > conf has:
> >
> > SHR_PAGE_CACHE_SIZE_KB = 2000000;
> > GEM_TEMPOBJ_CACHE_SIZE = 1800000;
> >
> > Yes, I read this as well:
> >
> http://gemstonesoup.wordpress.com/2008/11/19/gemstone-101-managing-out-of-memory-situations/
> >
> > but I don't know how to do that from seaside. Doing a
> >
> >  System signalAlmostOutOfMemoryThreshold: *75*.
> >
> > just before executing my report (in the seaside callback) ... but nothing
> > happens and the gems crash anyway.
> >
> > This report takes normally like 4 minutes. I know....I cannot hung a gem
> > serving a request that takes 4 mins, but that will take more time to fix
> > it. So first I want the report working even if the gem is hung. Maybe
> this
> > is something related to  STN_GEM_ABORT_TIMEOUT or something like that?
> > Something related to that is in the startSeaside30_adaptor and the
> FastCGI
> > one...yes, my report take 4 mins.
> >
> > Any other idea? I also run the statmonitor and I have a statmon file to
> > inspect with VSD.
> >
> > I really don't understand why the same code would work in GemTools but
> not
> > when called from Seaside.
> >
> > Thanks in advance!!!
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
> > _______________________________________________
> > Glass mailing list
>
> > Glass at .gemtalksystems
>
> > http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Glass-AlmostOutOfMemory-in-Seaside-but-not-from-GemTools-tp4729740p4729745.html
> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131213/ada2ce32/attachment-0001.html>