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.