Open kruton opened 4 years ago
./gradlew jmh
Output:
# JMH version: 1.25.2
# VM version: JDK 1.8.0_232, OpenJDK 64-Bit Server VM, 25.232-b09
# VM invoker: /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
# VM options: -server -Xms2g -Xmx2g
# Warmup: 10 iterations, 10 s each
# Measurement: 10 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.conscrypt.JmhAlpnBenchmark.hs
# Parameters: (a_cipher = TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, b_buffer = HEAP, c_engine = CONSCRYPT_UNPOOLED)
# Run progress: 0.00% complete, ETA 10:30:00
# Fork: 1 of 1
1301.482 ops/s
# Warmup Iteration 2: 1348.852 ops/s
# Warmup Iteration 3: 1414.627 ops/s
# Warmup Iteration 4: AppData::create pipe(2) failed: Too many open files
<failure>
java.lang.RuntimeException: javax.net.ssl.SSLException: Unable to create application data
at org.conscrypt.ConscryptEngine.newSsl(ConscryptEngine.java:207)
at org.conscrypt.ConscryptEngine.<init>(ConscryptEngine.java:183)
at org.conscrypt.OpenSSLContextImpl.engineCreateSSLEngine(OpenSSLContextImpl.java:143)
at javax.net.ssl.SSLContext.createSSLEngine(SSLContext.java:329)
at org.conscrypt.OpenJdkEngineFactory$2.newServerEngine(OpenJdkEngineFactory.java:97)
at org.conscrypt.EngineHandshakeBenchmark.handshake(EngineHandshakeBenchmark.java:93)
at org.conscrypt.JmhAlpnBenchmark.hs(JmhAlpnBenchmark.java:58)
at org.conscrypt.jmh_generated.JmhAlpnBenchmark_hs_jmhTest.hs_thrpt_jmhStub(JmhAlpnBenchmark_hs_jmhTest.java:158)
at org.conscrypt.jmh_generated.JmhAlpnBenchmark_hs_jmhTest.hs_Throughput(JmhAlpnBenchmark_hs_jmhTest.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:453)
at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:437)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLException: Unable to create application data
at org.conscrypt.NativeCrypto.SSL_new(Native Method)
at org.conscrypt.NativeSsl.newInstance(NativeSsl.java:79)
at org.conscrypt.ConscryptEngine.newSsl(ConscryptEngine.java:205)
... 20 more
Yeah, I noticed that when digging into #835... It's not a trivial fix (until we drop the fd-based socket) but fairly straightforward, we'd have to differentiate the calls to NativeSsl.newInstance()
from ConscryptEngine
and ConscryptFileDescriptorSocket
.
Any workaround to fix this issue?
It looks like the
AppData
structure always allocatesfdsEmergency
even if it's not possible for them to be used. Eliminating the allocation of these file descriptors would be a nice clean up.Currently it appears as though the OpenJDK JMH benchmarks can't be run on my workstation because
AppData
is allocating a ton of file descriptors too quickly. I could probably up theulimit
but that seems to be not addressing the underlying issue.