oozie提交pyspark任務後yarn 8088一直處於accepted狀態不執行running
這個問題困擾了我乙個週末……乙個週末……（然後其實後面又困擾了一周）
而且重啟登出，不懂是不是因為ubuntu kylin不穩定
【結果】是因為單集群的問題，導致yarn一次只能執行乙個job。在伺服器上跑就沒有事兒，在自己的虛擬機器上跑就不行，因為沒配備多個虛擬機器。——————【你以為是這樣就大錯特錯了】
【真實原因】未開啟yarn多執行緒模式，也就是scheduler為單執行緒單佇列執行
如圖，點開日誌可以看到自己寫的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。
如何發現這樣的問題呢？你在yarn命令列通過kill命令殺掉那個mapreduce，然後spark的job就能正常執行並出來結果了。
info [communication thread] org.apache.hadoop.mapred.taskattemptlistenerimpl: progress of taskattempt attempt_1458755526820_9216_m_000000_0 is : 1.0
會覺得這個yarn預設模式笨的感人。解決這個問題有2個方案，乙個是配置多個佇列，第二個是配置乙個fairscheduler。
有人就奇怪了，yarn本身不就是多執行緒的嗎？為什麼會出現這個問題，這就要談到佇列的概念。在yarn裡面，提交任務需要指定queue（佇列）的：
「使用過第一代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）。」——參考
【解決方案】配置
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檔案，新增如下：
yarn.resourcemanager.scheduler.class
org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.fairscheduler
yarn.scheduler.fair.preemption
true
yarn.scheduler.fair.preemption.cluster-utilization-threshold
1.0
開啟公平排程器。之後我們再在8088埠檢視pyspark的job的時候，會發現，雖然剛開始依然處於accepted的狀態，但已經正常分配給擁有nodemanager節點的機子並初始化了。等一陣子後就開始running了。再也不會發生卡殼的問題。
*************************====無關的探索*************************===
ps：為了解決這個accepted問題，一直以為是沒有更改原始碼使其支援py，所以總想著重新編譯。而重新編譯又想著是不是更新下內部軟體比較好呢？於是修改了kryo的版本，修改了tomcat的版本，結果編譯期間各種出問題。
【問題unexpected end of zlib input stream】
這個只能重新解壓原始碼，配置一遍再重新編譯。第二次編譯就好了。問題的原因可能是之前編譯到一半各種雜七雜八的編碼問題導致建立壓縮包失敗。
【問題jasperlistener】
19-feb-2017 10:23:11.868 warning [main] org.apache.catalina.startup.catalina.load catalina.start using conf/server.xml: error at (28, 67) : org.apache.catalina.core.jasperlistener
19-feb-2017 10:23:11.875 severe [main] org.apache.tomcat.util.digester.digester.startelement begin event threw exception
ｊａｖａ.lang.classnotfoundexception: org.apache.catalina.core.jasperlistener
進oozie-server/conf把jasperlistener注釋掉。同理注釋掉：
參考類推：
【問題 ioexception could not authenticate, authentication failed】
啟動oozie後，查詢status遇到
ioexception: error w hile connecting oozie server. no of retries = 1. exception = could not authenticate, authentication failed, status: 500, message: null
最後咋解決都不行，老老實實編譯回tomcat 6可以用了
編譯完成後別忘了prepare war。舊的sql資料應該可以繼續用，把配置檔案直接遷移過來就好
*************************====無關的探索******************************
附錄：１、關於公平排程器的介紹：
…………排程器將作業組織放入很多「佇列」，這些佇列會公平的共享所有的集群資源。預設情況下，所有的使用者共享乙個名叫「de****t」的佇列。如果乙個作業指定請求某個佇列，那麼這個作業將被提交到該佇列。另外，通過配置可以根據提交作業的使用者來分配進入相應的佇列。在每個佇列內部，同樣有乙個排程策略排程在每個佇列中執行的作業，預設的策略是基於記憶體的公平分配，但是也可以配置成fifo或者基於不同型別資源的公平分配。佇列可以按照層次結構來劃分資源，並和權重一起按照一定的比例共享集群資源…………
保持numlock處於開啟狀態
比較實用的東東，不然每次都自己去按numlock也很煩 字元終端下開啟numlock for tty in dev tty 1 6 dosetleds d num tty done 將上面的語句加入到系統啟動的指令碼中,比如 etc rc.d rc.local,加在結尾處就可以啦。x下開啟numlo...
C 如何判斷檔案處於開啟狀態
對於應用程式，有時候可能需要判斷某個檔案是否已經被開啟，也就是指是否被某個流連接著。這在對檔案的讀寫比較頻繁的程式中尤為重要，因為乙個檔案同一時刻只能有乙個流連線的。下面的 也許能有所幫助。csharp view plain copy print?public class filestatus in...
C 判斷主機是否處於聯網狀態
直接讓本機訪問乙個 如果成功的話，就說明成功聯網，沒有訪問成功，則說明沒有聯網！include include pragma comment lib,ws2 32.lib define len 1024 接收資料的大小 using namespace std int main if lobyte w...