Re: Tomcat Crashes after 1000 sessions.
Vikram Godse [EMAIL PROTECTED] wrote: Hi, My CATALINA_OPTS parameter has the following values i have 4gb ram on my server CATALINA_OPTS=-server -XX:MaxPermSize=512m -Xms1024m -Xmx1024m This is what i see in the tomcat manager server info. Max threads: 200 Min spare threads: 4 Max spare threads: 50 Current thread count: 20 Current thread busy: 17 Max processing time: 560464 ms Processing time: 2668.859 s Request count: 2800 Error count: 46 Bytes received: 0.00 MB Bytes sent: 27.28 MB My Max threads are 200 of which current thread count is 20 and current busy are 17 with 128 active sessions. The same problem here. Tomcat 5.5.15, Java 1.5.0, CATALINA_OPTS: -XX:MaxPermSize=512m -Xms1024m -Xmx1024m Info from one of the managers webapps: Max threads: 200 Min spare threads: 25 Max spare threads: 50 Current thread count: 57 Current thread busy: 16 Sessions: 192 -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Peter Lin [EMAIL PROTECTED] wrote: another potential solution is to try a different JVM like Bea's JRockit. JRockit provides some built in profiling capabilities, so that is another way to get some profile data quickly. I've read about jrockit 5.0 SP1. They say it has a new feature that can help track memory leaks in just few days, not few weeks :D To find a memory leak in cocoon webaplication would probably take few years for person like me, anyway :)) -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Tomasz Nowak [EMAIL PROTECTED] wrote: Hm. Here is my logging.properties: http://www.biochip.pl/logging.properties.txt The way new vhosts are added is pretty stupid for me but lets forget about the semantics now. I've added swallowOutput attibute to serveral context. How should it suppose to work? On my box it works in this way: - The only file that actually logs anything that matters is catalina.out - Most of catalina.out inputs also appear in localhost.timstamp.log - Nothing more then manager actions are logged to vhost logs - After tomcat has stared, the only input logs are: a) useless: INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action (repeted serveral times every single minute (!) on my machine) b) sth like: Feb 28, 2006 11:00:03 PM org.apache.jk.core.MsgContext action WARNING: Error sending end packet java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:518) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:112) at org.apache.jk.core.MsgContext.action(MsgContext.java:293) So how can I: - configure it to work similary to tomcat 4.1, I mean logs from different vhost go to different files - configure Tomcat not to log anything that belongs to vhost to catalina.out - turn of these useless jk infos Any help on above would be _really_ appreciated! -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Peter Lin [EMAIL PROTECTED] wrote: my advice is dive in and try to debug it, or hire someone with experience debugging webapps. there's no much others can do for you at this point, since it's debugging. good luck. I've just meant configuring the logging system: So how can I: - configure it to work similary to tomcat 4.1, I mean logs from different vhost go to different files - configure Tomcat not to log anything that belongs to vhost to catalina.out - turn of these useless jk infos Any help on above would be _really_ appreciated! Tomcat 5.5 logging docs are very brief about it.. Simple duplication of example entries does not do the job. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: This could be completely unrelated, but let me throw something at you, maybe it will help btw. I prefer to run mod_proxy over mod_jk over http, much simpler, and in *our* load tests has scaled much better during stress. Response already committed This can happen if your servlet/jsp has code like this do some stuff response.sendRedirect(url); ...do some more stuff what has happened here, is that you are trying to write to the response buffer even though you earlier indiciated (through sendRedirect or sendError) that you wouldn't. To correct this, you would have to put a return statement in your code do some stuff response.sendRedirect(url); return; ...do some more stuff I have little controle about it as redirect-url is on of built-in features of Apache Cocoon. I've tried to put sth like: org.apache.jk.core.MsgContext.level = SEVERE into the logging.properties but that unfortunately changes nothing -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sad: Tomcat 5.5.x crashes almost every single day.
Probably important: === - 2x Xeon, 3 GB mem - Linux 2.4.26 - Java 1.5.0_06-b05 - Apache Tomcat 5.5.15 - CATALINA_OPTS=\ -server \ -Djava.awt.headless=true \ -Dfile.encoding=UTF-8 \ -XX:MaxPermSize=256m \ -Xms1024m -Xmx1024m - Connector port=8009 protocol=AJP/1.3 maxThreads=200 minSpareThreads=25 maxSpareThreads=50 backlog=20 connectionTimeout=1 enableLookups=true redirectPort=8443 / - mod_jk 1.2.15 - Apache Httpd 1.3.34 - 8 Tomcat vhosts - 8 webapps - each webapp runs on separate vhost - each webapp is Apache Cocoon 2.1.7 - system load avarage: usually under 0.5 - http load: not more then 20-30 concurrent req The pain: crashing Tomcat == Everything works right until Tomcat suddenly crashes, what happens almost every single day. Sometimes it crashes with OOME / out of heap (heh, is 1GB not enought!?), but somtimes NOTHING wrong is logged into the logs - it just stops responding to requests (hangs). When Tomcat stops responding to requests JK eats all of 256 Apache HTTPd MaxClients so other httpd vhosts stop responding also. Disaster! Any ideas before abandoning Java technology? ;) Default Tomcat logging facility seems to be useless to me. j.u.l. logging.properties semantics looks like a programmers joke made to users (!). And even with swallowOutput it logs everything into catalina.out (?) I found none decent log4j-tomcat-virtual-hosts-logging-manual in Tomcat docs also. Is Tomcat a production ready reference j2se server or just a finish it yourself proof of concept toy? I've been crond-restarting Tomcat 4.1 on Java 1.4 every night for more than a year, and now I have to restart Tomcat 5.5.15 on Java 1.5 AND apache httpd also almost every single day. From my -user point of view, Tomcat doesn't change in a good direction. In fact in it is probably changing in wrong direction - at least the 4.1.x logger element has been working 'out of the box'. Come on! Am I the only one that has such problems with Tomcat? -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Mark Eggers [EMAIL PROTECTED] wrote: enableLookups=true redirectPort=8443 / Why enableLookups=true ??? I use request.getRemoteHost in couple of places. Also, Cocoon can be very resource-intensive depending on which blocks you've built. Almost always only: - databases-block - lucene-block - xsp-block - mail-block - profiler-block Nothing more. JSP under Cocoon 2.1.7 and JDK 1.5 is also problematic, see for example: http://issues.apache.org/jira/browse/COCOON-1457 I have some ideas as to how to approach this, but I've not had the time to investigate. I don't use JSP. But on my development box JSP works fine. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.x crashes almost every single day.
John C. Dale [EMAIL PROTECTED] wrote: Don't give-up on Tomcat so soon. At least 3 years of giving a chance are not soon... ;] Sometimes Tomcat is only as good as the applications deployed within her. Operating system is only as good as the applications run on it. True of false? True... in Windows 95 :-) Few years later even Microsoft handles apps erros successfully. Tomcat is the only server-type software I know that _any_user_ can crash so easily and the only that is so helpless about handling their erros. Why don't it send 500 status to pages in faulty webapp and contiunes to serve other webapps normally? I write my own apps ;o) I use Apache Foundation apps ;] I would stick with it, and cease development of new code until you have eliminated the existing installed code I'm so sad that I think of a _completly_ new code. In PHP! Along the way, it would be helpful for you to beat up a separate, mirrored staging instance of your production environment using JMeter. Reproduce your problem with regularity by hitting each URL many times, then examining the results. This is probably imposibble because: - the apps have _plenty_ of different urls. - I can't reproduce such Tomcat hangs on development machine. - Shall I really examin and monitor the production enviroment? What about performance then? Are there any resource monitors built-in into Tomcat? I've browsed the JMX management manual.. well is it written for a human being? Looks like a finish it yourself thing. :| -- Tomasz Nowak Netventure, http://www.netventure.pl/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Peter Crowther [EMAIL PROTECTED] wrote: Have you tested it for deadlocks that would cause hangs? [...] Profile your application. What's eating memory? Get a thread dump when your application hangs. Is anything deadlocked? What? Where? How? http://www.google.com/search?hl=plq=%22thread+dump%22+site%3Atomcat.apache.org http://www.google.com/search?hl=plq=profile+application+site%3Atomcat.apache.org -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.x crashes almost every single day.
John C. Dale [EMAIL PROTECTED] wrote: PHP is great. So is Zoap and .NET. Careful, though, some of the same problems you would be shunning Java for would also appear in any Internet development/application development platform. I know the pitfalls of PHP, I been developing php webapps before. That's why I moved to Java ;) But as far as I remember: - I've never managed to hang httpd with a buggy PHP script :) - I could _easly_ diagnose ANY PHP bug just by browsing the log file. I'd love Tomcat behave similar. There is a correlation between the size of the application and the time it takes to properly test the application. The larger the application, the more it takes to vet application quality. What you have said here is that you don't want to properly test the application because it's too large and too much work, and that you are happy to continually restart the application as a solution. Sounds equitable. You seems reasonable, but souldn't the appserver at least try to help me a bit? I'd really like to see something more than An error occurred. I quitting. Bye! An error where? Which vhost? Which webapp? Which class? Anything, please. And with regularity, what steps lead up to Tomcat hanging? This is the question that you should try to answer with increasing accuracy each time Tomcat hangs until you find the issue. Once you do, submit it as a bug, and give back to the OS community that has been supporting your applications for 3 years. No hangs regularity. Nothing special in the log files. No starting point out of the box. Please, browse the mailinig list topics. I'm not the only one here with such problems. Different people post similar stories. Are we all wrong? -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Tim Lucia [EMAIL PROTECTED] wrote: Send Tomcat a QUIT (11) signal on Unix, or control/break (run it interactively) on Windows. This will cause the VM to dump all thread stacks. If you don't like Tomcat, you can always shell out some big bugs for a commercial application server. For some even bigger bucks you can get commercial support. I can tell you it's unlikely you'll get a warm reception from the very people who can help you given the current tone of your postings. Your right, the tone of my postings is inproper. I've been using 'free' software for almost 10 years now and I pretty well get the rules. My only excuse is the level of my frustration, based on recent Tomcat use. For now, the only contribition to Tomcat community I can give is _pointing_out_ some real-world problems, that typical users of Tomcat may face (and face!). The problems are: 1. Poor/none default logging facility in 5.5.x. - no real help/tips on error sources - no examples how to do a decent virtual hosts logging - no tips how to switch off a lot of uneccesary trash log inputs If Tomcat is supposed to be production ready why it has no production ready logging features? 2. No real-world, step-by-step docs how to TRACE and eliminate application errors that lead to server failure. That is probably a problem lot of Tomcat users must struggle with. 3. During last years I see no actions taken by Tomcat dev team to eliminate Tomcat server failures caused by webaplications. Is it really impossible? Real world user feedback was the main point of my postings. And sorry for the tone again. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Remy Maucherat [EMAIL PROTECTED] wrote: In case you haven't noticed, it is extremely hard to do, because webapps have their own logging mechanism most of the time. You mention the logger element of 4.x, but it didn't actually do anything (it did put the internal logging for the specified container, as well as the logging done using the ServletContext - aka, the ugliest and most useless logging facility ever). Tomcat 5.5.15 and j.u.l use hierarchical categories for the containers so that you can easily replicate the logging that was done by the logger element. The default logging.properties does that for localhost. I do not consider logging.properties to be poor or bad in any way. Hm. Here is my logging.properties: http://www.biochip.pl/logging.properties.txt The way new vhosts are added is pretty stupid for me but lets forget about the semantics now. I've added swallowOutput attibute to serveral context. How should it suppose to work? On my box it works in this way: - The only file that actually logs anything that matters is catalina.out - Most of catalina.out inputs also appear in localhost.timstamp.log - Nothing more then manager actions are logged to vhost logs - After tomcat has stared, the only input logs are: a) useless: INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action INFO: Response already committed Feb 28, 2006 10:59:22 PM org.apache.jk.core.MsgContext action (repeted serveral times every single minute (!) on my machine) b) sth like: Feb 28, 2006 11:00:03 PM org.apache.jk.core.MsgContext action WARNING: Error sending end packet java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:518) at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:112) at org.apache.jk.core.MsgContext.action(MsgContext.java:293) So how can I: - configure it to work similary to tomcat 4.1, I mean logs from different vhost go to different files - configure Tomcat not to log anything that belongs to vhost to catalina.out - turn of these useless jk infos PS. Tim Lucia: I don't care about access logs, HTTPd logis it for me. Right, you want an integrated profiler, ready to enable, and with no performance cost. I'd like to have it too. OK, so what is the easiest to implement and easiest use to profiler that I can use with Tomcat? It depends, on some OSes, it's apparently impossible to get a threaded server to run properly indeed. You're using Linux 2.4.something. Try updating to 2.6. If you are using Redhat or another Redhat based distros, always use LD_ASSUME_KERNEL. Is Tomcat on 2.6 so called thread save? I've come over several warnings about Apache httpd 2.0 in 'threaded' mode on Linux kernels. People (also PHP dev's) seem to recommend sticking with 1.3. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Nathan Smith [EMAIL PROTECTED] wrote: Hi Tomasz, you mentioned below that you have a MaxPermSize of 256m. I have not seen OOME: PermGen errors on that machine but after having some of them on other machine with aditonal 10 webapps deployed I've increased it from default 64m to 256m to be absolutly sure it wont hang on PermGen error. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Leon Rosenberg [EMAIL PROTECTED] wrote: We had some serious problems with tomcat, which are solved now, however, we are on 5.0.25 (with session patch) and not on 5.5.x yet. However, when tomcat dies, what your cpu usage is looking like? 100%? I've noticed that when tomcat hangs - load avarage increases from 0.2-0.4 (normal) to about 1.0. But I'll take a close look at the cpu usage next time 5.5.x hangs. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Tim Lucia [EMAIL PROTECTED] wrote: #2 - Do any commercial application server vendors offer you assistance on how to find bugs in application code? You're much more likely to find these answers using google, or reading wikis or from community support. There are hundreds of such discussions out there. My favorite (personally) is how to avoid running out of permgen space. That problems I've already overcome :] But I honestly admit I don't have experience with Bea/Websphere etc, so I didn't know they hang/freeze/crash in the same way Tomcat does. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Leon Rosenberg [EMAIL PROTECTED] wrote: kill -SIGQUIT (i think its kill -11) your tomcat-java process Ok, it has happened again ! Simply: Mar 1, 2006 2:28:34 AM org.apache.catalina.connector.CoyoteAdapter service SEVERE: An exception or error occurred in the container during the request processing java.lang.OutOfMemoryError: Java heap space So I've kill -11 java process and there is an entry in catalina.out: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x00138246, pid=17443, tid=16384 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode) # Problematic frame: # C [libpthread.so.0+0xc246] accept+0x46 # # An error report file with more information is saved as /tmp/hs_err_pid17443.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # That /tmp/hs_err_pid17443.log is here: http://www.biochip.pl/hs_err_pid17443.log.txt Got it! But does it help? -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Peter Lin [EMAIL PROTECTED] wrote: look at the dump, it looks like the permgen ran out of space PSPermGen total 50304K, used 50170K [0x445f, 0x4771, 0x545f) object space 50304K, 99% used [0x445f,0x476ee878,0x4771) try increasing your permGen to 128Mb. Another option is to use a jdk that doesn't have permGen like JRockit. Sun's PermGen is not resized once the JVM starts, so if the webapp has lots of classes, it can exceed the PermGen size. As you see at the bottom of the file I have already 256m PermSpace. Another issue is that if Tomcat 5.5.x runs out of PermSpace, it logs: java.lang.OutOfMemoryError: PermGen space in contrary to: java.lang.OutOfMemoryError: Java heap space And heap space OOME is the one that has been logged. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Peter Lin [EMAIL PROTECTED] wrote: It's not at all clear why -XX:MaxPermSize=256m isn't working and the perm size is still at the default. If the perm gen was set correctly, wouldn't the dump show something other than 99%? You're right, it shows PSPermGen total 50304K not the 256m I've set up. I agree the message is misleading, so something odd is definitely happening. only way to find out at this point is to profile the app. The only apps I run are Apache Cocoon 2.1.7. Profiling such webapp threatens me.. I'm not sure if my java knowledge is sufficient to handle that. -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Nathan Smith [EMAIL PROTECTED] wrote: The problem can be fixed by increasing your -XX:MaxPermSize value to more than 256. I've increased it to 512m now. I'll see. Download and use a program called visualgc available here http://java.sun.com/performance/jvmstat. You can have it running during the day and monitor what the garbage collector is doing and how the Eden, Old and Perm Gen heap spaces are growing. If Tomcat is not throwing an OOM error then the Garbage Collector could be trying to do Full GC's causing Tomcat to hang and become unresponsive. There is a flow on affect here, which makes it look as though the problem is caused by something else. Looks like no way I can run it on headless box. Setting the deamon up fails because it can't write somewhere. # /usr/lib/java5/bin/jstatd Could not create remote object access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write) java.security.AccessControlException: access denied (java.util.PropertyPermission java.rmi.server.ignoreSubClasses write) at java.security.AccessControlContext.checkPermission(AccessControlContext. java:264) at java.security.AccessController.checkPermission(AccessController.java:427 ) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.System.setProperty(System.java:698) at sun.tools.jstatd.Jstatd.main(Jstatd.java:122) Thanks to Java I still don't know where.. : Anyway: a) I've added -Xloggc:/home/tomcat/logs/gc.log I logs sth such inputs: 1489.487: [GC 219875K-151505K(1018496K), 0.0292590 secs] 1546.088: [GC 225745K-152608K(1031744K), 0.0268240 secs] 1591.348: [GC 241696K-152348K(1023296K), 0.0198200 secs] 1635.863: [GC 241052K-156605K(1030656K), 0.0218510 secs] 1653.314: [GC 244925K-155047K(1022272K), 0.0205590 secs] 1727.156: [GC 243047K-157627K(1029632K), 0.0215210 secs] 1730.679: [GC 245307K-163738K(1030016K), 0.0263340 secs] 1740.791: [GC 251098K-165299K(1030016K), 0.0266920 secs] 1750.912: [GC 252275K-162599K(1022592K), 0.0220800 secs] 1790.949: [GC 249255K-163285K(1028672K), 0.0179890 secs] b) These values do not mean ANYTHING to me but percheps they will be readable by someone from the list: # /usr/lib/java5/bin/jstat -gc 28923 S0CS1CS0US1U EC EUOC OU PC PUYGC YGCTFGCFGCT GCT 9984.0 12352.0 9975.6 0.0 83008.0 21940.2 932096.0 168376.4 48640.0 48550.7 822.150 0 0.0002.150 # /usr/lib/java5/bin/jstat -gcutil 28923 S0 S1 E O P YGC YGCTFGCFGCT GCT 99.92 0.00 58.27 18.06 99.82 822.150 00.000 2.150 # /usr/lib/java5/bin/jstat -gccapacity 28923 NGCMNNGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMNPGCMX PGC PC YGCFGC 116480.0 116480.0 106368.0 11840.0 4736.0 82688.0 932096.0 932096.0 932096.0 932096.0 16384.0 524288.0 48640.0 48640.0 83 0 # /usr/lib/java5/bin/jstat -gcpermcapacity 28923 PGCMN PGCMX PGC PC YGC FGCFGCT GCT 16384.0 524288.048640.048640.083 00.000 2.172 28923 is the PID of jvm I'm focused on -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sad: Tomcat 5.5.x crashes almost every single day.
Wade Chandler [EMAIL PROTECTED] wrote: Sometimes changing the ratio to not have enough new space and then creating too many objects too fast can make your application eventually throw OOMEs because it can't move the objects into older spaces quick enough depending on what you application is doing. Gosh, it looks like don't move your mouse coursor to quickly or your operations system will fail :D How much memory does your system have compared to how much memory you have allocated to your heap? Asking because of the way the VM will be able to allocate memory. The total heap size switches are separate from the MaxPermSize, so if your heap size is too large and then you have bumped up your PermSize then you could have this issue when your PermSize resizes and your heap tries to grow as well. MaxPermSize doesn't set the PermSize to that size, but is merely a limit, so it will grow as you add to your permanent objects (classes and statics). phisical: 3gb settings: -XX:MaxPermSize=512m -Xms1024m -Xmx1024m (was 256m for Perm, 512m now) -- T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
