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
>