Kudu 故障排除 · Kudu 1.4.0 中文文檔

# Kudu 故障排除原文鏈接 : [http://kudu.apache.org/docs/troubleshooting.html](http://kudu.apache.org/docs/troubleshooting.html) 譯文鏈接 : [http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813626](http://cwiki.apachecn.org/pages/viewpage.action?pageId=10813626) 貢獻者 : [小瑤](/display/~chenyao) [ApacheCN](/display/~apachecn) [Apache中文網](/display/~apachechina) ## 啟動錯誤 ### 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** ，請對您的操作系統使用相應的命令： | OS ( 操作系統 ) | Command ( 命令 ) | | --- | --- | | Debian/Ubuntu | sudo apt-get install ntp | | RHEL/CentOS | sudo yum install ntp | 如果 **NTP** 已安裝但未運行，請使用以下命令之一啟動它： | OS ( 操作系統 ) | Command ( 命令 ) | | --- | --- | | Debian/Ubuntu | sudo service ntp restart | | RHEL/CentOS | sudo /etc/init.d/ntpd restart | 重要 **NTP** 需要網絡連接，可能需要幾分鐘才能同步時鐘。在某些情況下，有點網絡連接可能使 **NTP** 將時鐘報告為不同步。一個常見的，雖然臨時的解決方法是使用上述命令重新啟動 **NTP** 。如果時鐘被 **NTP** 報告為同步，但是最大誤差太高，則用戶可以通過設置上述標志來將閾值增加到更高的值。例如，將可能的最大誤差增加到 **20** 秒，標志應該如下設置：**--max_clock_sync_error_usec = 20000000** ## 報告 Kudu 崩潰 **Kudu** 在 **Kudu** 遇到崩潰時使用 **[Google Breakpad](https://chromium.googlesource.com/breakpad/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** | Daemon ( 守護進程 ) | URL | | --- | --- | | Tablet Server | [http://tablet-server-1.example.com:8050/tracing.html](http://tablet-server-1.example.com:8050/tracing.html) | | Master | [http://master-1.example.com:8051/tracing.html](http://master-1.example.com:8051/tracing.html) | 注意已知跟蹤界面適用于最新版本的 **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: [<ffffffffa00b209d>] do_get_write_access+0x29d/0x520 [jbd2] [<ffffffffa00b2471>] jbd2_journal_get_write_access+0x31/0x50 [jbd2] [<ffffffffa00fe6d8>] __ext4_journal_get_write_access+0x38/0x80 [ext4] [<ffffffffa00d9b23>] ext4_reserve_inode_write+0x73/0xa0 [ext4] [<ffffffffa00d9b9c>] ext4_mark_inode_dirty+0x4c/0x1d0 [ext4] [<ffffffffa00d9e90>] ext4_dirty_inode+0x40/0x60 [ext4] [<ffffffff811ac48b>] __mark_inode_dirty+0x3b/0x160 [<ffffffff8119c742>] file_update_time+0xf2/0x170 [<ffffffff8111c1e0>] __generic_file_aio_write+0x230/0x490 [<ffffffff8111c4c8>] generic_file_aio_write+0x88/0x100 [<ffffffffa00d3fb1>] ext4_file_write+0x61/0x1e0 [ext4] [<ffffffff81180f5b>] do_sync_readv_writev+0xfb/0x140 [<ffffffff81181ee6>] do_readv_writev+0xd6/0x1f0 [<ffffffff81182046>] vfs_writev+0x46/0x60 [<ffffffff81182102>] sys_pwritev+0xa2/0xc0 [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 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** 用戶需要創建臨時表。