原文地址：http://www.aboutyun.com/thread-9946-1-1.html

--------------------------------------

問題導(dǎo)讀
1、當(dāng)前集群的可用資源不能滿足應(yīng)用程序的需求，怎么解決？
2、內(nèi)存里堆的東西太多了，有什么好辦法嗎？





1、WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster uito ensure that workers are registered and have sufficient memory
當(dāng)前的集群的可用資源不能滿足應(yīng)用程序所請求的資源。
資源分2類： cores 和 ram
Core代表對執(zhí)行可用的executor slots
Ram代表每個Worker上被需要的空閑內(nèi)存來運(yùn)行你的Application。
解決方法：
應(yīng)用不要請求多余空閑可用資源的
關(guān)閉掉已經(jīng)執(zhí)行結(jié)束的Application


2、Application isn’t using all of the Cores: How to set the Cores used by a Spark App
設(shè)置每個App所能獲得的core
解決方法：
spark-env.sh里設(shè)置spark.deploy.defaultCores
或
spark.cores.max


3、Spark Executor OOM: How to set Memory Parameters on Spark
OOM是內(nèi)存里堆的東西太多了
1、增加job的并行度，即增加job的partition數(shù)量，把大數(shù)據(jù)集切分成更小的數(shù)據(jù)，可以減少一次性load到內(nèi)存中的數(shù)據(jù)量。InputFomart， getSplit來確定。

2、spark.storage.memoryFraction
管理executor中RDD和運(yùn)行任務(wù)時的內(nèi)存比例，如果shuffle比較小，只需要一點(diǎn)點(diǎn)shuffle memory，那么就調(diào)大這個比例。默認(rèn)是0.6。不能比老年代還要大。大了就是浪費(fèi)。

3、spark.executor.memory如果還是不行，那么就要加Executor的內(nèi)存了，改完executor內(nèi)存后，這個需要重啟。

4、Shark Server/ Long Running Application Metadata Cleanup
Spark程序的元數(shù)據(jù)是會往內(nèi)存中無限存儲的。spark.cleaner.ttl來防止OOM，主要出現(xiàn)在Spark Steaming和Shark Server里。
export SPARK_JAVA_OPTS +="-Dspark.kryoserializer.buffer.mb=10 -Dspark.cleaner.ttl=43200"

5、Class Not Found: Classpath Issues
問題1、缺少jar，不在classpath里。
問題2、jar包沖突，同一個jar不同版本。

解決1：
將所有依賴jar都打入到一個fatJar包里，然后手動設(shè)置依賴到指定每臺機(jī)器的DIR。
val conf = new SparkConf().setAppName(appName).setJars(Seq(System.getProperty("user.dir") + "/target/scala-2.10/sparktest.jar"))

解決2：
把所需要的依賴jar包都放到default classpath里，分發(fā)到各個worker node上。


關(guān)于性能優(yōu)化：
第一個是sort-based shuffle。這個功能大大的減少了超大規(guī)模作業(yè)在shuffle方面的內(nèi)存占用量，使得我們可以用更多的內(nèi)存去排序。
第二個是新的基于Netty的網(wǎng)絡(luò)模塊取代了原有的NIO網(wǎng)絡(luò)模塊。這個新的模塊提高了網(wǎng)絡(luò)傳輸?shù)男阅?#xff0c;并且脫離JVM的GC自己管理內(nèi)存，降低了GC頻率。
第三個是一個獨(dú)立于Spark executor的external shuffle service。這樣子executor在GC的時候其他節(jié)點(diǎn)還可以通過這個service來抓取shuffle數(shù)據(jù)，所以網(wǎng)絡(luò)傳輸本身不受到GC的影響。

過去一些的參賽系統(tǒng)軟件方面的處理都沒有能力達(dá)到硬件的瓶頸，甚至對硬件的利用率還不到10%。而這次我們的參賽系統(tǒng)在map期間用滿了3GB/s的硬盤帶寬，達(dá)到了這些虛擬機(jī)上八塊SSD的瓶頸，在reduce期間網(wǎng)絡(luò)利用率到了1.1GB/s，接近物理極限。


參考文獻(xiàn)：
http://www.datastax.com/dev/blog/common-spark-troubleshooting
http://www.csdn.net/article/2014-11-06/2822505

-------------

更多的Java，Android，大數(shù)據(jù)，J2EE，Python，數(shù)據(jù)庫，Linux，Java架構(gòu)師，教程，視頻請?jiān)L問：

http://www.cnblogs.com/zengmiaogen/p/7083694.html

總結(jié)

以上是生活随笔為你收集整理的Spark 常见问题小结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。