E-MapReduce：常見問題

叢集有狀態重啟包括哪些內容？

叢集有狀態重啟包括RM Restart和NM Restart兩部分，ResourceManager（簡稱RM）負責維護應用級基礎資訊與狀態，NodeManager（簡稱NM）負責維護運行時的Container資訊與狀態，它們持續將相關狀態同步至外部儲存（Zookeeper、LevelDB和HDFS等），並在重啟後重新載入狀態自行恢複，保證叢集升級或重啟後應用自動回復，通常情況下可以做到應用無感知。

如何啟用RM HA？

如何配置熱更新？

1. 開啟關鍵配置。

   您可以在EMR控制台YARN服務的配置頁簽，檢查或者配置以下參數。

   參數	描述	參數值（推薦）
   yarn.scheduler.configuration.store.class	使用的備份存放區的類型。例如，設定為fs，表示使用FileSystem類型儲存。	fs
   yarn.scheduler.configuration.max.version	保留歷史版本的最大數量，超出自動清理。	100
   yarn.scheduler.configuration.fs.path	capacity-scheduler.xml檔案儲存體路徑。 不存在儲存路徑時，則自動建立。不指定首碼時，則預設defaultFs的相對路徑。	/yarn/<叢集名>/scheduler/conf 重要 將<叢集名>替換為叢集名稱以便區分，可能有多個YARN叢集對應同一分布式儲存的情況。

