views:

412

answers:

3

Over the weekend we added SSL security to a Tomcat 6 instance that has been running for awhile without error. This morning, after the number of sessions increased on the machine, Tomcat began throwing 500 errors to users. I checked the logs and found an instance of OutOfMemory, followed by dozens of errors related to Google Guice attempting to start new threads. I can only image that with the addition of SSL, more memory is being used by more threads being created, or some such situation. I'm not terribly sure where or how the extra resources are being used.

I was hoping that those with the experience of using SSL on Tomcat could point me in some direction on places to look for clues. At the moment I'm not sure where the issue could be. Here are a few of the statistics about our setup and configuration:

-XX:ThreadStackSize=512
Initial Memory Pool: 128MB
Maximum Memory Pool: 1024MB
Thread Stack Size: 512KB

I've been adjusting these in various ways to attempt to at least find a path towards success. So far, about 5 minutes after the server is restarted the performance begins to plummet. Any direction would be greatly appreciated.

A: 

Adding a SSL certificate / https to Tomcat6 should not cause these problems.

Where is the OutOfMemoryError coming from? Can you attach a profiler to see what is taking up so much memory?

I think that what you are looking at here is two unrelated changes:

  1. You enabled SSL/https
  2. Your number of session has gone up, exposing memory problems.
matt b
I wouldn't think so either. However, everyone was peachy on Friday. We had the same number of sessions, the same code, etc. The only change that happened on the system was the SSL addition.
Chris Stewart
I should also state that removing SSL solves the issue. Everything runs fine when SSL is disabled.
Chris Stewart
+1  A: 

Here's a possibility, though it's a bit of a long-shot: Browsers cache a https content a lot less aggressively than http content. So, if your end-users are now accessing the service over HTTPS, but previously over HTTP, you're going to be handling a lot more requests (though with the same number of sessions).

Failing that, I'd go with Matt B's suggestion above; profile to find out where the heap's being used. Add -verbose:gc -Xloggc:/path/to/where/you/want/gc.log to your startup JVM arguments, and use the resulting gc.log to see if you can correlate jumps in heap size with particular sequences of requests. Use jmap -dump:format=b,file=/path/to/dump {tomcat PID} to generate a heap dump. If you take one immediately after starting tomcat, and one when it starts to die, you can then use jhat to show the differences between the two.

Chris May
Actually, I think it's not such a long shot. But in any case, the course of action is just to treat it like any old OutOfMemoyError that you can't guess the cause of and add diagnostics and profiling.
Neil Coffey
A: 

This discussion of gc in SSLSessionImpl objects could be relevant . . . .

http://forums.sun.com/thread.jspa?threadID=5266266

tbond