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

James Foster james.foster at gemtalksystems.com
Thu Dec 12 14:09:58 PST 2013


One possibility is that a different config file or parameter is being used. For example, the FastCGI gems might be Topaz sessions running with a -T argument. The best way to diagnose this is to look at the log file for the gem (this will be stdout if Topaz is started “linked”, with the -l option). Verify that you have the right log file by checking the start time and PID. There should be something that shows the value for GEM_TEMPOBJ_CACHE_SIZE and it might mention where it got the value.

James

On Dec 12, 2013, at 2:04 PM, Mariano Martinez Peck <marianopeck at gmail.com> 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 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/20131212/5db73cb3/attachment.html>


More information about the Glass mailing list