Kudu 故障排除

    译文链接 :

    贡献者 : 小瑶 Apache中文网

    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 将不会启动，并会发出如下消息：

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

      或者

      重要

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

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

      重要

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

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

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

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

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

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

      访问跟踪界面

      表 1. 跟踪界面 URL

      注意

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

      Collecting a trace ( 收集痕迹 )

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

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

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

      Saving a trace ( 保存痕迹 )

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

      RPC Timeout Traces ( RPC超时跟踪 )

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

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

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

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

      1. W0921 23:51:54.306350 10912 kernel_stack_watchdog.cc:111] Thread 10937 stuck at /data/kudu/consensus/log.cc:505 for 537ms:
      2. Kernel stack:
      3. [<ffffffffa00b209d>] do_get_write_access+0x29d/0x520 [jbd2]
      4. [<ffffffffa00b2471>] jbd2_journal_get_write_access+0x31/0x50 [jbd2]
      5. [<ffffffffa00fe6d8>] __ext4_journal_get_write_access+0x38/0x80 [ext4]
      6. [<ffffffffa00d9b23>] ext4_reserve_inode_write+0x73/0xa0 [ext4]
      7. [<ffffffffa00d9b9c>] ext4_mark_inode_dirty+0x4c/0x1d0 [ext4]
      8. [<ffffffffa00d9e90>] ext4_dirty_inode+0x40/0x60 [ext4]
      9. [<ffffffff811ac48b>] __mark_inode_dirty+0x3b/0x160
      11. [<ffffffff8111c1e0>] __generic_file_aio_write+0x230/0x490
      12. [<ffffffff8111c4c8>] generic_file_aio_write+0x88/0x100
      13. [<ffffffffa00d3fb1>] ext4_file_write+0x61/0x1e0 [ext4]
      14. [<ffffffff81180f5b>] do_sync_readv_writev+0xfb/0x140
      15. [<ffffffff81181ee6>] do_readv_writev+0xd6/0x1f0
      16. [<ffffffff81182102>] sys_pwritev+0xa2/0xc0
      17. [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
      18. [<ffffffffffffffff>] 0xffffffffffffffff
      21.     @       0x3a1ace10c4  (unknown)
      22.     @          0x1262103  (unknown)
      23.     @          0x12622d4  (unknown)
      24.     @          0x12603df  (unknown)
      25.     @           0x8e7bfb  (unknown)
      26.     @           0x8f478b  (unknown)
      27.     @           0x8f55db  (unknown)
      28.     @          0x12a7b6f  (unknown)
      29.     @       0x3a1b007851  (unknown)
      30.     @       0x3a1ace894d  (unknown)

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

      ClassNotFoundException：com.cloudera.kudu.hive.KuduStorageHandler

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