What's your experience with adding SSL to Tomcat 6?

What's your experience with adding SSL to Tomcat 6?

把回忆走一遍 发布于 2021-11-25 字数 1202 浏览 784 回复 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.

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

暮光沉寂 2022-06-07 3 楼

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

https://forums.oracle.com/forums/thread.jspa?threadID=1532009

攀登最高峰 2022-06-07 2 楼

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.
生活了然无味 2022-06-07 1 楼

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.