[kepler-dev] Memory Useage

[Kevin Ruland]

What I mean about the database is we can store just enough information 
in there to support the library views and searching.  I don't exactly 
what information would be required but something like:  Name, 
categorization, little icon assignment, lsid, more data?.  I was 
thinking something even lighter weight than the ActorMetadata proxy 
object you mention but in any case it would certainly be smaller than 
the current ActorMetadata.

Right now I don't have hard numbers on the total memory requirements for 
each entry in ActorMetadata.  I'll see if I can't convince the standard 
java profiling tools to hand this over to me.

Kevin

Shawn Bowers wrote:

>I'm not sure I'm really following what Kevin has said below in terms of
>the database, etc.
>
>But, I just wanted to make a note on keeping actor objects loaded in
>memory:  First, is there any idea of how large these objects are?
>Second, to support search, we'd either need to (1) load "proxy" objects
>for each actor (e.g., the ActorMetadata objects would be a good
>candidate), or (2) implement some type of mechanism that only loaded
>(either proxy or the actual actor)  objects that are at any one time shown
>in the actor library. I'm thinking approach (1) wouldn't be that much
>savings. Approach (2) would be more scalable but require a lot of work
>because we'd have to completely rewrite the actor library stuff (and may
>result in slowdown for navigating and otherwise interacting with the actor
>library).
>
>However, I'm in general supportive of going the proxy route regardless of
>this issue, because it is a more elegant way to deal with actors that
>can't be loaded for whatever reason at runtime.
>
>
>-shawn
>
>
>On Wed, 21 Dec 2005, Kevin Ruland wrote:
>
>  
>
>>Dan,
>>
>>That would be a great savings.  It would also potentially speed up
>>startup in the "populated cache" scenario.  Any changes to that system
>>has to wait until we are back with a full corpus of developers (in
>>particular Chad).  My opinion is some judicious use of the internal
>>database would greatly simplify startup and prevent loading all the
>>actors into memory simultaneously.
>>
>>BTW - you can try my one line hack to ptolemy MoMLParser to see if it
>>frees up enough memory to execute those workflows.  Christopher will
>>probably come up with a much better solution but it appeared to work for me.
>>
>>Kevin
>>
>>Dan Higgins wrote:
>>
>>    
>>
>>>Hi All,
>>>
>>>   Kevin and Christopher have had several emails on memoery leaks in
>>>Kepler. Even when we get the leaks fixed, I am seeing another memory
>>>issue - memory useage.. I am now getting some java 'out of memeory'
>>>errors on some workflows on a 512M Windows machine. I think we really
>>>would like to have Kepler run on a machine with 512MB of RAM, so we
>>>should do some thinking  about reducing memory use. The most obvious
>>>solution I can think of is to avoid loading all actor into memory at
>>>program startup.
>>>
>>>Dan
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>>    
>>