Impala事故处理手册

Impala事故处理手册

本文不是事故原因汇总，只介绍当Impala集群出现事故时的处理流程，以最大限度保留现场信息，方便事后调查。关于如何搜索已知问题，可参考《如何在Apache JIRA中搜索issue》一文。

本文第一节介绍故障表现和对应的操作建议，第二节介绍每个操作的具体执行流程。本文将不定期更新，欢迎留言反馈具体的故障场景。

1. 故障表现

1.1 大量查询处于CREATED状态

如果coordinator有大量 “waiting for metadata” 的日志，挑几个提及的表去查catalogd日志，结合jstack分析。
如果CREATED状态的大部分是DDL/DML，也是查catalogd日志，结合jstack分析。

定位不了问题可以关闭可疑的表对应的application，收集profile、coordinator和catalogd日志以及catalogd的jstack，重启catalogd。

1.2 Catalog Server OOM

首先要排除假的OOM，即内存够用，但日志里显示OOM错误，报错一般从 ByteArrayOutputStream.hugeCapacity 或类似的函数抛出。这类是因为申请了超过2GB的byte array，需要优化对应大表的元数据，不属于本条事故类型。

排除是申请超过2GB byte array报的OOM后，收集catalogd的jstack、jmap heap dump，时间来得及的话收集内存使用直方图信息，最后提高Xmx重启catalogd。

如果是类似的JVM内存问题，如频繁Full GC，也适用本条。

1.3 Impalad crash

如果是CM管理的集群，一般会自动重启impalad。在图表里有Unexpected Exit会显示多少台挂了。

备份日志（包括所有coordinator和crash的executor）、minidump文件、CM图表里相关的Impala图表。

1.4 疑似内存泄漏

如果发现进程rss值一直增加，可以用pprof做内存分析，同时最好收集Web UI信息和pstack，如果是catalogd的话还要收集jstack。具体操作见后面的操作汇总。

1.5 Impalad日志报错 “Could not acquire lock for topic catalog-update. Skipping update”

该日志表示Impalad无法apply statestore发来的catalog update，因为上一个catalog update还在处理中，占着锁。可以打jstack看看updateCatalog的堆栈卡在哪了，找不到的话再打pstack找对应的堆栈。

1.6 Catalogd/Impalad启动报错 “NoClassDefFoundError: org.apache.hadoop.fs.FileSystem”

检查CLASSPATH是否明确包含了该类所在的jar包，org.apache.hadoop.fs.FileSystem对应的是hadoop-common-xxx.jar。如果CLASSPATH没问题，检查配置文件log4j.properties、core-site.xml等是否在CLASSPATH某个目录中，权限是否可读等。具体排查参考这篇文章。

2. 操作汇总

2.1 收集jstack

Catalog Server (catalogd) 和 Impalad 都有 JVM，当出现服务卡死或响应很慢时，需要收集jstack信息。使用和进程所用jdk对应的jstack，并且切换到进程所用的username来操作。比如CM管理的Impala服务，都是用 “impala” 这个用户名来启动的，jstack操作示例：

export JAVA_HOME=/usr/java/jdk1.8.0_232-cloudera
export PATH="$JAVA_HOME/bin:$PATH"
sudo -E -u impala jstack $(pidof catalogd) > catalogd.jstack.txt

若无响应或失败，增加 -F 参数：

sudo -E -u impala jstack -F $(pidof catalogd) > catalogd.jstack.txt

如果服务不是卡死，可循环采集多轮，如

while true; do sudo -E -u impala jstack $(pidof catalogd) >> catalogd.jstack.txt; done

注：如果是服务响应慢（性能问题），打jstack时尽量不要加 -l (小写L) 或 -F 参数，因为会显著增加JVM pause的时间。观察日志里的JvmPauseMonitor信息以确定它们的影响。

2.2 收集jmap信息

当发现服务的JVM内存使用异常时，如频繁Full GC或OOM时，需要采集jmap信息。需要注意的是，有一类OOM是byte array大小超过2GB引发的，这类不算JVM内存使用异常，收集jmap信息没用。

jmap可以收集JVM内存占用的直方图（histogram），也可以打heap dump，生成的文件用Eclipse MAT之类的分析工具做深入调查。注意使用同款jdk里的jmap。

2.2.1 内存占用直方图

收集内存占用直方图：

export JAVA_HOME=/usr/java/jdk1.8.0_232-cloudera
export PATH="$JAVA_HOME/bin:$PATH"
sudo -E -u impala jmap -histo $(pidof catalogd) > catalogd.jmap-histo.txt

如果JVM堆不大，或者日志里JvmPauseMonitor显示的GC pause时间不长，可以再采集 histo:live（会触发Full GC）

sudo -E -u impala jmap -histo:live $(pidof catalogd) > catalogd.jmap-histo-live.txt

2.2.2 JVM heap dump

注意找一个剩余空间大的目录操作（df -h查看磁盘使用信息），以防写满磁盘。以下示例在当前目录生成heap dump文件catalogd.hprof

