On 09/01/2019 14:24, Mark Thomas wrote: > On 09/01/2019 10:14, Mark Thomas wrote:
<snip/> >> It may be you are seeing the same thing. Or you may have found a memory >> leak. The next step would be to use a profiler to see where the memory >> is being used. > > Using NIO + OpenSSL with the settings from the commented out APR/native > TLS connector in server.xml, the heap and non-heap memory reported by > the profiler reach steady state at fairly low values. However, process > memory continues to steadily increase. Those observations are consistent > with a memory leak in native code (but they are not proof). > > Next steps are looking at additional logging to see where the memory > allocations occur. I didn't really get anywhere with that. There was a lot of noise from the JVM and the performance hit was several orders of magnitude so there was no obvious built up of leaked memory. However, there has been some progress. I've tested trunk (9.0.x) with: - Oracle JDK 1.8.0_192 - Tomcat Native 1.2.19 - OpenSSL 1.1.2-dev - JMeter (20 threads, /index.jsp, no keep-alive) and the commented out APT/native TLS connector in the default server.xml. APR/native connector - no leak NIO+JSSE - no leak NIO+OpenSSL - leak Interestingly, the performance of the above was roughly: NIO+OpenSSL - 5000 req/s NIO+JSSE - 4000 req/s APR/native - 400 req/s That difference is so large I wonder if I was doing something wrong. Something to come back to later. Given than only NIO+OpenSSL is affected (or at least it is significantly more affected than the other combinations) I'm going to take another look at the code focussing on the parts that are specific to that configuration. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
