# 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** 用戶需要創建臨時表。