2. 查看capacity-scheduler.xml配置。

   • 方式一（REST API）：http://<rm-address>/ws/v1/cluster/scheduler-conf。

   • 方式二（HDFS檔案）：${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp>，其中尾碼<timestamp>值最大的檔案是最新的設定檔。

3. 更新配置。

   樣本：更新一個配置項yarn.scheduler.capacity.maximum-am-resource-percent，並刪除配置項yarn.scheduler.capacity.xxx，刪除某配置項只需去掉其Value值。

   curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
   {
     "global-updates": [
       {
         "entry": [{
           "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
           "value":"0.2"
         },{
           "key":"yarn.scheduler.capacity.xxx"
         }]
       }
     ]
   }'

如何處理Queue內應用程式指派不均？

如何查看隊列資源使用方式？

要查看隊列資源使用方式，您可以在YARN WebUI頁面查看Used Capacity參數。Used Capacity參數表示該隊列已使用的資源占該隊列整體資源的百分比，分別計算Memory和vCores佔總體的比例，並選取最大值作為隊列整體資源使用的比例。具體查看操作如下：

1. 訪問YARN UI，詳情請參見訪問連結與連接埠。

2. 在All Applications頁面，單擊目標作業的ID。

3. 單擊Queue行的隊列。

   在Application Queues地區，可以查看隊列資源使用方式。

   

YARN服務元件.out日誌為何會大量堆積且無法自動清理？

• 問題原因：Hadoop組件部分依賴庫使用Java Logging APIs來組建記錄檔記錄，不支援使用log4j配置的日誌輪轉。目前這些daemon組件的stderr輸出被重新導向到.out檔案中，沒有自動清理機制，長時間積累可能導致資料盤儲存空間被佔滿。

• 處理方法：可以使用head和tail命令結合日誌中產生的時間戳記資訊，來判斷是否由於Java Logging APIs產生的日誌導致儲存空間佔用過大。通常情況下，這些依賴庫產生的都是INFO層級日誌，不影響組件正常功能使用，但為了避免資料盤儲存空間被佔用，可以採取修改配置的方式禁用此類日誌的產生。

  例如，在最佳化TimelineServer組件以關閉jersey依賴庫的日誌產生時，操作步驟如下：

  1. 通過以下命令，監控YARN日誌路徑中與hadoop-timelineserver-相關的.out記錄檔。DataLake叢集的日誌路徑為/var/log/emr/yarn/，Hadoop叢集日誌路徑為/mnt/disk1/log/hadoop-yarn。

     tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

     觀察到輸出日誌中包含由com.sun.jersey組件產生的記錄。

     

  2. 為了禁止組件輸出Jersey庫的INFO層級日誌到.out 檔案，建立並配置一個檔案來關閉其日誌產生。在運行有TimelineServer組件的EMR節點上，可以通過執行以下命令以root許可權建立並編輯設定檔。

     sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

  3. 在EMR控制台中YARN服務的配置頁面，尋找YARN_TIMELINESERVER_OPTS參數（Hadoop叢集為yarn_timelineserver_opts），並在此參數值後添加-Djava.util.logging.config.file=off-logging.properties，指定剛剛建立的設定檔位置。

     

  4. 儲存上述配置更改後，重啟TimelineServer組件使新設定生效。持續觀察一段時間，如果TimelineServer組件正常啟動，並且.out日誌中不再出現任何與com.sun.jersey相關的日誌資訊，則說明關閉jersey依賴庫日誌的操作已成功完成。

如何檢查ResourceManager服務是否正常？

如何瞭解應用健全狀態？

應用問題排查流程

1. 檢查App狀態，通過App詳情頁或App REST API檢查App狀態。

   • 未找到App狀態，可能原因：

     • 用戶端向YARN提交之前失敗退出：用戶端組件問題（檢查提交用戶端日誌：BRS、flowagent等組件）。

     • 用戶端無法串連YARN RM：檢查串連RM地址是否正確、網路是否存在問題。如有網路問題，用戶端可能存在報錯：com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed。

   • NEW_SAVING：該狀態處於Zookeeper State Store寫入應用資訊階段。持續該狀態可能原因如下：

     • Zookeeper存在問題，檢查Zookeeper服務是否正常。

     • Zookeeper讀寫資料問題，處理方法請參見RM處於Standby狀態，無法自動回復Active狀態，該如何處理？。

   • SUBMITTED：該狀態極少遇到，可能原因為Node Update請求太多造成Capacity Scheduler內部搶鎖堵塞，通常發生在大規模叢集，需最佳化相關流程。相關案例，請參見YARN-9618。

   • ACCEPTED：檢查Diagnostics。請根據提示資訊，選擇相應的處理方式。

     • 報錯提示Queue's AM resource limit exceeded。

       • 可能原因：Queue AM已使用資源和AM資源之和超出了Queue AM資源上限，UI條件為${Used Application Master Resources} + ${AM Resource Request} < ${Max Application Master Resources}。

       • 處理方法：上調該Queue的AM資源上限。例如，設定參數yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent為0.5。

     • 報錯提示User's AM resource limit exceeded。

       • 可能原因：Queue user AM已使用資源和AM資源之和超出了Queue user AM資源上限。

       • 處理方法：提高user-limit比例。您可以修改參數yarn.scheduler.capacity.<queue-path>.user-limit-factor和yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent的參數值。

     • 報錯提示AM container is launched, waiting for AM container to Register with RM。

       • 可能原因：AM已啟動，內部初始化未完成（例如，Zookeeper連線逾時等）。

       • 處理方法：需要根據AM日誌進一步排查問題。

     • 報錯提示Application is Activated, waiting for resources to be assigned for AM。

       執行步驟3，檢查AM資源分派為何未滿足。

   • RUNNING：執行步驟2，檢查Container資源請求是否完成。

   • FAILED：檢查diagnostics。請根據提示資訊，選擇相應的處理方式。

     • 報錯提示Maximum system application limit reached,cannot accept submission of application

       • 可能原因：叢集內運行中的總應用數超過上限（配置項：yarn.scheduler.capacity.maximum-applications，預設值：10000）。

       • 處理方法：檢查JMX Metrics，確認各隊列啟動並執行應用數是否符合預期，找出並處理有大量重複提交的問題應用。如果應用都正常，可以根據叢集水位情況適當調大上述配置。

     • 報錯提示Application XXX submitted by user YYY to unknown queue: ZZZ

       • 可能原因：提交到不存在的queue。

       • 處理方法：提交到已存在的leaf queue。

     • 報錯提示Application XXX submitted by user YYY to non-leaf queue: ZZZ

       • 可能原因：提交到parent queue。

       • 處理方法：提交到已存在的leaf queue。

     • 報錯提示Queue XXX is STOPPED. Cannot accept submission of application: YYY

       • 可能原因：提交到STOPPED或DRAINING queue（已下線或正在下線的queue）。

       • 處理方法：提交到RUNNING queue（工作狀態正常的queue）。

     • 報錯提示Queue XXX already has YYY applications, cannot accept submission of application: ZZZ

       • 可能原因：queue應用數達到上限。

       • 處理方法：

         1. 檢查queue內是否有大量重複提交的問題應用。

         2. 調整配置：yarn.scheduler.capacity.<queue-path>.maximum-applications。

     • 報錯提示Queue XXX already has YYY applications from user ZZZ cannot accept submission of application: AAA

       • 可能原因：user應用數達到上限。

       • 處理方法：

         1. 檢查該user是否有大量重複提交的問題應用。

         2. 調整配置：yarn.scheduler.capacity.<queue-path>.maximum-applications、yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent、yarn.scheduler.capacity.<queue-path>.user-limit-factor。

2. 確認YARN資源分派還未完成。

   1. 在apps列表頁，單擊appID進入AM頁面。

   2. 單擊下方列表的AM-ID，進入AM-Attempt頁面。

   3. 查看Total Outstanding Resource Requests列表中是否有Pending資源（也可以通過PendingRequests REST API查詢）：

      • 沒有Pending資源：說明YARN已指派完畢，退出該檢查流程，檢查AM情況。

      • 有Pending資源：說明YARN資源分派未完成，繼續下一步檢查。

3. 資源限制檢查。

   檢查叢集或Queue資源，查看資源資訊，例如，Effective Max Resource和Used Resources。

   1. 檢查叢集資源或所在Queue資源或其父Queue資源是否已用完。

   2. 檢查葉子隊列某維度資源是否接近或達到上限。

   3. 當叢集資源接近用滿時（例如85%以上），應用的分配速度可能會變慢，因為大部分機器都沒有資源了，分配的機器沒有資源就會reserve，reserve到一定個數後分配就會變慢，另外也可能是由於記憶體資源和CPU資源不成比例，例如，有的機器上記憶體資源有空閑但CPU資源已經用滿，有的機器上CPU資源有空閑但記憶體已經用滿。

4. 檢查是否存在Container資源分派成功但啟動失敗的情況，YARN UI的App Attempt頁面可以看到已指派的Container數（間隔一小段時間觀察是否變化），如果有Container啟動失敗，查看對應的NM日誌或Container日誌進一步排查失敗原因。

5. 動態修改記錄層級：在YARN UI的logLevel頁面（http://RM_IP:8088/logLevel），將org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity（CapacityScheduler調度邏輯所在的package）參數的記錄層級改為DEBUG，如下圖所示。

   重要

   您需要在複現問題的同時開啟，持續幾十秒（由於日誌重新整理的很快，無需持續太長時間），記錄層級改回INFO即可恢複。

單任務/容器（Container）最大可用資源由哪些配置項決定？

YARN配置修改未生效，如何處理？

• 可能原因

  • 非熱更新配置，配置關聯的組件未重啟。

  • 熱更新配置，配置生效所需的指定操作未執行。

• 解決方案：請確保相關配置修改的後續操作正確執行。

  配置集	配置類型	更新後續操作
  capacity-scheduler.xml fair-scheduler.xml	調度器配置。	熱更新配置，需要執行RM組件的refresh_queues操作。
  yarn-env.sh yarn-site.xml mapred-env.sh mapred-site.xml	YARN組件回合組態。	重啟配置關聯組件。例如： 修改配置yarn-env.sh中的YARN_RESOURCEMANAGER_HEAPSIZE、yarn-site.xml中的yarn.resourcemanager.nodes.exclude-path等配置項後，需重啟RM。 修改配置yarn-env.sh中的YARN_NODEMANAGER_HEAPSIZE、yarn-site.xml中的yarn.nodemanager.log-dirs等配置項後，需重啟NM。 修改配置mapred-env.sh中的MAPRED_HISTORYSERVER_OPTS、mapred-site.xml中的mapreduce.jobhistory.http.policys等配置項後，需重啟MRHistoryServer。

用戶端異常，提示Exception while invoking getClusterNodes of class ApplicationClientProtocolPBClientImpl over rm2 after 1 fail over attempts. Trying to fail over immediately

• 問題現象：無法正常訪問Active ResourceManager。ResourceManager日誌異常，提示資訊：WARN org.apache.hadoop.ipc.Server: Incorrect header or version mismatch from 10.33.**.**:53144 got version 6 expected version 9。

• 問題原因：Hadoop版本太舊，導致用戶端RPC版本不相容。

• 處理方法：使用匹配的Hadoop版本。

RM處於Standby狀態，無法自動回復Active狀態，該如何處理？

RM組件OOM如何處理？

為什麼節點啟動任務時Localize失敗或任務日誌無法採集與刪除？

• 問題現象：NM日誌異常，提示java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider。

• 可能原因：HDFS配置異常。

• 處理方法：

  1. 以上是封裝後的異常，非根因，需要開啟DEBUG層級日誌查看：

     • hadoop用戶端命令列環境（例如執行hadoop fs -ls /命令），開啟DEBUG調試資訊。

       export HADOOP_LOGLEVEL=DEBUG

     • 有Log4j配置的運行環境，Log4j末尾增加log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG。

  2. 以下樣本的根因是使用者曾修改過NameServices配置，將emr-cluster修改為了hadoop-emr-cluster，但是擴容節點時使用了修改前的配置。

  3. 在EMR控制台HDFS服務的配置頁面，檢查各項配置是否正確。

資源本地化異常，該如何處理？

• 問題現象：

  • Job AM Container啟動失敗，異常資訊如下。

    Failed job diagnostics資訊為：Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted

  • 在資源本地化過程中（下載後解壓時）報錯，NodeManager日誌資訊如下。

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operation not permitted
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            at org.apache.hadoop.fs.DelegateToFileSystem.setPermission(DelegateToFileSystem.java:186)
            at org.apache.hadoop.fs.FilterFs.setPermission(FilterFs.java:235)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:949)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:945)
            at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
            at org.apache.hadoop.fs.FileContext.setPermission(FileContext.java:945)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:398)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:352)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:57)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)

