-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Eric,
On 3/19/15 7:15 PM, Eric Robinson wrote: > Christopher Shultz wrote: // Time to upgrade. Tomcat is hideously > out of date (probably because you are using RedHat's Tomcat > package), at least by version number. I'm not sure what RedHat > does (if anything) about security fixes, etc. but a vanilla 6.0.18 > is probably vulnerable and has been for a very long time. > > Java 1.6 is EOL and Java 1.7 is getting close. > > I strongly advise you to move up to Tomcat 8.0.20 and Java 1.8 and > start developing and testing your application against those > versions. // > > Would if I could. Vendor restriction. I can only run what they > will support. Bah. I hate "Vendors". Tell them to get with the program. What you are getting isn't support: it's complacency. If someone hacks your environment, they would certainly start paying attention. You should hire another vendor to do penetration tests and let the sparks fly. > Christopher Shultz wrote: // >> Typical startup options looks like this... >> >> JAVA_OPTS="-Xms192M -Xmx384M \ -XX:MaxPermSize=128M \ > > Those seem reasonable, except maybe not PermGen. Are you > increasing it or reducing it from the default on your platform? // > > Increased from default of 64 MB, which ran fine for years until a > recent software upgrade. Okay. > Christopher Shultz wrote: // >> The memory allocation seems low to you because we run many >> instances of tomcat on the same server. Although the servers >> have 32-64GB of RAM, the individual tomcat/java instances are >> kept fairly low. > > We ran for years in a 64MiB heap. Then we got enough traffic that > sessions required us to expand our heaps. If you can run in a > small heap, great. But keep your eye on what's happening with your > users; you may find that you have outgrown your old heap settings. > // > > That's what this question is about. We ran 64 MB heaps for years, > but with the latest application software version we find that > 192-384 is required per instance. Others throw errors unless they > get 768. We cannot set them all the same, so we need to configure > them very carefully and closely. Recent 64-bit JVMs will automatically use "-XX:+UseCompressedOops". I'm not sure about your version, specifically. If you have the option, you might want to run a 32-bit JVM; it will probably run leaner and faster than a 64-bit JVM will. > Christopher Shultz wrote: // >> We are trying to be proactive by watching the memory usage >> numbers in the thread dumps. > > Heap dumps? // > > What we do is called a thread dump, as far as I know. We use kill > -3 on Linux, which dumps the thread activity. The memory data > shows up at the bottom of that. See: > http://producthelp.sdl.com/WorldServer/10.2/en/GUID-4F09CD10-BC4F-46A8-AE83-599A5C8C7740.html Okay. > > A heap dump produces a file roughly the size of the heap space. You are getting a heap summary. If you are issuing a "kill -3" and then looking at stdout, I'd encourage you to take a look at "jstack" which can do the same thing (dump the thread status) but it can be redirected to some other file. That is, it doesn't dump to the target JVM's stdout, but the jstack tool's stdout. It's much more convenient. If you are looking for heap information, you want "jmap" instead: $ jmap -heap [pid] Unfortunately, each of these tools produces output in a slightly different format, so you may have to adjust some of your automated tools to suit. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVDEVSAAoJEBzwKT+lPKRYmNMP/is3AWqp7ZaHccFFQ2olE9su 51SmM1iLsQz9d0KhpXZtC7JK0l7pzE0roxhiAZEHmhg+nmWNRY8nCzcNvT4BM3P2 WUJnakmGve2gvziHXOH/bhtWdsODYCHm/rdxMHUYf+9i2i4aKwpBG0KtVHzK3f3r 29oC17hqzE2IqRSLaWKSM3xLY4smXVBb29srKnhjL86k4pPtRisdI9beCRTRagoo D4tcWK/vre6r+0Hq50bj2oM7ECCpNnWVv/TloKy18DsuyU1ODsTE9XWoBKuMVSry HYiStjGB0wHuiltwF5Q7PtVH+gAMJTFYExUekMFOt4nESllcZw6bezZnbPm2Q2Qd AJkLvA2SRgRBEzXUFkbWozlSCIDz/kKNAYYd9mzAJQDwRrvaoumACYbOdyBWApZM xC+bIb2rgVvXKHZr0cbzEmfoXRq3bHSfI3rMCpj2lY7PCjLw9jFukuc+ogiuiPbu HgkfyFofJKOAYp2aimbzH4RBGzddDh0gm3VD7kOUHudyWngH2UmUtwHcdOmH/Jtw MFK99lhQ+5Mdxg1Damb4nZxmfWWmQkHOV8pvNBw/pyWFIEo73QO3L4T0ZTAZM3Ll CpqAPiWKTWzEBGE3hL1PWB9DKbWTTeZjDFOwJ/gKW8Gcb8y8RKq41EL4yzRc8lWu QCoidw6zb75NIrXYuXd3 =8EKS -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
