Memory settings for Spark standalone cluster

Memory settings for Spark standalone cluster

The Spark standalone cluster means it is not running on Mesos or YARN cluster managers.
There are multiple memory parameter settings and this article will explain each of them by showing real cases.
Firstly we need to understand the Spark components.

1. Master and Worker Daemon processes

Master and Worker are components of the Spark's standalone cluster manager. They manage available resources in the cluster.
For example on Master Node, we can find below JAVA process which is Master Daemon process:
-Xms2g -Xmx2g org.apache.spark.deploy.master.Master
Example of Worker Daemon process on Worker Node:
-Xms1g -Xmx1g org.apache.spark.deploy.worker.Worker spark://<IP of master>:7077
Above JVM settings are controlled by SPARK_DAEMON_MEMORY in spark-env.sh.
In this example, "n1a" is the Master Node host name, "n4a" is the Worker Node host name.
[root@n1a conf]# grep -i SPARK_DAEMON_MEMORY spark-env.sh
export SPARK_DAEMON_MEMORY=2g
[root@n4a conf]# grep -i SPARK_DAEMON_MEMORY spark-env.sh
export SPARK_DAEMON_MEMORY=1g

2. Driver and Executor

When running Spark applications, new processes will be created which means applications run as independent sets of processes.
The application is coordinated by the SparkContext object in your main program -- Driver.
Driver will ask Master for resources, Master then allocates Workers to this application, and Worker will start Executors, which are processes that run computations and store data for your application.

The Driver memory is controlled by "SPARK_DRIVER_MEMORY" in spark-env.sh , or "spark.driver.memory" in spark-defaults.conf, or by specifying "--driver-memory" in application.
The Executor memory is controlled by "SPARK_EXECUTOR_MEMORY" in spark-env.sh , or "spark.executor.memory" in spark-defaults.conf or by specifying "--executor-memory" in application.

For example, if I am running a spark-shell using below parameter:
spark-shell --executor-memory 123m --driver-memory 456m
On Master Node, you can find out below Driver process is created for this process:
-Xms456m -Xmx456m org.apache.spark.deploy.SparkSubmit
On Worker Node, below Executor process is created:
-Xms123M -Xmx123M org.apache.spark.executor.CoarseGrainedExecutorBackend

3. Total memory for all Spark applications per server

As we know, each application's Executor usage is controlled by SPARK_EXECUTOR_MEMORY.
Total memory limit for all applications per server is controlled by "SPARK_WORKER_MEMORY" in spark-env.sh.
[root@n1a conf]# grep SPARK_WORKER_MEMORY spark-env.sh
# - SPARK_WORKER_MEMORY, to set how much total memory workers have to give executors (e.g. 1000m, 2g)
export SPARK_WORKER_MEMORY=3g

4. Troubleshooting

Jobs may fail with error message "Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient memory". It is because of no sufficient memory for the request.
For example, if we ask for 4G executor memory, it will fail because the total SPARK_WORKER_MEMORY is set to 3g in above example.
[root@n1a conf]#  spark-shell --executor-memory 4g
scala> val textFile = sc.textFile("passwd")          
textFile: org.apache.spark.rdd.RDD[String] = passwd MappedRDD[1] at textFile at <console>:12

scala> textFile.count()           
14/11/25 17:49:33 WARN LoadSnappy: Snappy native library is available
14/11/25 17:49:48 WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient memory
14/11/25 17:50:03 WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient memory
14/11/25 17:50:18 WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient memory

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Controlling Parallelism in Spark by controlling the input partitions by controlling the input partitions

Image
It is useful to be able to control the degree of parallelism when using Spark. Spark provides a very convenient method to increase the degree of parallelism which should be adequate in practice. This blog entry of the "Inside Spark" series describes the knobs Spark uses to control the degree of parallelism. Controlling the number of partitions in the " local " mode Spark is designed ground up to enable unit testing. To control the degree of parallelism in the local mode simply utilize the function JavaRDD<String> org.apache.spark.api.java.JavaSparkContext.parallelize(List<String> list, int numSlices) The following snippet of code demonstrates this usage- public class SparkControlPartitionSizeLocally { public static void main ( String [] args ) { JavaSparkContext sc = new JavaSparkContext ( "local" , "localpartitionsizecontrol" ); String input = "four score and sev
Lire la suite

Spark performance optimization: shuffle tuning

Image
Article directory 1 shuffle tuning 1.1 Summary of tuning 1.2 Overview of ShuffleManager Development 1.3 HashShuffleManager operating principle 1.3.1 Unoptured HashShuffleManager 1.3.2 Optimized HashShuffleManager 1.4 SortShuffleManager operating principle 1.4.1 General operating mechanism 1.4.2 bypass running mechanism 1.5 shuffle related parameters tuning 1.5.1 spark.shuffle.file.buffer 1.5.2 spark.reducer.maxSizeInFlight 1.5.3 spark.shuffle.io.maxRetries 1.5.4 spark.shuffle.io.retryWait 1.5.5 spark.shuffle.memoryFraction 1.5.6 spark.shuffle.manager 1.5.7 spark.shuffle.sort.bypassMergeThreshold 1.5.8 spark.shuffle.consolidateFiles 2 write in the last words Shuffle Summary of tuning Most of the performance of Spark operations is mainly consumed in the shuffle link, because the link contains a large number of disk IO, serialization, network data transmission and othe
Lire la suite

Spark optimization

Image
One operation and maintenance 1. Master hang up, standby restart is also invalid Master defaults to 512M of memory, when the task in the cluster is particularly high, it will hang, because the master will read each task event log log to generate spark ui, the memory will naturally OOM, you can run the log See that the master of the start through the HA will naturally fail for this reason. solve Increase the Master's memory spark-env.sh , set in the master node spark-env.sh : export SPARK_DAEMON_MEMORY 10g # 根据你的实际情况 Reduce the job information stored in the Master memory spark.ui.retainedJobs 500 # 默认都是1000 spark.ui.retainedStages 500 Hang up or suspend Sometimes we will see the web node in the web ui disappear or in the dead state, the task of running the node will report a variety of lost worker errors, causing the same reasons and the above, worker memory to save a lot of ui The information leads to gc when the heartbeat is lost
Lire la suite