Dru,
If you are using TopLink as the JPA provider, this blog can help tune up its
cache:
http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t.html
Regards,
-marina
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
>