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:

  1. actually had wrong understanding of 'cpu load' here. more 100% means execution queue length.
  2. cpu cores allocation correct. 1 core allocated per executor demanded.
  3. 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

Popular posts from this blog

google chrome - Developer tools - How to inspect the elements which are added momentarily (by JQuery)? -

angularjs - Showing an empty as first option in select tag -

php - Cloud9 cloud IDE and CakePHP -