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 <naftoli...@gmail.com> 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<pe...@bubblefoundry.com> 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 <naftoli...@gmail.com> 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<pe...@bubblefoundry.com> 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 <sur...@gmail.com> 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 > > > <timo...@getintheloop.eu>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." <marius.dan...@gmail.com> wrote: > > > > > BTW 256mb seems to me ridiculous small for a server side application. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
