Peter, I was running demo.liftweb.net with a heap size of 32MB. I am using the "jetty_instance" found in http://github.com/dpp/lift-samples/tree/master
32MB for the heap size is just fine except every once in a while, we get 2,000 new sessions opened up and that pushed the heap past the 32MB level, so I'm currently running with a max 128MB heap. On Tue, Jul 28, 2009 at 4:36 PM, Peter Robinett <[email protected]>wrote: > > Yep, that's what I figured. I should add the memory usage seems to > have stabilized at approximately 55% of all memory. Looking at the > logs I see that starting about an hour and a half from launch lots of > sessions regularly expire. I assume a session is being created per > POST and then expires some time later. Since all the POSTs are coming > from the same source, is it possible to make more efficient use of > sessions (ie have fewer of them)? Do I need to change something in the > source (I have control over it) or in the Lift app? If the POSTs are going to a Custom Dispatch (DispatchPF), you can change the code to be a stateless (LiftRules.statelessDispatchTable instead of LiftRules.dispatch) No session will be generated as part of handling the request. Thanks, David > > > Thanks, > Peter > > On Jul 28, 3:28 pm, Ross Mellgren <[email protected]> wrote: > > If it's a left-to-right sawtooth (e.g. increasing linearly over time > > and then sharply dropping) then that's probably garbage accumulating > > then the GC running. > > > > -Ross > > > > On Jul 28, 2009, at 6:23 PM, Peter Robinett wrote: > > > > > > > > > Nope, haven't touched any of the files. As for the increases, they do > > > not appear to, since requests happen approximately every second and > > > the length of each spike is around one minute. > > > > > Peter > > > > > On Jul 28, 3:16 pm, Naftoli Gugenheim <[email protected]> wrote: > > >> It would redeploy if you were using mvn jetty:run and you changed > > >> files in the webapp. > > >> Do the increases correspond to (specific) requests? > > > > >> ------------------------------------- > > > > >> Peter Robinett<[email protected]> wrote: > > > > >> Thanks, Naftoli. After running for an hour the app is using 45-60% of > > >> my (very little) memory. It appears that memory is being used in a > > >> sawtooth pattern, with the baseline gradually creeping upwards.[1] I > > >> don't see any mention in the logs of any redeployments. > > > > >> Peter > > > > >> [1]:http://www.bubblefoundry.com/lift/jconsole-overview.jpg > > > > >> On Jul 28, 2:15 pm, Naftoli Gugenheim <[email protected]> wrote: > > > > >>> You can monitor it with jconsole. > > >>> Is the memory building up gradually and not being garbage > > >>> collected? Is it being redeployed without restarting jetty? > > > > >>> ------------------------------------- > > > > >>> Peter Robinett<[email protected]> wrote: > > > > >>> Thanks all for the comments and suggestions. I'm totally new to the > > >>> Java world, so thanks for mentioning all these various options. > > > > >>> First, my system: MySQL is the database I'm using with my Lift app > > >>> (and some other very low traffic apps) and is tuned pretty > > >>> aggressively to use little memory. It seems to only use tens of > > >>> megabytes. My Lift app is based upon 1.1-SNAPSHOT and archetype > > >>> lift- > > >>> archetype-basic. > > > > >>> Second, JVM options and analysis: how should I pass options to the > > >>> JVM > > >>> when launching jetty and Lift with 'mvn jetty:run'? What heap size > > >>> should I use? How do I monitor a JVM process? My actors being > > >>> notified > > >>> of the REST POSTs are scala.actors, as I understood them to be > > >>> sufficient[1]: class NodeActor extends Actor with ListenerManager. > > >>> The > > >>> CometActors that listen to the NodeActors are defined like: class > > >>> NodeGraph extends CometActor. > > > > >>> Thanks for your help, > > >>> Peter > > > > >>> [1]:http://groups.google.com/group/liftweb/msg/86d518b0c44b1b58? > > >>> hl=en > > > > >>> On Jul 28, 10:31 am, Spencer Uresk <[email protected]> wrote: > > > > >>>> I'm not sure about how much overhead Jetty adds to the mix (I'd > > >>>> assume it > > >>>> would be small, but I could be wrong), but on my production > > >>>> server, a small > > >>>> Lift app added only 30 - 40 mb or so to the memory usage of my > > >>>> Tomcat > > >>>> instance. Based on my experience with running Java and Groovy based > > >>>> applications on a VPS, a 256 mb slice should be plenty unless you > > >>>> have lots > > >>>> of concurrent sessions and/or big sessions. If people are having > > >>>> a different > > >>>> experience with Lift-based apps, I'd be interested in hearing > > >>>> that (and > > >>>> why). > > > > >>>> Peter, Have you tried running jmap on your box to generate a heap > > >>>> dump and > > >>>> then analyzing that to see what is using up all the memory? Using > > >>>> something > > >>>> like MAT (www.eclipse.org/mat/) makes it pretty easy to see what > > >>>> the likely > > >>>> culprits are, and then you can go from there. > > > > >>>> - Spencer > > > > >>>> On Tue, Jul 28, 2009 at 3:55 AM, Timothy Perrett > > >>>> <[email protected]>wrote: > > > > >>>>> Agreed; its pretty light to run all those services. I have a > > >>>>> lift based app > > >>>>> that's been running for quite some time and its using around > > >>>>> 250mb of RAM > > >>>>> on > > >>>>> average. A raw lift app will probably use 128mb RAM as minimum. > > > > >>>>> Cheers, Tim > > > > >>>>> On 28/07/2009 10:08, "marius d." <[email protected]> wrote: > > >>>>>> BTW 256mb seems to me ridiculous small for a server side > > >>>>>> application. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
