[
https://issues.apache.org/jira/browse/HADOOP-16011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815356#comment-16815356
]
Siyao Meng commented on HADOOP-16011:
-------------------------------------
Thanks [~tlipcon]. I've also tried to run this w/ native on a Ubuntu 16.04 node.
It seems Hadoop 3.1/3.2 already tries to use OpensslAesCtrCryptoCodec as the
first choice, it falls back when it can't find its path. After setting log4j
level to TRACE I can see its attempt to load native-hadoop lib:
{code}
DEBUG [org.sample.MyBenchmark.testHadoop-jmh-worker-1] Trying to load the
custom-built native-hadoop library...
DEBUG [org.sample.MyBenchmark.testHadoop-jmh-worker-1] Failed to load
native-hadoop with error: java.lang.UnsatisfiedLinkError: no hadoop in
java.library.path
DEBUG [org.sample.MyBenchmark.testHadoop-jmh-worker-1]
java.library.path=/usr/java/packages/lib/amd64:/usr/lib/x86_64-linux-gnu/jni:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/usr/lib/jni:/lib:/usr/lib
WARN [org.sample.MyBenchmark.testHadoop-jmh-worker-1] Unable to load
native-hadoop library for your platform... using builtin-java classes where
applicable
DEBUG [org.sample.MyBenchmark.testHadoop-jmh-worker-1] Failed to load OpenSSL
Cipher.
{code}
So I manually specified the native lib path:
{code:bash}
java
-Djava.library.path=/home/systest/trunk/hadoop-dist/target/hadoop-3.3.0-SNAPSHOT/lib/native/
-jar target/benchmarks.jar
{code}
Results with 3.3.0-SNAPSHOT:
{code}
Benchmark Mode Cnt Score Error Units
MyBenchmark.testHadoop thrpt 3 231204.042 ± 6968.536 ops/s [ w/
OpenSSL ]
MyBenchmark.testHadoop thrpt 3 102696.569 ± 1289.506 ops/s [
w/o OpenSSL, uses JceAesCtrCryptoCodec, JDK 1.8.0_191 ]
MyBenchmark.testNewSecureRandom thrpt 3 104188.125 ± 15255.362 ops/s
MyBenchmark.testSha1PrngNew thrpt 3 343648.417 ± 20911.516 ops/s
MyBenchmark.testSha1PrngShared thrpt 3 583999.658 ± 8519.252 ops/s
MyBenchmark.testSha1PrngThread thrpt 3 581220.206 ± 13029.829 ops/s
{code}
> OsSecureRandom very slow compared to other SecureRandom implementations
> -----------------------------------------------------------------------
>
> Key: HADOOP-16011
> URL: https://issues.apache.org/jira/browse/HADOOP-16011
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Todd Lipcon
> Assignee: Siyao Meng
> Priority: Major
> Fix For: 3.3.0
>
> Attachments: HADOOP-16011.001.patch, HADOOP-16011.002.patch,
> MyBenchmark.java
>
>
> In looking at performance of a workload which creates a lot of short-lived
> remote connections to a secured DN, [~philip] and I found very high system
> CPU usage. We tracked it down to reads from /dev/random, which are incurred
> by the DN using CryptoCodec.generateSecureRandom to generate a transient
> session key and IV for AES encryption.
> In the case that the OpenSSL codec is not enabled, the above code falls
> through to the JDK SecureRandom implementation, which performs reasonably.
> However, OpenSSLCodec defaults to using OsSecureRandom, which reads all
> random data from /dev/random rather than doing something more efficient like
> initializing a CSPRNG from a small seed.
> I wrote a simple JMH benchmark to compare various approaches when running
> with concurrency 10:
> testHadoop - using CryptoCodec
> testNewSecureRandom - using 'new SecureRandom()' each iteration
> testSha1PrngNew - using the SHA1PRNG explicitly, new instance each iteration
> testSha1PrngShared - using a single shared instance of SHA1PRNG
> testSha1PrngThread - using a thread-specific instance of SHA1PRNG
> {code:java}
> Benchmark Mode Cnt Score Error Units
> MyBenchmark.testHadoop thrpt 1293.000 ops/s
> [with libhadoop.so]
> MyBenchmark.testHadoop thrpt 461515.697 ops/s
> [without libhadoop.so]
> MyBenchmark.testNewSecureRandom thrpt 43413.640 ops/s
> MyBenchmark.testSha1PrngNew thrpt 395515.000 ops/s
> MyBenchmark.testSha1PrngShared thrpt 164488.713 ops/s
> MyBenchmark.testSha1PrngThread thrpt 4295123.210 ops/s
> {code}
> In other words, the presence of the OpenSSL acceleration slows down this code
> path by 356x. And, compared to the optimal (thread-local Sha1Prng) it's 3321x
> slower.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
