|
From: Brett v. de S. <bv...@as...> - 2010-03-18 01:56:09
|
>what you have so far revealed implies that > >- you have persistent models which you manipulate and present > in response to requests. >- these models combine some persistent/static data and some > dynamic/per-session data. >- the complete set of models takes more space than the heap would allow. >- the models for any given actual simultaneous session mix do fit in >heap. >- you load model state from external storage on demand. >- you free models when no longer used - through gc possibly combined > with weak sets and/or releasing. Yes. I think you have described it correctly. >given this situation, you experience memory exhaustion despite that >no session ever requests more than its unit resources. If I monitor garbage collection, using (generation-bytes-allocated i), and memory usage, using (room), I find the dynamic space size is stable and that session data is being recovered by the garbage collection after sessions are finished. This goes on for about 30 minutes (a session is average 14 minutes long) with the dynamic space size staying under 300MB. Then I get the memory exhaustion error. > >? what happens if you arrange the request mix such that the models >are never released. that is, there is always some session which uses >each model and the session mix is limited such that no more than the >maximum expected permitted number of models is required. does this >eventually exhaust memory as well or does it survive? I have thought about sharing models between sessions where there are multiple students solving the same problem. It is a good idea but will require some work to implement. > >if the entire model is s-expressions and function objects, reuse >would be difficult as the former are very fine-grained and the latter >are difficult to recycle. one would need more information about the >model. if there are higher-level composite data structures, the >approach offers advantages. Yes, reuse of model data structures between sessions solving differenct problems would be a bad idea. Brett |