Smalltalk › Gemtalk › GLASS

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

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 3 messages Options
Mariano Martinez Peck
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Mariano Martinez Peck
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;


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!!!


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

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

James Foster-9
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 <[hidden email]> 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;


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!!!

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


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

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

Paul DeBruicker
In reply to this post by Mariano Martinez Peck
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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Free forum by Nabble Edit this page