-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian,
On 11/12/2010 3:02 PM, Brian wrote: >> -----Original Message----- >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Sent: Thursday, November 11, 2010 02:39 PM > >> I agree with Chuck's assessment, but there may be some questions we can ask >> to >> help lead you down the right path when using tools such as memory profilers. >> >> 0. What kind of OOME are you suffering? Please post any messages that >> you get when your heap busts. Specifically, is this a "regular" heap >> exhaustion or a PermGen exhaustion? > > Good question, but I can't answer that. I think I lost my logs. :-( > I will search for them again. > But I could use the profiler now and responde whatever you would like to ask > about how is it behaving now. I think you already answered this elsewhere: you're filling-up your Tenured generation and/or PermGen. Keep an eye on PermGen: if it's filling up after your "600000 URLs" (that's a /lot/ IMO) have all been hit, then you might have a redeployment problem. >> 1. Are you seeing any messages in catalina.out when you undeploy of >> the form "your webapp likely has a memory leak"? Tomcat 6.0.x has >> some nice checks on undeploy to see if your webapp is leaking >> some specific things like threads, etc. > > Yeah, I have seen those lately. Read them, and try to fix them. ;) >> 2. Are you re-starting your webapp a lot while Tomcat remains running? >> Failure to perform some clean-up during webapp unload can cause >> your entire set of classes loaded in the "old" webapp to stay in >> the PermGen space forever. > > No, I don’t restart them frequently. But I do redeploy them > frequently, in the past I did it deleting the WAR in the directly and > uploading a new one, now I'm suing the Tmocat Manager do undeploy and > deploy again. Semantics. You are stopping your webapp and starting it again, with or without an update to the WAR file. It's actually the ungraceful webapp stop that kills you, not the fact that you start up again or whether it's a restart or a redeploy. If your webapp doesn't clean-up, the WebappClassLoader can stay in memory forever. In fact, that's a good test: search your memory snapshot for instances of WebappClassLoader. There's a boolean in each one ("active" I think) that tells you if it's active. Force a couple of full GCs, then see how many of them are still around. If you have more than 1+webapp count (I think you get one for free plus one for each webapp deployed) then the old, undeployed webapps are still sitting around in memory. If that's the case, then you are filling-up your PermGen with useless java.lang.Class instances. I'm not sure how Tomcat expires it's caches, but it might also be keeping those cached static files around with the WebappClassLoader, too. Double whammy. >> 3. Are you using any caching mechanism in your webapp? Perhaps it needs >> to be tuned. You should probably check out what's in your >> "application" scope: you may have things you didn't expect. > > I do have some caches in my objects. For example, the ir an object > called "BrandsManager" which has methods like "getBrands(), > getBrand(int id), insertBrand" and so on. The getBrands() method goes > to the database only the first time, and then creates a LinkedList > with the data. But I don't think this kind of caching is the problem, > they consume a minimal amount of memory. It's always a good idea to double-check. >> 4. Are you using HttpSession for anything bulky? It's possible that >> you are "leaking" memory with lots of sessions. When a webapp >> is stopped, though, all session should be purged and if you >> have session persistence, they should all come back and take >> up the same amount of memory. This is a long-shot, but low-hanging >> fruit. > > No, I don’t store anything big in the sessions. I just store some > strings in them. Nothing serious.How do I know if I have session > persistence? You get it for free if you use the standard manager: it will persist sessions to the disk when Tomcat stops, and re-load them when Tomcat comes back up. This is not session persistence like using a DbStore where all your session data goes to a db or anything like that. >> It's worth a read to understand how simple things like using a >> logging library can cause PermGen exhaustion after several webapp >> redeploy operations. > > Well, I'm using the Tomcat log indeed. And I also saw a lot of > memory being used by that! But more memory is being used by the > cached static pages, so I guess I should start with that. Tomcat's log shouldn't be using any noticeable amount of memory. The only static file you mentioned was a 400KiB file, which is only 4% of the default cache size of 10MiB. Are you seeing /lots/ of those files? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzdpycACgkQ9CaO5/Lv0PDvJgCfUHYFH2uP/5gYKrb84Y/N/SoN LZEAn2hjU3bjQqx/6+6OdPVdexd6mkkX =dPtI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
