Kudu故障排除

原文链接 : http://kudu.apache.org/docs/troubleshooting.html

译文链接 : http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813626

贡献者 : 小瑶ApacheCNApache中文网

启动错误

Errors During Hole Punching Test ( 穿透测试中的错误 )

Kudu 需要 hole punching capabilities ( 穿透能力 ) 才能有效。穿透支持取决于您的操作系统内核版本和本地文件系统实现。

• RHEL 或 CentOS 6.4 或更高版本，修补到 2.6.32-358 或更高版本的内核版本。未配置的 RHEL 或 CentOS 6.4 不包括支持穿透的内核。
• Ubuntu 14.04 包括 Linux 内核的 3.13 版本，它支持打孔。
• 较新版本的 EXT4 或 XFS 文件系统支持穿透，但 EXT3 不支持。旧版本的 XFS 不支持穿透返回 EOPNOTSUPP （操作不支持）错误。不支持穿透的 EXT4 或 XFS 的较旧版本会导致 Kudu 发出以下错误消息，并且无法启动：

穿透试验时出错日志块管理器需要一个具有穿透支持的文件系统，如 ext4 或 xfs 。在 el6 上，内核版本 2.6.32-358 或更新版本是必需的。不使用穿透时（以某种效率和可扩展性为代价），重新配置 Kudu 与 --block_manager = file。有关更多信息，请参阅 Kudu 文档细节。原始错误消息如下。

没有穿透支持，日志块管理器不安全使用。它不会删除块，并将消耗更多的磁盘空间。

即使你的环境中无法使用穿透，你仍然可以尝试 Kudu 。通过将 --block_manager = file 标志添加到用于启动主服务器和tablet server的命令，启用文件块管理器而不是日志块管理器。文件块管理器不会与日志块管理器一样缩放。

注意

由于文件块管理器的规模和性能不佳，只能用于小规模的评估和开发。

NTP Clock Synchronization ( NTP 时钟同步 )

对于主服务器和平板电脑服务器守护程序，必须使用 NTP 同步服务器的时钟。另外，最大时钟误差（不要误估为误差）低于可配置的阈值。默认值为 10 秒，但可以使用标志 --max_clock_sync_error_usec 设置。

如果未安装 NTP ，或者如果时钟被报告为不同步，则 Kudu 将不会启动，并会发出如下消息：

F0924 20:24:36.336809 14550 hybrid_clock.cc:191 Couldn't get the current time: Clock unsynchronized. Status: Service unavailable: Error reading clock. Clock considered unsynchronized.


如果 NTP 安装并同步，但最大时钟错误太高，用户将看到如下消息：

Sep 17, 8:13:09.873 PM FATAL hybrid_clock.cc:196 Couldn't get the current time: Clock synchronized, but error: 11130000, is past the maximum allowable error: 10000000


或者

Sep 17, 8:32:31.135 PM FATAL tablet_server_main.cc:38 Check failed: _s.ok() Bad status: Service unavailable: Cannot initialize clock: Cannot initialize HybridClock. Clock synchronized but error was too high (11711000 us).


重要

如果已安装 NTP ，用户可以通过运行 ntptime 来监视同步状态。相关值是报告的最大误差。

要安装 NTP ，请对您的操作系统使用相应的命令：

如果 NTP 已安装但未运行，请使用以下命令之一启动它：

重要

NTP 需要网络连接，可能需要几分钟才能同步时钟。 在某些情况下，有点网络连接可能使 NTP 将时钟报告为不同步。 一个常见的，虽然临时的解决方法是使用上述命令重新启动 NTP 。

如果时钟被 NTP 报告为同步，但是最大误差太高，则用户可以通过设置上述标志来将阈值增加到更高的值。 例如，将可能的最大误差增加到 20 秒，标志应该如下设置：--max_clock_sync_error_usec = 20000000

报告 Kudu 崩溃