• 問題原因：壓縮包內含有軟連結導致資源本地化異常。

• 處理方法：刪除該壓縮包內包含的軟連結。

Container啟動失敗或運行異常，報錯提示No space left on device，該如何處理？

節點NM服務或任務運行時無法正常解析網域名稱，該如何處理？

• 問題現象：報錯提示java.net.UnknownHostException: Invalid host name: local host is: (unknown)。

• 問題原因及處理方法：

  • 查看是否正確配置了DNS伺服器。

    通過以下命令，檢查配置資訊。

    cat /etc/resolv.conf

  • 查看防火牆是否設定了53連接埠的相關規則。

    如果設定了，請關閉防火牆。

  • 查看是否開啟了DNS的NSCD快取服務。

    通過以下命令，檢查服務狀態。

    systemctl status nscd

    如果開啟了DNS的NSCD快取服務，可以執行以下命令，停止快取服務。

    systemctl stop nscd

NM組件OOM如何處理？

ECS執行個體重啟後NM啟動失敗：cgroup目錄丟失，如何處理？

• 詳細異常資訊：ResourceHandlerException: Unexpected: Cannot create yarn cgroup Subsystem:cpu Mount point:/proc/mounts User:hadoop Path:/sys/fs/cgroup/cpu/hadoop-yarn

