0
Ich rufe native JNI-basierte Funktionen in Map-Operationen von Spark auf.Langsamer JNI-basierter Spark-Job auf EC2
// Read each input from HDFS or S3
val A = info.sc.broadcast(fs.read(0, 4)) // 400 MB
val B = info.sc.broadcast(fs.read(1, 4)) // 400 MB
// Generate RDD
val index = info.sc.parallelize(0.toLong to SIZE-1 by 1)
// Perform Map operations --> the problematic part
val res = index.map{ x => nativeFunction(x, A, B) }.persist
// Fake action for profiling purpose
res.foreachPartition{ x => }
// Get the results back and write them in the HDFS or S3
val output = res.reduce(Util.bitor)
fs.write(2, output)
Wenn ich es auf EC2 leite, nimmt die Ausführung des Mappings über 4x mehr, als wenn ich es auf einem lokalen Cluster mit derselben partitionieren und Anzahl der Kerne laufen.
Wenn ich die native Funktion außerhalb von Spark ausführe, ist die Ausführung äquivalent, was beweist, dass dies nicht an der EC2-Virtualisierung liegt.
Irgendeine Idee von einem Grund?
ich gerade entdeckt, das Problem tritt nicht auf, wenn ich Funken von Hand Set-up (das heißt ohne Funken EC2-Skript) auf EC2 Ubuntu 14.04 ami mit – elldekaa