export JAVA_HOME=/usr/java/jdk1.8.0_232-cloudera
export PATH="$JAVA_HOME/bin:$PATH"
sudo -E -u impala jmap -dump:live,format=b,file=catalogd.hprof $(pidof catalogd)

2.3 收集pstack

如果impalad无响应，或者发现某个线程疑似死循环，需要收集pstack。没有pstack指令的话可以安装gdb，就会有pstack。

对整个进程收集pstack会比较耗时：

sudo pstack $(pidof impalad) > impalad.pstack.txt

通过 “top -H -p $(pidof impalad)” 之类的指令可以查看哪些线程占用较高的CPU，也可以在WebUI的threadz页面找特定的线程ID。然后再收集单个线程的pstack会轻一些：

sudo pstack threadId > impalad.pstack.txt

pstack执行出问题时可能忽略了报错，这时可以用对应的gdb指令：

sudo gdb -p PID -ex 'thread apply all bt' -ex 'set confirm off' -ex 'quit' > impalad.pstack.txt

2.4 保留WebUI信息

Impala的Web UI展示了不少信息，都可以在 URL 加 “?json” 后缀的方式获取json形式的数据。如

wget "http://impalad_host:25000/metrics?json" -O impalad.metrics.txt
wget "http://impalad_host:25000/memz?json" -O impalad.memz.txt
wget "http://impalad_host:25000/jmx?json" -O impalad.jmx.txt
wget "http://impalad_host:25000/rpcz?json" -O impalad.rpcz.txt
wget "http://impalad_host:25000/queries?json" -O impalad.queries.txt
wget "http://impalad_host:25000/sessions?json" -O impalad.sessions.txt
wget "http://impalad_host:25000/admission?json" -O impalad.admission.txt

threadz页面显示的是累积信息，如累积的user time、sys time、iowait。需要多采集几次以后才能看增量，而且URL略有不同：“http://impalad_host:25000/thread-group?all&json”

以下指令采集100次：

for i in `seq 100`; do wget "http://impalad_host:25000/thread-group?all&json" -O impalad.threads.${i}.txt; (date && date +%s%N) >> impalad.threads.${i}.txt; sleep 0.5; done

2.5 备份日志

日志保留时间稍长，可以在上述步骤都做完后再备份。备份位置应选跟根目录（即 “/” 目录）不同的磁盘上的目录，以防日志占满根目录磁盘造成系统故障。

下面列出了各个服务对应的目录位置：

• catalogd日志一般位于 /var/log/catalogd/
• statestore日志位于 /var/log/statestored/
• impalad 日志位于 /var/log/impalad/
• HMS 日志位于 /var/log/hive/
• NameNode 日志位于 /var/log/hadoop-hdfs

实际位置以实际配制为准。

2.6 备份profile

Impala的profile都会保存在coordinator本地，这个留存时间会比Web UI（默认100个）或CM里的更长，当找不到查询时可以在coordinator本地的profile文件里找到。目录一般位于日志目录下的profiles子目录，如 /var/log/impalad/profiles，可由 --profile_log_dir配置。

profile文件里一行是一个查询，格式是明文的query id和base64编码的profile。要找某个查询时可以把对应的那行复制出来单独成为一个文件，然后用impala-profile-tool转成text profile。

事先没有编译impala-profile-tool的话也可以用docker镜像：

docker pull apache/impala:4.0.0-impala_profile_tool
cat my_profile | docker run -i apache/impala:4.0.0-impala_profile_tool > my_profile.txt

2.7 备份minidump文件

impalad crash时一般会生成minidump文件，文件名如 7dd118b5-fd6a-9098-79215292-715fcff9.dmp，在日志中可以找到。

备份好对应的minidump文件，可用gzip压缩节省空间。

2.8 pprof 内存分析

Impala集成了pprof，可以做CPU和内存的分析，参考文档：
https://cwiki.apache.org/confluence/display/IMPALA/Collecting+Impala+CPU+and+Heap+Profiles

做内存分析时，可以用wget先抓取一定量的profile，如

for i in `seq 60`; do wget http://hostname:25000/pprof/heap; done

以上指令抓取60次heap profile，每次需要30秒，总共耗时30分钟。wget会自动重命名文件，所以最终得到的文件是 heap, heap.1, heap.2, …, heap.59

把这些文件打包压缩，传到另一台空闲机器上做分析。分析的机器需要设置好环境，比如确保安装了相同版本的jdk，以及安装了 gperftools、cyrus-sasl 等依赖。比如在CentOS7里：

yum install -y gperftools cyrus-sasl-plain cyrus-sasl-gssapi

还需要复制线上环境的impalad可执行文件，然后使用pprof生成text或pdf报告：

pprof --text /opt/cloudera/parcels/CDH/lib/impala/sbin-retail/impalad ./heap.40 > heap.40.txt
pprof --pdf /opt/cloudera/parcels/CDH/lib/impala/sbin-retail/impalad ./heap.40 > heap.40.pdf