That sounds like you're not releasing your old threads as you finish
with them, in both configurations, rather than a PermSize issue. The old
version may have been queuing incoming messages waiting for a thread,
while the new version simply runs out of allocatable threads. I'd check
your code to see if you're holding on to old connections or something
like that and, if possible, point something like JConsole at it to see
what your memory and thread usage is like to narrow down the potential
culprits.
glassfish_at_javadesktop.org wrote:
> Dear Jean Francois,
> I have reconfigured the my production server according the performance tips from your articles Configuring Grizzly for performance part I and II and here are the results:
> Configuration recommended by you:
> <jvm-options>-server</jvm-options>
> <jvm-options>-XX:+AggressiveHeap</jvm-options>
> <jvm-options>-Xmx1400m</jvm-options>
> <jvm-options>-Xms1400m</jvm-options>
> <jvm-options>-Xss128k</jvm-options>
> <jvm-options>-XX:MaxPermSize=400m</jvm-options>
> <jvm-options>-XX:+DisableExplicitGC</jvm-options>
> <jvm-options>-Dcom.sun.enterprise.server.ss.ASQuickStartup=false</jvm-options>
> <jvm-options>-XX:ParallelGCThreads=2</jvm-options>
> <jvm-options>-XX:+UseParallelOldGC</jvm-options>
> <jvm-options>-XX:NewRatio=2</jvm-options>
>
> The server stops running one hour after being started throwing the following exception: java.lang.OutOfMemoryError: unable to create new native thread
> I have increased the values for MaxPermSize but the problem still persists.
>
> Configuration we used to have:
> <jvm-options>-server</jvm-options>
> <jvm-options>-Xmx1200m</jvm-options>
> <jvm-options>-Xms1200m</jvm-options>
> <jvm-options>-Xss128k</jvm-options>
> <jvm-options>-XX:MaxPermSize=400m</jvm-options>
> <jvm-options>-XX:+UseConcMarkSweepGC</jvm-options>
> <jvm-options>-XX:SoftRefLRUPolicyMSPerMB=1</jvm-options>
> <jvm-options>-XX:+DisableExplicitGC</jvm-options>
> <jvm-options>-Dcom.sun.enterprise.server.ss.ASQuickStartup=false</jvm-options>
> <jvm-options>-XX:NewRatio=2</jvm-options>
>
> The difference between both configurations is the aggressive heap and the GC algorithm.
> The problem with the second configuration is that the https port stops responding after receiving roughly 5000 requests. The strange thing is that the http port still works fine and there is no error message in Glassfish’s log file.
>
> The hardware and software I’m using is as follows: processor Intel Core 2 Quad 2.50 GHz, 4 GB RAM, Windows Server 2008 Standard Edition, Glassfish V2.1 b51
>
> I would really appreciate any comments or suggestions since I have a production server that is crashing ones a day.
>
> Thank you for your time and help,
> David
> [Message sent by forum member 'zukerman' (zukerman)]
>
> http://forums.java.net/jive/thread.jspa?messageID=301259
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>