问题分析报告--读取ORC文件报seek错误
1、問題描述
1.1?基本信息[Basic Information]
- 集群規(guī)模：37+3臺物理機(jī)，每臺128G內(nèi)存；CPU：2*16C；SATA磁盤，2T*12
- hadoop社區(qū)版本：**
- 商業(yè)版本：FusionInsight_HD_V100R002C60U10
- MetaStore：高斯數(shù)據(jù)庫（Postgresql）
1.2 問題描述[Problem Description]
- C60U10版本YARN集群在高并發(fā)任務(wù)狀態(tài)下運(yùn)行2天左右可能導(dǎo)致NM資源本地化性能下降，進(jìn)而導(dǎo)致任務(wù)整體執(zhí)行效率下降。
2、問題分析[Problem Analysis]
1. 分析job性能變慢，主要體現(xiàn)為Container localized執(zhí)行變慢
Task Slow logs:
?
Task Quick logs:
通過分析日志發(fā)現(xiàn), container 執(zhí)行變慢主要卡在ResourceLocalizationService鎖的競爭上：
?
下圖為隨機(jī)挑選出來的一個container運(yùn)行慢的時候的jstack打印信息，發(fā)現(xiàn)這個container等待這個鎖等待了22s之久：
?
2. 分析鎖內(nèi)代碼執(zhí)行慢的原因：
通過獲取操作系統(tǒng)的統(tǒng)計數(shù)據(jù)osinfo，發(fā)現(xiàn)在container localized過程中會調(diào)用ls命令獲取本地目錄的文件基本信息出現(xiàn)了X狀態(tài)（Linux process state: X (TASK_DEAD - EXIT_DEAD), the exit status, the process is about to be destroyed.），該狀態(tài)被捕捉多次，說明這個命令執(zhí)行在os層占用時間較長。
?
?
3. 排查ls變慢的原因，發(fā)現(xiàn)NM的堆外內(nèi)存持續(xù)增長
1） NM的內(nèi)存使用持續(xù)增長：
?
2）通過打印NM的堆外內(nèi)存使用，發(fā)現(xiàn)大部分堆外內(nèi)存使用均來自leveldb，內(nèi)存分析截圖如下：
利用pmap命令將NM使用的內(nèi)存信息dump下來，然后用gdb將指定尋址空間的堆外內(nèi)存dump到本地：
?
通過將二進(jìn)制內(nèi)存文件轉(zhuǎn)化為可見字符，可知，當(dāng)前的堆外內(nèi)存主要來自leveldB。
4. NM堆外內(nèi)存的持續(xù)上漲到一定程度后，會導(dǎo)致NM內(nèi)部調(diào)用os的命令執(zhí)行變慢，從而導(dǎo)致YARN的NM的container本地化鎖競爭加劇，最終導(dǎo)致業(yè)務(wù)性能下降。最后，通過在生產(chǎn)環(huán)境上將NM的recovery特性關(guān)閉，消除了levelDB導(dǎo)致堆外內(nèi)存持續(xù)上漲的問題，從而解決了業(yè)務(wù)執(zhí)行48小時后會出現(xiàn)性能下降的問題。
3、根本原因[Root Cause]
分析為YARN的recovery特性會依賴leveldb，而leveldb的數(shù)據(jù)存儲會占用堆外內(nèi)存，從而導(dǎo)致堆外內(nèi)存上漲，當(dāng)堆外內(nèi)存的堆積會導(dǎo)致os占用內(nèi)存無法及時的釋放，而在大量任務(wù)并發(fā)時，業(yè)務(wù)也需要占用大量內(nèi)存，內(nèi)存的緊張會導(dǎo)致任務(wù)在資源本地化的過程中執(zhí)行os的“l(fā)s ?-ld” 命令變慢；同時每個contaienr的localized地方存在鎖的競爭，命令執(zhí)行變慢，會使該鎖的競爭惡化，從而表現(xiàn)在業(yè)務(wù)運(yùn)行一段時間后，性能逐漸變慢。
4、解決措施[Corrective Action]
4.1 最終解決措施[Solution]
?4.2?最終解決措施[Solution]
5、解決措施[Corrective Action]
4.1 最終解決措施[Solution]
1. 觀察系統(tǒng)內(nèi)存占用情況，檢查是否存在內(nèi)存使用異常 2. 通過如下手段排查，確定是否是同一問題： 1） 確認(rèn)是否開啟NM的recovery特性（yarn.nodemanager.recovery.enabled：true）； 2） 通過top -p PID查看NM進(jìn)程的內(nèi)存RES使用是否超過JVM堆內(nèi)存的2倍以上； 3） 查看{yarn.nodemanager.recovery.dir}/yarn-nm-state目錄下的xx.sst文件數(shù)目是否超過2000+； 注：{yarn.nodemanager.recovery.dir}在NM的后臺配置文件中查看： /opt/huawei/Bigdata/FusionInsight/etc/x_x_NodeManager/yarn-site.xml（其中x表示某一數(shù)字） <property> <name>yarn.nodemanager.recovery.dir</name> <value>/srv/BigData/tmp/yarn-nm-recovery</value> </property> 4） NM日志中排查是否有大量的“Localizer failed”、“InterruptedException”； 3. 如確認(rèn)是同一問題，請參照5.1臨時規(guī)避。總結(jié)
以上是生活随笔為你收集整理的问题分析报告--读取ORC文件报seek错误的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 测试人生的最大危机不是 35 岁，是你工
- 下一篇： Qt输出4位大字十六进制，不足4位左边补