On Fri, 2008-10-31 at 12:04, Dru Devore wrote:
> I knew about the heap not getting larger than what is specified, I
> included the information to be complete. What I needed to get to was the
> rest of it so thank you very much. I have a couple of
> questions/confirmations.
>
> We are planning on increasing the memory for this machine. The powers
> that be would like to get the memory under control so we can be assured
> that increasing the memory doesn't simply delay the death. So since this
> is my first stint on admining GF for production can I expect the memory
> to ever max out? or will it simply keep growing tell this happens no
> matter what I do. I am guessing that it will eventually stop but how big
> should I expect this to get before it finally settles down?
You can expect the memory to max out -- all the socket connections and
everything else I mentioned are made gradually (e.g., a connection pool
typically has a min and max size where the min starts at 1). Once they
all hit the max size, they' have allocated the memory.
So typically, I always set the min == max for connection pool sizes and
request-processing threads and java heap, just so that all the memory is
allocated up front.
If the memory doesn't max out under those circumstances, there is a bug
somewhere -- either in glassfish or the JVM itself (which we are unaware
of), or in the postgres JDBC drivers.
-Scott
> Are there any docs out there for this tuning. I have been looking and
> find a tidbit here and a tidbit there but nothing complete.
>
> > -------- Original Message --------
> > Subject: Re: Memory Keeps Growing
> > From: Scott Oaks <Scott.Oaks_at_Sun.COM>
> > Date: Fri, October 31, 2008 10:12 am
> > To: users_at_glassfish.dev.java.net
> > Cc: GlassfishAdmin <admin_at_glassfish.dev.java.net>
> >
> >
> > The memory usage of any Java application, including glassfish, isn't
> > really at all dependent on your data set. The Java heap will grow to
> > whatever size you have specified (256M in your case), and all Java
> > objects will be managed by the JVM in that heap. There's nothing you can
> > do in the application to really affect that -- if you tell Java to use
> > 256M of heap, that's what it will use.
> >
> > The remaining memory used by the JVM is native memory for its libraries,
> > plus any native memory your application is using (that would be the case
> > if you are using a Type 2 JDBC driver). Assuming you're using a type 4
> > JDBC driver, then the remaining memory is all program text and data.
> >
> > The program text and native memory will occupy a certain amount of space
> > which you can't really control. But one thing is that every socket used
> > by the application uses some native memory for its socket buffers, so
> > you should make sure that the size of all your socket-related tunables
> > is reasonable, particularly for your very small machine. This includes
> > the size of your JDBC connection pool and the number of simultaneous
> > connections your allow into the server (which means the number of
> > keep-alive connections).
> >
> > The other thing that affects native memory is the thread stacks -- you
> > can limit the size of the thread stacks by adding -Xss128k to your
> > jvm-options; you should also make sure that the size of the HTTP
> > request-processing threads is small (again, given your small machine).
> >
> > -Scott
> >
> > On Fri, 2008-10-31 at 09:47, Dru Devore wrote:
> > > We are having a major memory problem and I need a solution.
> > >
> > > The Glassfish process continually takes memory tell there is no more and
> > > postgres dies. I think that postgres has a little blame her for our
> > > overall memory problem but not as much as Glassfish because Glassfish
> > > hogs memory.
> > >
> > > This is our current setup:
> > > Glassfish v2 (asadmin reports Sun Java System Application Server 9.1_01)
> > > (-Xmx256m)
> > > Ubuntu 8.04
> > > Postgres 8.3
> > > Running under VM ware
> > > 1 GB total memory
> > > 512 MB virtual
> > > The application is mostly services implemented in EJB3/JPA. This is not
> > > a large data set.
> > >
> > > Situation:
> > > When GF is started it jumps to around 160m RES (from top) with around
> > > 545m VIRT (from top). Postgres has multiple threads that with one
> > > jumping to around 19m RES and 42408 VIRT.
> > > Over time the GF process will be grow to up around 1250m VIRT and 683m
> > > RES. Postgres will grow its threads to 8 with 28m RES and 42408 VIRT. At
> > > this time pieces of the application start to fail due to postgress
> > > failing. Postgres will eventually fail and all postgres processes will
> > > die out.
> > >
> > > Like I said above the data set is not large. Basically the application
> > > accepts around 5000 service requests/day and stores the information to
> > > the database. It then has some EJB3 timer beans that run and pull
> > > information out of the database, performs some business logic, and
> > > stores some information back to the database. I am not storing any
> > > information, besides configuration settings, in the application. All the
> > > services are serviced with stateless session beans, multiple in most
> > > cases.
> > >
> > > There are performance improvements we are looking at now which will
> > > streamline the application and help but all we have been able to
> > > accomplish up to this point is a delay in the errors.
> > >
> > > Questions:
> > >
> > > 1. How can I limit the GF memory?
> > >
> > > 2. Any tips for performance settings we should look at before moving the
> > > application to production?
> > >
> > > 3. Anything I should look at in my EJB3/JPA code that could help
> > > eliminate unneeded caching or holding of data?
> > >
> > > I am being forced into an admin position on this.
> > >
> > > Thanks for any help.
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>