Kudu 在 Kudu 遇到崩溃时使用 Google Breakpad 库来生成 minidump 。这些 minidumps 的大小通常只有几 MB ，即使禁用了核心转储生成也会生成这些。在这个时候，只能在 Kudu 的 Linux 上生成 minidumps 。

minidump 文件包含有关崩溃的进程的重要调试信息，包括加载的共享库及其版本，崩溃时运行的线程列表，处理器寄存器的状态和每个线程的堆栈内存副本，以及 CPU 和操作系统版本信息。

也可以强制 Kudu 通过向 kudu-tserver 或 kudu-master 进程发送 USR1 信号来创建一个 minidump ，而不会杀死进程。例如：

sudo pkill -USR1 kudu-tserver


默认情况下，Kudu 将其 minidum 存储在其配置的名为 minidumps 的 glog 目录的子目录中。可以通过设置 --minidump_path 标志来定制该位置。在删除最旧的之前， Kudu 将只保留一定数量的 minidumps ，以避免用 minidump 文件填满磁盘。可以通过设置 --max_minidumps gflag 来控制将保留的最小数量。

Minidumps 包含特定于创建它们的二进制文件的信息，因此在不访问崩溃的确切二进制文件的情况下不可用，或者非常相似的二进制文件。

重要

Minitump 可以通过电子邮件发送给 Kudu 开发人员或附加到 JIRA ，以帮助 Kudu 开发人员调试崩溃。为了使其有用，开发人员将需要知道 Kudu 的确切版本和发生崩溃的操作系统。请注意，虽然 minidump 不包含堆内存转储，但它确实包含堆栈内存，因此可以将应用程序数据显示在minidump 中。如果机密或个人信息存储在群集上，请不要共享 minidump 文件。

性能故障排除

Kudu追踪

kudu-master 和 kudu-tserver 守护进程包括基于开源 Chromium 跟踪框架的内置跟踪支持。您可以使用跟踪来帮助诊断延迟问题或 Kudu 服务器上的其他问题。

访问跟踪界面

每个 Kudu 守护进程中，跟踪界面是通过 Web 浏览器访问嵌入式 Web 服务器的一部分。

表 1. 跟踪界面 URL

注意

已知跟踪界面适用于最新版本的 Google Chrome 。其他浏览器可能无法正常工作。

Collecting a trace ( 收集痕迹 )

导航到跟踪界面后，单击屏幕左上角的记录按钮。当开始诊断问题时，首先选择所有类别。单击记录开始记录跟踪。

在跟踪收集期间，事件被收集到内存中的环形缓冲区中。该环形缓冲器的大小固定，最终可以达到100％。但是，在删除旧事件的同时，仍然收集新的事件。记录跟踪时，触发您有兴趣探索的行为或工作负载。

收集数秒后，单击停止。收集的踪迹将被下载并显示。使用 ？键显示有关使用跟踪界面探索跟踪的帮助文本。

Saving a trace ( 保存痕迹 )

您可以将收集的痕迹保存为 JSON 文件，以便以后分析，然后在收集跟踪后单击“保存”。要加载和分析保存的 JSON 文件，请单击加载并选择文件。

RPC Timeout Traces ( RPC超时跟踪 )

如果客户端应用程序遇到 RPC 超时，Kudu  tablet servers WARNING 级别日志应包含包含 RPC 级别跟踪的日志条目。例如：

