【解決】處於ACCEPTED狀態不runnin…

Oozie提交pyspark任務後yarn 8088一直處於ACCEPTED狀態不運行runninghtml

這個問題困擾了我一個週末……一個週末……(而後其實後面又困擾了一週)node

並且重啓註銷,不懂是否是由於ubuntu kylin不穩定web

【結果】是由於單集羣的問題,致使yarn一次只能運行一個job。在服務器上跑就沒有事兒,在本身的虛擬機上跑就不行,由於沒配備多個虛擬機。——————【你覺得是這樣就大錯特錯了】apache

【真實緣由】未開啓yarn多線程模式,也就是scheduler爲單線程單隊列運行ubuntu

【解決】處於ACCEPTED狀態不running,Oozie提交pyspark任務後yarn <wbr>8088一直處於ACCEPTED狀態不運
  如圖,點開日誌能夠看到本身寫的py程序正確地輸出告終果。能夠點開log來看。這裏吐槽下,有些人忽視web界面的做用,以爲什麼都用yarn命令行來查就好……真的很不方便的。web還能自動給你歸類好,節省了大量無心義的工做,使你更專一解決exception等問題。

  至於爲何會出現一直ACCEPTED不RUNNING的結果,由於Oozie提交pyspark任務是經過mapreduce來提交的。它先提交一個mapreduce任務,而這個mapreduce任務裏面包含pyspark任務,形成2個任務同時在提交。若是yarn是單節點的,一次只能運行一個任務,那麼就悲劇了。mapreduce提交了pyspark,此時mapreduce任務在running中,yarn已經沒有slot給其它job了,而後,雖然pyspark已經ACCEPTED了但就是不能running。pyspark不running並結束,mapreduce也結束不了,沒法釋放資源給pyspark。
【解決】處於ACCEPTED狀態不running,Oozie提交pyspark任務後yarn <wbr>8088一直處於ACCEPTED狀態不運
  如何發現這樣的問題呢?你在yarn命令行經過kill命令殺掉那個mapreduce,而後spark的job就能正常運行並出來結果了。服務器

  那麼緣由既然是沒能2個job同時運行,那如何解決呢?咱們查看一直在ACCEPTED的job的application_id,鏈接到相應的log,會發現它一直在重複以下的信息,就是不RUNNING:多線程

INFO [communication thread] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1458755526820_9216_m_000000_0 is : 1.0併發

  會以爲這個yarn默認模式笨的感人。解決這個問題有2個方案,一個是配置多個隊列,第二個是配置一個FairScheduler。app

  有人就奇怪了,yarn自己不就是多線程的嗎?爲何會出現這個問題,這就要談到隊列的概念。在yarn裏面,提交任務須要指定queue(隊列)的:oop

 「使用過第一代hadoop的同窗應該比較熟悉mapred.job.map.capacity/mapred.job.reduce.capacity這個參數,不管是map仍是reduce均可以配置capacity(也就是併發數),表示同時能夠有多少個map(或reduce)運行,經過這個參數能夠限制一個任務同時佔用的資源(節點)數,這樣不至於影響其餘任務的執行。

  第二代hadoop由於使用yarn作資源管理,沒有了槽位的概念,因此就沒有了capacity。可是在yarn中專門有了CapacityScheduler這個組件。這是一個可插裝的調度器,它的用途就是對多用戶實現共享大集羣並對每一個用戶資源佔用作控制。

  對於很豪的公司來講,每一個用戶(團隊)本身有一個hadoop集羣,這樣能夠提升自身的穩定性和資源供應,可是確下降了資源利用率,由於不少集羣大多數時間都是空閒的。CapacityScheduler能實現這樣的功能:每一個組固定享有集羣裏的一部分資源,保證低保,同時若是這個固定的資源空閒,那麼能夠提供給其餘組來搶佔,可是一旦這些資源的固定使用者要用,那麼當即釋放給它使用。這種機制在實現上是經過queue(隊列)來實現的。固然CapacityScheduler還支持子隊列(sub-queue)。」——參考http://www.tuicool.com/articles/VNJNBr7

 

【解決方案】配置yarn多線程運行模式:

  若是一直顯示這樣的:

INFO [communication thread] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Progress of TaskAttempt attempt_1458755526820_9216_m_000000_0 is : 1.0

  那麼確實是調度器的問題。

  在可行的解決方案中,增長隊列可能沒那麼快,而修改調度器爲FairSchduler是比較現成和快的解決方案:

  修改yarn-site.xml文件,添加以下:

<!-- scheduler configuration, for multi-tasks run in queue, avoid mapreduce-run & pyspark ACCEPTED not run problem -->

    <property>

        <name>yarn.resourcemanager.scheduler.class</name>

        <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>

    </property>

    <property>

        <name>yarn.scheduler.fair.preemption</name>

        <value>true</value>

    </property>

<!-- 下面配置用來設置集羣利用率的閥值, 默認值0.8f,最多能夠搶佔到集羣全部資源的80% -->

    <property>

        <name>yarn.scheduler.fair.preemption.cluster-utilization-threshold</name>

        <value>1.0</value>

    </property>

  開啓公平調度器。以後咱們再在8088端口查看pyspark的job的時候,會發現,雖然剛開始依然處於ACCEPTED的狀態,但已經正常分配給擁有nodemanager節點的機子並初始化了。等一陣子後就開始RUNNING了。不再會發生卡殼的問題。

相關文章
相關標籤/搜索