• 原因：ECS異常重啟可能是ECS核心缺陷（已知問題版本：4.19.91 -21.2.al7.x86_64）導致的。重啟後CPU cgroup失效問題，原因是重啟後cgroup的記憶體資料會被銷毀掉。

• 解決方案：修改存量叢集節點執行和擴容節點的引導指令碼，在當前環境中建立cgroup目錄並且用rc.local在以後ECS啟動的時候建立目錄。

  # enable cgroups
  mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
  chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
  # enable cgroups after reboot
  echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  chmod +x /etc/rc.d/rc.local

修改NM resource配置，儲存重啟後未生效，如何處理？

• 報錯說明：修改yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb參數，儲存重啟NM後，NM資源數未修改。

• 問題原因：由於機器組可能使用不同CPU記憶體規格的執行個體，所以修改yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb參數，需要修改節點群組維度配置才會生效。

• 解決方案：在EMR控制台，選擇節點群組維度，選擇需要配置的NM所在節點群組修改資源數的配置，具體操作請參見管理配置項。

節點出現Unhealthy問題，如何處理？

• 原因：

  • 磁碟檢查發現異常：當正常目錄數或總目錄數比率低於磁碟健康比例（yarn-site.xml配置項yarn.nodemanager.disk-health-checker.min-healthy-disks，預設值：0.25）時，將節點標記為UnHealthy。例如NM節點使用4塊磁碟，當4塊磁碟上的目錄均不正常時節點才會標記為UnHealthy，否則只在NM狀態報表中顯示local-dirs are bad或log-dirs are bad，參見節點磁碟問題：local-dirs are bad/log-dirs are bad，如何處理？。

  • NM健全狀態檢查指令碼發現異常：該項檢查預設未啟用，需要主動配置健全狀態檢查指令碼（yarn-site.xml配置項yarn.nodemanager.health-checker.script.path）才能開啟。

