permgen

How do I increase the memory used by my Weblogic (Java). While starting the server from eclipse it shows a message that JAVA Memory arguments: -Xms256m -Xmx512m -XX:MaxPermSize=256m . I couldn't understand from where is it taking that value from. After sometime the Weblogic server fails because of low permgen space. I added startup arguments from console but that doesn't have any effect. Can you help me from where is it taking the memory values from? When you configure a "Server" in Eclipse for WebLogic, you select a domain directory (for local). That domain directory contains the startup

Glassfish sometimes fails to stop when the PermGen is full, in this case asadmin stop-domain domain1 doesn't work. In Glassfish 2.1.1 it would just sit there forever; in 3.x it times out after AS_ADMIN_READTIMEOUT . So I am now working on my Glassfish stop script that will kill/kill -9 it after a certain timeout to guarantee it gets stopped. To fully test this I need to reproduce this PermGen full scenario. How can I deliberately fill up PermGen? I'm currently using Java 1.7.0_45 if that matters. I've written a program to fill up heap but this is a new one for me, I figured I'd turn to SO. It

We are running grails and we are noticing multiple full garbage collections are needed to clear out the permgen space. 2013-06-06T16:11:27.016+0000: 32582.145: [Full GC 32582.145: [CMS2013-06-06T16:11:45.404+0000: 32600.532: [CMS-concurrent-mark: 21.403/86.063 secs] [Times: user=48.44 sys=0.63, real=86.07 secs] (concurrent mode failure): 7585874K->7290466K(10145024K), 57.9230770 secs] 7866094K->7290466K(10451712K), [CMS Perm : 261766K->261702K(262144K)] icms_dc=30 , 57.9232150 secs] [Times: user=57.97 sys=0.00, real=57.93 secs] 2013-06-06T16:12:25.183+0000: 32640.311: [GC [1 CMS-initial-mark:

I'm running a GWT+Hibernate app on Glassfish 3.1. After a few hours, I run out of Permgen space. This is without any webapp reloads. I'm running with –XX:MaxPermSize=256m –XmX1024m . I took the advice from this page , and found that I'm leaking tons of classes- all of my Hibernate models and all of my GWT RequestFactory proxies. The guide referenced above says to "inspect the chains, locate the accidental reference, and fix the code". Easier said than done. The classloader always points back to an instance of org.glassfish.web.loader.WebappClassLoader . Digging further, I find lots of

What would be the purpose of limiting the size of the Permgen space on a Java JVM? Why not always set it equal to the max heap size? Why does Java default to such a small number of 64MB? Are they trying to force people to notice permgen issues in their code by doing this? If my app uses 85MB of permgen, then it might be safe to set it to 96MB but why set it so small if its just really part of the main heap? Wouldn't it be efficient to allow the JVM to use as much PermGen as the heap allows? Conceptually to the programmer, you could argue that a "Permanent Generation" is largely pointless. If

It looks like MemoryError: PermGen space java.lang.OutOfMemoryError: PermGen space is a common problem. You can Increase the size of your perm space, but after 100 or 200 redeploys it will be full. Tracking ClassLoader memory leaks is nearly impossible. What are your methods for Tomcat (or another simple servlet container - Jetty?) on production server? Is server restart after each deploy a solution? Do you use one Tomcat for many applications ? Maybe I should use many Jetty servers on different ports (or an embedded Jetty) and do undeploy/restart/deploy each time ? I gave up on using the

I have a Java 7 project that runs scripts every n minutes by n processes. Here is an example of the code that runs the scripts. ScheduledFuture scheduledFuture = scheduledService.scheduleAtFixedRate(new Runnable() { @Override public void run() { try (GroovyClassLoader cl = new GroovyClassLoader()) { // Load up reusable script modules in the class loader Class scriptClass = cl.parseClass(scriptSource); Foo script = optimizationClass.newInstance(); // Tell Groovy that we don't need class meta info GroovySystem.getMetaClassRegistry().removeMetaClass(scriptClass); script.run(); cl.clearCache(); }