【问题标题】:SSL handshake problemsSSL 握手问题
【发布时间】:2011-03-23 16:48:09
【问题描述】:

我们的服务器应用程序在某些客户中遇到了极其缓慢的问题。缓慢通过服务器重新启动解决,但它会在几周后恢复。

Java CPU 始终在 100% 左右(超出 200%),所有其他参数都很好。研究表明,大部分 CPU 被“HandshakeCompletedNotify-Thread”线程消耗。从 tcp dump 我们看到 SSL 握手需要 2-8 秒,时间很长,有时会抛出超时。

我们的 SSL 提供商是 BSAFE。服务器在 Linux(CentOS)、640 mb 堆、2 个内核上运行。 Hibernate、spring都用,Oracle本地db

出现这种行为的原因可能是什么?可以做些什么来找出它们?

附:我们无法将客户的流量切换到 HTTP。

更新:当java进程的传出连接被IP表阻塞时,系统完全释放。在这种情况下释放了哪些资源? 我们看到 SSL 握手经常卡在“更改密码规范”阶段。客户端(我的 java 进程)尝试重用 SSL 会话,但服务器完全无状态,每次都会生成新会话。

【问题讨论】:

  • 您是否使用 jvisualvm 之类的工具对应用程序进行了概要分析?
  • 向我们的客户(大型银行或公司)解释我们想要对他们进行分析有点困难,但我们朝着这个方向努力。我们通常使用 Yourkit 进行分析。 jvisualvm 比 Yourkit 好吗?
  • 您有可以分析的测试系统吗?
  • 不幸的是我没有。没有在QA中复制,但是有很多客户的抱怨

标签: java performance security ssl


【解决方案1】:

这是 Sun 在 6u10 推出下一代 Java 插件时引入的一个已知错误。 Oracle 最终在 Java 7u2 中修复了它,但他们还没有将它向后移植到 Java 6,至少在 6u33 中是这样。

有关该错误的详细信息,#7060523,可以找到here

【讨论】:

    【解决方案2】:

    您可能想查看针对 JBoss 的 this issue 报告(不确定您是否正在使用)。该问题表明HandshakeCompletedNotify-Thread 可以抛出ConcurrentModificationException,这是竞态条件的一种可能结果。其他结果包括陷入无限循环并与 CPU 挂钩的代码,这听起来像是您的症状。如果您正在使用 JBoss,或者与导致报告的问题相关的库,我会考虑升级它。它可能会解决您的问题。

    【讨论】:

    • 症状和你描述的差不多,但是我们用的是Tomcat。
    【解决方案3】:

    您可以尝试切换到 JRE 默认的 JSSE 实现,看看是否存在 BSAFE 错误。

    启用 JSSE 调试代码也很有价值(javax.net.debug 属性)。

    这些链接对调试 JSSE 非常有帮助

    http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug

    http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/ReadDebug.html

    【讨论】:

    • 这可能是我们与分析一起的下一步。感谢您提到 javax.net.debug 属性,它可能很有用。
    【解决方案4】:

    您是否分析过您的 DNS 查找。当 dns 查找速度较慢时,SSL 握手可能需要更长的时间,它需要查找和反向查找才能有效。

    【讨论】:

    • 是的,我们已经考虑过这个问题。 DNS 工作正常。谢谢。
    猜你喜欢
    • 2014-06-28
    • 2019-04-24
    • 1970-01-01
    • 1970-01-01
    • 2019-05-05
    • 1970-01-01
    • 2012-04-04
    • 1970-01-01
    • 2016-08-11
    相关资源
    最近更新 更多