• 解決方案

  • 磁碟問題，請參見節點磁碟問題：local-dirs are bad/log-dirs are bad，如何處理？中的解決方案。

  • 健全狀態檢查指令碼問題，請根據自訂指令碼處理。

節點磁碟問題：local-dirs are bad/log-dirs are bad，如何處理？

• 原因：磁碟檢查發現異常。該項檢查預設開啟，周期性檢查local-dirs（任務運行緩衝目錄，包括任務運行依賴的各類檔案、中間資料檔案等）與log-dirs（任務作業記錄目錄，包含全部日誌運行）是否滿足以下條件，只要有一項不滿足就會被標記為bad。

  • 可讀

  • 可寫

  • 可執行

  • 磁碟空間使用率是否低於配置閾值（yarn-site.xml配置項yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage，預設：90%）

    磁碟剩餘可用空間是否大於磁碟最小可用空間的配置值（yarn-site.xml配置項yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb，預設：0）

• 解決方案

  • 一般都是磁碟空間不足引起，如果確認存在下述情境之一，建議擴容磁碟：

    • NM節點規格較大，可運行任務數較多。

    • 磁碟空間相對較小。

    • 任務運行所依賴的資料或檔案較大。

    • 任務運行產生的中間資料較多。

    • 任務日誌相對較大（磁碟空間佔比高）。

  • 檢查yarn-site.xml配置項yarn.nodemanager.localizer.cache.target-size-mb，如果相對磁碟比例過大會造成歷史任務緩衝佔用磁碟空間過多（超出配置值後才能自動清理）。

  • 壞盤問題，請參見自助壞盤維修流程更換叢集損壞的本地碟。

報錯提示User [dr.who] is not authorized to view the logs for application ***，該如何處理？

• 問題現象：開啟日誌頁面時，提示資訊如下。

• 問題原因：訪問NodeManager Log頁面時會檢查ACL規則。如果啟用了ACL規則，遠端使用者就要符合以下任一個條件：

  • 是admin使用者。

  • 是app owner。

  • 滿足app自訂ACL規則。

• 處理方法：檢查是否滿足以上條件中的任一條。

報錯提示HTTP ERROR 401 Authentication required或HTTP ERROR 403 Unauthenticated users are not authorized to access this page，該如何處理？

