本文汇总了Kudu使用时的常见问题。

在哪里查看Kudu的日志文件？

Kudu日志文件路径在/mnt/disk1/log/kudu下。

Kudu支持的分区方式有哪些？

Kudu支持Range分区方式以及Hash分区方式，两种分区方式可以嵌套使用，详情请参见Apache Kudu Schema Design。

如何访问Kudu WebUI？

因为Kudu WebUI与Knox还没有集成，所以不能通过Knox查看Kudu WebUI。您可以通过隧道的方式访问Kudu的WebUI，详情请参见通过SSH隧道方式访问开源组件Web UI。

Kudu客户端连接报错NonRecoverableException

  • 报错详情
    报错详细信息，如下所示。
    org.apache.kudu.client.NonRecoverableException: Could not connect to a leader master. Client configured with 1 master(s) (192.168.0.10:7051) but cluster indicates it expects 3 master(s) (192.168.0.36:7051,192.168.0.11:7051,192.168.0.10:7051)
  • 问题原因

    此问题主要是因为在设置Master节点时，只设置了一个Master节点的信息，程序会找不到主Master节点。

  • 解决方法

    您在进行此配置时，需要配置所有Master节点的信息。

如何查看社区FAQ？

可以查看社区的Apache Kudu Troubleshooting。

报错Bad status: Network error: Could not obtain a remote proxy to the peer.: unable to resolve address for <hostname>: Name or service not known

  • 问题原因：无法解析<hostname>，导致kudu tablet的raft server不能获取自己的peer机器类型，不清楚是否存活，所以终止。
  • 解决方法：
    1. 在/etc/hosts中手动添加解析。
    2. 如果<hostname>所代表的机器已经被释放了，可以在/etc/hosts中添加解析到随便一个IP上，无论该IP是否可以访问，之后kudu tserver走Replica恢复的流程。

报错Bad status: I/O error: Failed to load Fs layout: could not verify integrity of files: <目录>, <数字> data directories provided, but expected <数字>

该问题是由于-fs_data_dirs设置的磁盘数目与-fs_metadata_dir记录的元数据不一致。直接将-fs_data_dirs的磁盘数目修改为与元数据匹配的即可。

报错pthread_create failed: Resource temporarily unavailable (error 11)

该问题是因为没有资源了，导致线程创建失败。

  • 没有资源

    需要通过ulimit -a确认下max user processes的值，是否是比较小的一个值。如果比较小，则需要修改/etc/security/limits.conf或者增加一个/etc/security/limits.d/kudu.conf文件，在其中增加对max user processes值的修改。

  • 混部的情况下，使用了Kudu client 0.8版本

    根据KUDU-1453，Spark executor使用kudu client 0.8可能会造成线程泄漏，先考虑升级到0.9及以上是否能够解决。

  • 线程泄漏
    • Trino导致的问题

      主要是由于Trino退出的时候，shutdown hook里面等待blocking queue的take方法有返回，shutdown hook线程不会被interrupt，而EMR管控又会不断的发SIGTERM创建出来新的SIGTERM Handler线程，因此导致了线程的耗尽。

      需要Trino侧解决，或者直接执行Kill -9命令。

    • Jindo SDK导致的问题

      这是由于Spark在执行Write Job的时候会用到JindoOssCommitter这个类，这个类会创建JindoOssMagicCommitter，并在其中生成一个名为oss-committer-pool的线程池。该线程池并不是static的，并且也没有被手动shutdown。因此，在不断的创建JindoOssMagicCommitter的过程中，会不断的产生新的线程池，而老的线程池因为各种原因，也没有被释放，因此会使用过量的线程。如果此时您使用的是Spark Streaming或Structure Streaming，则可能使得系统资源耗尽。

      您可以设置以下参数解决。
      spark.sql.hive.outputCommitterClass=org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter
spark.sql.sources.outputCommitterClass=org.apache.hadoop.mapreduce.lib.output.FileOutputCommitter
    • 排查工具
      通过执行以下threads_monitor.sh脚本，来查找系统中使用最多线程的进程是什么，然后再解决问题。
      #!/bin/bash

total_threads=0
max_pid=-1
max_threads=-1

for tid in `ls /proc`
do
  if [[ $tid != *self && -f /proc/$tid/status ]]; then
    num_threads=`cat /proc/$tid/status | grep Threads | awk '{print $NF}'`
    ((total_threads+=num_threads))
    if [[ ${max_pid} -eq -1 || ${max_threads} -lt ${num_threads} ]]; then
      max_pid=${tid}
      max_threads=${num_threads}
    fi
#    echo "Thread ${pid}: ${num_threads}"
  fi
done

echo "Total threads: ${total_threads}"
echo "Max threads: ${max_threads}, pid is ${max_pid}"
ps -ef | grep ${max_pid} | grep -v grep

启动Kudu失败，该如何处理？

使用Kudu时，bigboot提供的bigboot monitor进行启动、运行、失败自动拉起等操作。bigboot 3.5.0版本存在缺陷。如果kudu异常退出，则无法删除数据库中的服务信息，导致后面无法再拉起。此时您需要先stop再start即可。
说明 需要在机器中操作，控制台可能会由于服务已经终止了，不会执行stop操作。
您可以在Worker节点执行以下命令。如果您是在Header节点执行以下命令，请替换命令中的kudu-tserver为kudu-master。
/usr/lib/b2monitor-current/bin/monictrl -stop kudu-tserver
/usr/lib/b2monitor-current/bin/monictrl -start kudu-tserver

报错Service unavailable: RunTabletServer() failed: Cannot initialize clock: timed out waiting for clock synchronisation: Error reading clock. Clock considered unsynchronized

  • 报错详情
    日志中可能会有如下错误信息。
    E1010 10:37:54.165313 29920 system_ntp.cc:104] /sbin/ntptime
------------------------------------------
stdout:
ntp_gettime() returns code 5 (ERROR)
  time e6ee0402.2a452c4c  Mon, Oct 10 2022 10:37:54.165, (.165118697),
  maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 187.830 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16000000 us,
  status 0x2041 (PLL,UNSYNC,NANO),
  time constant 6, precision 0.001 us, tolerance 500 ppm,
  • 问题原因：机器上的ntpd无法连接到所配置的ntp server。
  • 解决方法：请尝试重启解决。

报错Rejecting Write request: Soft memory limit exceeded

  • 报错原因：超过Soft memory limit。
  • 解决方法
    您可以进行以下操作：
    1. 设置参数memory_limit_hard_bytes，整体调大内存使用量，默认值是0，代表根据系统自动设置，也可以调整为-1，则表示不做任何限制。
    2. 设置参数memory_limit_soft_percentage，表示可使用内存的比例，默认值是80。