java - Apache Spark executor uses more than one core despite of spark.executor.cores=1 -
when start apache spark 1.2.1
application on centos 6.5, receive more 100% load executors in accordance 'top' output , load average significant more amount of cores.
as result have high load on garbage collector.
- have tried limit cores per executor
spark.executor.cores=1
. - have tried
spark.cores
. no effect. - hardware 2 x intel(r) xeon(r) cpu e5-2620 v2 @ 2.10ghz, 6 physical cores each 12 cpu cores per node.
- deployment model yarn client.
similar ubuntu 14.04 setup 4 physical cores (intel i5) has no issue, 1 core per executor.
any idea how fix this?
application submission performed code needed properties set through system.setproperty
, spark configuration , context created. done same way, possible difference spark configuration properties set per-cluster there nothing special. under ubuntu 4 cores i5 leads proper load no more 1 core used each executor. under centos 6.5 2x6 cores e5 see more 1 core used per executor. more, tried apply 4 cores i5 configuration e5 , had no success.
spark-defaults.conf
file content (before spark version substitution 1.2.1):
spark.master=yarn-client spark.eventlog.enabled=true spark.eventlog.dir=hdfs:///user/spark/applicationhistory spark.yarn.historyserver.address=x.x.x.x:18088 spark.executor.memory=1650m spark.executor.cores=1 spark.cores.max=4 spark.executor.instances=15 spark.shuffle.memoryfraction=0.2 spark.storage.memoryfraction=0.02 spark.yarn.jar=hdfs:///user/spark/share/lib/${spark.version}/spark-assembly.jar
main problem here see 2 x 6 cores e5 has lower performance linear 1 i5 x 4 cores. yes, e5 older should anyway notable more powerful. , yet analysed spark history server ui on similar load on both clusters see notable more time spent gc on e5 cluster. crazy state.
ok, @ end have found:
- actually had wrong understanding of 'cpu load' here. more 100% means execution queue length.
- cpu cores allocation correct. 1 core allocated per executor demanded.
- based on gc profiling enabled on spark executors , job code review found root cause non-optimal copying of objects. code corrected more lean in term of memory management.
so resolution was:
when see more 100% load on cpu core under spark executor should first check job gc logs ineffective memory intensive operations or @ least reduce lifetime of objects more aggressive release of resources.
Comments
Post a Comment