• 問題現象：訪問UI或REST API時報錯HTTP ERROR 401或HTTP ERROR 403。HTTP ERROR 401詳細資料如下圖。

  

• 問題原因：YARN啟用了Simple認證且不允許匿名訪問，詳情請參見Authentication for Hadoop HTTP web-consoles。

• 處理方法：

  • 方式一：URL參數中顯示指定遠端使用者，例如，user.name=***。

  • 方式二：您可以在E-MapReduce控制台的HDFS服務的配置頁簽，在搜尋地區搜尋參數hadoop.http.authentication.simple.anonymous.allowed，修改其參數值為true允許匿名訪問，參數含義請參見Authentication for Hadoop HTTP web-consoles。然後重啟服務，請參見重啟服務。

為什麼TotalVcore顯示值不準確？

在YARN UI右上方，Cluster或Metrics REST API結果中，TotalVcore顯示值不準確。此問題是由於社區2.9.2之前版本TotalVcore計算邏輯有問題，詳情請參見https://issues.apache.org/jira/browse/YARN-8443。

EMR-3.37.x和EMR-5.3.x及後續版本已修複此問題。

TEZ UI展示的應用資訊不全，該如何處理？

為什麼YARN UI頁面有一個正在啟動並執行Spark Thrift JDBC/ODBC Server任務？

如果您在建立叢集時選擇了Spark服務，叢集會自動啟動一個預設的Spark Thrift Server服務。該服務會佔用一個YARN Driver的資源。在Spark Thrift Server中啟動並執行任務，預設會通過該Driver向YARN申請所需的資源。

yarn.timeline-service.leveldb-timeline-store.path是否支援使用OSS地址？

yarn.timeline-service.leveldb-timeline-store.path參數不支援使用OSS地址。

如果您建立的是Hadoop叢集，則yarn.timeline-service.leveldb-timeline-store.path的預設值與hadoop.tmp.dir參數相同。請不要修改HDFS的hadoop.tmp.dir參數，因為這會影響yarn.timeline-service.leveldb-timeline-store.path的配置。

Timeline Server連線逾時、CPU或Memory佔用異常高問題，該如何處理？

在Tez任務特別多的情況下，寫入YARN的Timeline Server時，可能會出現連線逾時的問題。這是因為Timeline Server進程佔用大量CPU導致節點CPU使用率達到極限，進而影響到了作業開發和其他非核心業務（例如報表產生），所以臨時停止TimelineServer進程來減輕節點的CPU負載。您可以通過修改以下配置項來解決此問題。

在EMR控制台修改Tez和YARN服務的相應配置，新增或修改配置的具體操作，請參見管理配置項。

1. 在EMR控制台Tez服務的配置頁面的tez-site.xml頁簽，新增參數為tez.yarn.ats.event.flush.timeout.millis，參數值為60000的配置項，該參數用來設定Tez任務將事件寫入YARN的Timeline Server時的逾時時間。

2. 在EMR控制台YARN服務的配置頁面的yarn-site.xml頁簽，新增或修改以下配置項。修改完配置項後需要在YARN服務的狀態頁面重啟下TimelineServer。

   參數	參數值	說明
   yarn.timeline-service.store-class	org.apache.hadoop.yarn.server.timeline.RollingLevelDBTimelineStore	用於指定YARN Timeline Server的事件儲存類。
   yarn.timeline-service.rolling-period	daily	用於設定YARN Timeline Server的事件滾動周期
   yarn.timeline-service.leveldb-timeline-store.read-cache-size	4194304	用於設定YARN Timeline Server LevelDB儲存的讀取緩衝大小。
   yarn.timeline-service.leveldb-timeline-store.write-buffer-size	4194304	用於設定YARN Timeline Server LevelDB儲存的寫入緩衝區大小。
   yarn.timeline-service.leveldb-timeline-store.max-open-files	500	用於設定YARN Timeline Server LevelDB儲存的最大開啟檔案數。