W0922 00:56:52.313848 10858 inbound_call.cc:193] Call kudu.consensus.ConsensusService.UpdateConsensus
from 192.168.1.102:43499 (request call id 3555909) took 1464ms (client timeout 1000).
W0922 00:56:52.314888 10858 inbound_call.cc:197] Trace:
0922 00:56:50.849505 (+ 0us) service_pool.cc:97] Inserting onto call queue
0922 00:56:50.849527 (+ 22us) service_pool.cc:158] Handling call
0922 00:56:50.849574 (+ 47us) raft_consensus.cc:1008] Updating replica for 2 ops
0922 00:56:50.849628 (+ 54us) raft_consensus.cc:1050] Early marking committed up to term: 8 index: 880241
0922 00:56:50.849968 (+ 340us) raft_consensus.cc:1056] Triggering prepare for 2 ops
0922 00:56:50.850119 (+ 151us) log.cc:420] Serialized 1555 byte log entry
0922 00:56:50.850213 (+ 94us) raft_consensus.cc:1131] Marking committed up to term: 8 index: 880241
0922 00:56:50.850218 (+ 5us) raft_consensus.cc:1148] Updating last received op as term: 8 index: 880243
0922 00:56:50.850219 (+ 1us) raft_consensus.cc:1195] Filling consensus response to leader.
0922 00:56:50.850221 (+ 2us) raft_consensus.cc:1169] Waiting on the replicates to finish logging
0922 00:56:52.313763 (+1463542us) raft_consensus.cc:1182] finished
0922 00:56:52.313764 (+ 1us) raft_consensus.cc:1190] UpdateReplicas() finished
0922 00:56:52.313788 (+ 24us) inbound_call.cc:114] Queueing success response


这些跟踪可以指示请求的哪个部分缓慢。 请将它们包含在与 RPC 延迟异常值相关的错误报告中。

Kernel Stack Watchdog Traces ( 内核堆栈看门狗跟踪 )

每个 Kudu 服务器进程都有一个称为 Stack Watchdog 的后台线程，它监视服务器中的其他线程，以防它们被阻塞超过预期的时间段。 这些跟踪可以指示操作系统问题或瓶颈存储。

当看门狗线程识别线程阻塞的情况时，它会在 WARNING 日志中记录一个条目，如下所示：

W0921 23:51:54.306350 10912 kernel_stack_watchdog.cc:111] Thread 10937 stuck at /data/kudu/consensus/log.cc:505 for 537ms:
Kernel stack:
[] do_get_write_access+0x29d/0x520 [jbd2]
[] jbd2_journal_get_write_access+0x31/0x50 [jbd2]
[] __ext4_journal_get_write_access+0x38/0x80 [ext4]
[] ext4_reserve_inode_write+0x73/0xa0 [ext4]
[] ext4_mark_inode_dirty+0x4c/0x1d0 [ext4]
[] ext4_dirty_inode+0x40/0x60 [ext4]
[] __mark_inode_dirty+0x3b/0x160
[] file_update_time+0xf2/0x170
[] __generic_file_aio_write+0x230/0x490
[] generic_file_aio_write+0x88/0x100
[] ext4_file_write+0x61/0x1e0 [ext4]
[] do_sync_readv_writev+0xfb/0x140
[] do_readv_writev+0xd6/0x1f0
[] vfs_writev+0x46/0x60
[] sys_pwritev+0xa2/0xc0
[] system_call_fastpath+0x16/0x1b
[] 0xffffffffffffffff
User stack:
@ 0x3a1ace10c4 (unknown)
@ 0x1262103 (unknown)
@ 0x12622d4 (unknown)
@ 0x12603df (unknown)
@ 0x8e7bfb (unknown)
@ 0x8f478b (unknown)
@ 0x8f55db (unknown)
@ 0x12a7b6f (unknown)
@ 0x3a1b007851 (unknown)
@ 0x3a1ace894d (unknown)
@ (nil) (unknown)


这些跟踪可用于诊断根源于延迟问题（由 Kudu 以下的系统引起），如磁盘控制器或文件系统。

使用 Kudu 的问题

ClassNotFoundException：com.cloudera.kudu.hive.KuduStorageHandler

尝试通过 Hive 使用 Kudu 表时，用户将遇到此异常。 这不是一个丢失的 jar 的情况，而只是 Impala 将 Hive 中的 Kudu 元数据存储在其他工具（包括 Hive 本身和 Spark ）中无法读取的格式。  Hive 用户没有解决方法。  Spark 用户需要创建临时表。