疑難排解 IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data 部署

瞭解如何疑難排解及解決您在使用產品時可能遇到的問題。

IBM Cloud Pak for Data

此資訊僅適用於安裝在 IBM Cloud Pak® for Data上的 IBM Watson® Discovery 實例。如需將資料同時新增至已安裝及受管理部署的疑難排解提示，請參閱疑難排解汲取。

本主題中的資訊建議您可以採取步驟來調查可能發生的問題。如需每個版本的已知問題及其暫行解決方法的相關資訊，請參閱已知問題。

Minio Pod 在安裝或升級期間進入重新開機迴圈

錯誤: 在安裝或升級 Discovery期間顯示 Cannot find volume "export" to mount into container "ibm-minio"。當您使用 oc get pods -l release=wd-minio -o wide 指令來檢查 Minio Pod 的狀態，然後使用 oc get pods -A | grep ibm-minio-operator 指令來檢查 Minio operator 日誌，然後使用 oc logs -n <namespace> ibm-minio-operator-XXXXX 指令來檢查 Minio Pod 的狀態時，您會在日誌中看到類似於下列錯誤的錯誤:
```
ibm-minio/templates/minio-create-bucket-job.yaml failed: jobs.batch "wd-minio-discovery-create-bucket" already exists) and failed rollback: failed to replace object"
```
原因: 未適當地刪除為 Minio 建立儲存體儲存區然後在完成之後予以刪除的工作。
解決方案: 完成下列步驟，以檢查 Minio 的 create-bucket 工作是否不完整。如果是這樣，請刪除未完成的工作，以便可以重建工作，然後可以順利執行。
1. 使用下列指令來檢查 Minio 工作:
```
oc get jobs | grep 'wd-minio-discovery-create-bucket'
```
2. 如果回應中列出現有工作，請使用下列指令來刪除工作:
```
oc delete job $(oc get jobs -oname | grep 'wd-minio-discovery-create-bucket')
```
3. 使用下列指令，驗證所有 Minio Pod 都已順利啟動:
```
oc get pods -l release=wd-minio -o wide
```

日誌中顯示 `No space left on device` 訊息

如果 wd-ibm-elasticsearch-es-server-client Pod 反覆地重新啟動，然後報告 Crashloopbackoff 狀態，並將訊息 No space left on device 寫入 Pod 的日誌，則問題可能是 Pod 上缺少記憶體。請遵循疑難排解記憶體不足問題的步驟，或聯絡 IBM 支援中心。

日誌中顯示 `java.lang.OutOfMemoryError: Java heap space` 訊息

檢索已套用多個強化的大量文件時，工作者節點可能會用盡空間。若要解決此問題，請先完成下列步驟來判斷哪個 Pod 記憶體不足:

如果文件狀態無法升級至 Processing，請檢查 inlet、outlet 及 converter Pod 的狀態。

執行下列指令：

oc get pod -l 'tenant=wd,run in (inlet,outlet,converter)'

如果任何 Pod 未顯示 Running 狀態，請使用下列指令重新啟動失敗的 Pod:
```
oc delete pod <pod_name>
```
否則，請開啟 管理集合>{collection name}>活動頁面。檢查訊息 OutOfMemory happened during conversion. Please reconsider size of documents. 的 警告及錯誤概覽 區段，如果顯示的話，請使用下列指令來提高轉換器的記憶體大小:
```
oc patch wd wd --type=merge \
--patch='{"spec":{"ingestion":{"converter":b{"maxHeapMemory":"10240m","resources":{"limits":{"memory":"10Gi"}}}}}}'
```
根據叢集資源來調整 maxHeapMemory 的值及容器記憶體。
順利重新啟動 converter Pod 之後，請從「活動」標籤中按一下 重新處理。

如果文件停留在 Processing 狀態，且無法提升至集合的 Available 狀態，請完成下列步驟:

使用下列指令檢查 Hadoop 的狀態：
```
oc get pod -l 'tenant=wd,run in (hdp-rm,hdp-worker)'
```
其中 l 是清單的小寫 L。
如果任何 Pod 未顯示 Running 狀態，請使用下列指令重新啟動失敗的 Pod:
```
oc delete pod <pod_name>
```
使用下列指令來尋找 OOM when allocating 訊息，以檢查是否有任何 Hadoop 工作者節點記憶體不足:
```
oc logs -l tenant=wd,run=hdp-worker -c logger --tail=-1 \
| grep "OOM when allocating"
```
如果找到相符項，請使用下列指令來修補資源:
```
oc patch wd wd --type=merge \
--patch='{"spec":{"orchestrator":{"docproc":{"pythonAnalyzerMaxMemory":"8g"}}}}'
```
pythonAnalyzerMaxMemory 容許的值上限為 12g。預設值為 6g。逐步增加該值，例如根據叢集資源一次增加 2g。
使用下列指令來尋找 OutOfMemoryError 訊息，以檢查是否有任何 Hadoop 工作者節點記憶體不足:
```
oc logs -l tenant=wd,run=hdp-worker -c logger --tail=-1 \
| grep "OutOfMemoryError"
```

如果找到相符項，請使用下列指令來檢查現行環境變數值及 Hadoop 工作者節點記憶體資源:

若要檢查編排器儲存器中的 "DOCPROC_MAX_MEMORY" 變數，請執行下列動作:

oc exec `oc get po -l run=orchestrator -o 'jsonpath={.items[0].metadata.name}'` env \
| grep DOCPROC_MAX_MEMORY

若要檢查 Hadoop 工作者節點儲存器中的 "YARN_NODEMANAGER_RESOURCE_MEMORY_MB" 變數，請執行下列動作:

oc exec `oc get po -lrun=hdp-worker -o 'jsonpath={.items[0].metadata.name}'` \
-c hdp-worker -- env | grep YARN_NODEMANAGER_RESOURCE_MEMORY_MB

若要檢查 hdp-worker 儲存器的記憶體資源，請執行下列動作:

oc get po -l run=hdp-worker -o 'jsonpath=requests are \
{.items[*].spec.containers[?(.name=="hdp-worker")].resources.requests.memory}, \
limits are {.items[*].spec.containers[?(.name=="hdp-worker")].resources.limits.memory}'

使用下列指令，逐步修補環境變數資源:

oc patch wd `oc get wd -o 'jsonpath={.items[0].metadata.name}'` \
--type=merge --patch='{"spec":{"orchestrator":{"docproc":{"maxMemory":"4g"}}, \
"hdp":{"worker":{"nm":{"memoryMB":12000}, "resources":{"limits":{"memory":"20Gi"}, \
"requests":{"memory":"20Gi"}}}}}}'

資源的預設值如下:

docproc.maxMemory: 2g

每次遞增 2g。
nm.memoryMB: 10,240

從 12,000 開始，一次增加 2,000 個增量。
memory requests/limits: 13Gi/18Gi

一次增加 2Gi 個增量。

使用下列指令，檢查 Hadoop Pod 是否順利重新啟動:
```
oc get pods -l 'tenant=wd,run in (orchestrator,hdp-worker)'
```
請確認在您修補叢集之後已套用新的配置。
如果 Pod 未重新啟動，請使用下列指令來檢查資源是否已更新:
```
oc get wd wd -o yaml
```
個別檢查用戶端和資料節點，以檢查 Elasticsearch 的狀態。

在用戶端節點上，執行下列指令，以檢查是否發生記憶體不足異常狀況:

oc logs -l tenant=wd,ibm-es-data=False,ibm-es-master=False \
-c elasticsearch --tail=-1 | grep "OutOfMemoryError"

如果找到錯誤訊息 (不包括 INFO 訊息)，請使用下列指令來增加記憶體資源:

oc patch wd wd --type=merge \
--patch='{"spec":{"elasticsearch":{"clientNode":{"maxHeap":"896m","resources":{"limits":{"memory":"1792Mi"}}}}}}'

執行此指令之後，大約 20 分鐘後會重新啟動 Elasticsearch 用戶端 Pod。使用下列指令來監視 Pod 的 "AGE":
```
oc get pod -l tenant=wd,ibm-es-data=False,ibm-es-master=False
```
順利重新啟動 Pod 之後，請使用下列指令來檢查 ES_JAVA_OPTS 的新值及儲存器記憶體限制:
```
oc describe $(oc get po -l tenant=wd,ibm-es-data=False,ibm-es-master=False -o name)
```

在資料節點上，執行下列指令，以檢查是否發生記憶體不足異常狀況:

oc logs -l tenant=wd,ibm-es-data=True,ibm-es-master=False \
-c elasticsearch --tail=-1 | grep "OutOfMemoryError"

如果找到錯誤訊息 (不包括 INFO 訊息)，請使用下列指令來增加記憶體資源:

oc patch wd wd --type=merge \
--patch='{"spec":{"elasticsearch":{"dataNode":{"maxHeap":"6g","resources":{"limits":{"memory":"10Gi"},"requests":{"memory":"8Gi"}}}}}}'

執行此指令之後，大約 20 分鐘後會重新啟動 Elasticsearch 用戶端 Pod。使用下列指令來監視 Pod 的 "AGE":
```
oc get pod -l tenant=wd,ibm-es-data=True,ibm-es-master=False
```
順利重新啟動 Pod 之後，請使用下列指令來檢查 ES_JAVA_OPTS 的新值及儲存器記憶體要求/限制:
```
oc describe $(oc get po -l tenant=wd,ibm-es-data=True,ibm-es-master=False -o name)
```
對於兩個節點 (用戶端和資料)，請將 resources.limits.memory 設為等於 2 * maxHeap。

如果在 30 分鐘之後無法透過套用 oc patch 指令來重新啟動 Pod，請使用下列指令收集日誌以與 IBM 支援中心共用:
```
oc logs -l control-plane=ibm-es-controller-manager --tail=-1
```

對於無法將文件狀態升級至 Processing 以及文件停留在 Processing 狀態的這兩個問題，如果您使用 Portworx 儲存體，則可以檢查 Elasticsearch 磁碟是否已滿。

執行下列指令以檢查 Elasticsearch 磁碟是否已滿：

oc logs -l tenant=wd,run=elastic,ibm-es-master=True \
-c elasticsearch --tail=100000|grep 'disk watermark'

如果日誌顯示 watermark exceeded on x-data-1 之類的訊息，表示指定節點上的磁碟已滿，您需要使用下列指令來增加磁碟大小:

oc patch pvc $(oc get pvc -l tenant=wd,run=elastic,ibm-es-data=True,ibm-es-master=False \
-o jsonpath='{.items[N].metadata.name}') \
-p '{"spec": {"resources": {"requests":{"storage": "60Gi"}}}}'

其中 N 表示從日誌報告的資料節點號碼。

例如，如果日誌提及節點名稱中的 data-1，則要使用的指令為:

oc patch pvc $(oc get pvc -l tenant=wd,run=elastic,ibm-es-data=True,ibm-es-master=False \
-o jsonpath='{.items[1].metadata.name}') -p '{"spec": {"resources": {"requests":{"storage": "60Gi"}}}}'

在 Discovery for Cloud Pak for Data 中設定 Shard 限制

在 Discovery 版本 4.0 中，群集上可以保持開啟的分片數量是有限制的。在開發實例中，限制為 1,000 個開啟的 Shard，而在正式作業實例中，限制為兩個資料節點（相當於 2,000 個開啟的 Shard），或每個資料節點 1,000 個開啟的 Shard。在達到任一限制之後，您無法在叢集上建立任何其他專案及集合，而且如果嘗試建立新的專案及集合，則會收到一則錯誤訊息。

這個限制是因為當您安裝 Discovery 版本 4.0 時，Elasticsearch 版本 7.10.2 會自動在您的叢集上執行。因為此版本的 Elasticsearch 在您的叢集上執行，所以新的叢集穩定性配置變成可用，將每一個 Elasticsearch 資料節點的開啟 Shard 數目限制為 1,000。

如果無法建立新的專案及集合，並收到錯誤，請先檢查 Elasticsearch 叢集的狀態，以及該叢集上的 Shard 數目。請考量增加叢集的資料節點數目，以支援更多的 Shard。這是最大化效能的最佳方法。不過，增加的節點數目會使用更多的記憶體。如果 Shard 數目達到限制，您也可以增加資料節點的限制。如需增加節點的 Shard 限制的相關資訊，請參閱增加 Shard 限制。

此 1,000 個 Shard 的限制適用於 4.0 或更高版本的 Discovery 版本。

增加 Shard 限制

登入 Discovery 叢集。
存取您的資料節點。

輸入下列指令：

oc exec -it $(oc get pod \
-l app=elastic,ibm-es-data=True -o jsonpath='{.items[0].metadata.name}') -- bash

輸入下列指令，以您的連接埠號取代 <> 及其內的內容：
```
curl -X POST http://localhost:<port_number>/_cluster/health?pretty
```
如果您不知道埠號是多少，請輸入下列指令來尋找：
```
oc get pod -l app=elastic,ibm-es-data=True -o json \
| jq .items[].spec.containers[].ports[0].containerPort | head -n 1`
```
curl POST 指令會傳回 active_primary_shards 的值。如果有一個資料節點的值大於 1,000，或者有兩個資料節點的值大於 2,000，則必須增加 Shard 限制，以在叢集中建立新的專案及集合。

如果您增加此限制，叢集會變成較不穩定，因為其包含了增加的 Shard 數目。
輸入下列指令以增加分片數量，請將 <port_number> 改為您的連接埠號，並將 <total_shards_per_node> 和 <max_shards_per_node> 改為您要指派給節點的新分片限制：
```
curl -X POST http://localhost:<port_number>/_cluster/settings \
-d '{"persistent": {"cluster.routing.allocation.total_shards_per_node":<total_shards_per_node>, \
"cluster.max_shards_per_node":<max_shards_per_node>} }' \
-XPUT -H 'Content-Type:application/json'
```
在增加 Shard 限制之後，您即可在叢集上建立更多的專案及集合。

清除鎖定狀態

IBM Cloud Pak for Data 僅已安裝：pod 重新啟動時，會執行資料庫驗證外掛程式，以檢查變更，並將最新的變更集套用至共用資料庫。gateway 如果在進行此檢查時重新啟動 pod，外掛程式可能會維持在鎖定狀態，使服務無法啟動。可能需要手動資料庫干預來清除鎖。

如果 Discovery API 不會上線，或者 gateway-0 pod 看起來像是不斷在當機循環，您可以嘗試檢查位於此處的 API 服務的 Liberty 伺服器日誌：/opt/ibm/wlp/output/wdapi/logs/messages.log

日誌會顯示 Liquibase 是否失敗及無法執行。如果系統已鎖定，您可能會看到類似下列的內容:

[11/7/19 5:07:51:491 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:07:51:593 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:01:601 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:02:091 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:12:097 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:12:197 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:22:203 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT ID,LOCKED,LOCKGRANTED,LOCKEDBY FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:22:613 UTC] 0000002f com.ibm.ws.logging.internal.impl.IncidentImpl I FFDC1015I: An FFDC Incident has been created: "org.jboss.weld.exceptions.DeploymentException: WELD-000049: Unable to invoke public void liquibase.integration.cdi.CDILiquibase.onStartup() on liquibase.integration.cdi.CDILiquibase@7f02a07 com.ibm.ws.container.service.state.internal.ApplicationStateManager 31" at ffdc\_19.11.07\_05.08.22.0.log

可以手動解除鎖定外掛程式。如果您有 Discovery 2.1.4 或更舊版本，請在 gateway-0 Pod 正在查看的 postgres 資料庫上輸入下列指令:

psql dadmin
UPDATE DATABASECHANGELOGLOCK SET LOCKED=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

如果您有 Discovery 2.2.0 或更新版本，請在 gateway-0 Pod 正在查看的 postgres 資料庫上輸入下列指令:

oc exec -it wd-discovery-postgres-0 -- bash -c 'env PGPASSWORD="$PG_PASSWORD" psql "postgresql://$PG_USER@$STKEEPER_CLUSTER_NAME-proxy-service:$STKEEPER_PG_PORT/dadmin" -c "UPDATE DATABASECHANGELOGLOCK SET LOCKE
D=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1"'

如果您可以重新啟動 gateway pod，一切都應該可以恢復正常。

智慧型文件理解的環境變數設定

對於 IBM Watson® Discovery 2.1.0 版中的「智慧型文件理解」，有兩個環境變數需要進行調整。這在 2.1.1 版已解決，請參閱 2.1.1 版，2020 年 1 月 24 日。

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS
SDU_YOLO_TIMEOUT_SEC

這兩個變數都應該設定為其各自的 hour 值。這些值必須在 <release-name>-watson-discovery-hdp ConfigMap 中設定。

值應該為：

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS 應該設定為 3600000

SDU_YOLO_TIMEOUT_SEC 應該設定為 3600

這兩個值應該在安裝或重新安裝軟體時進行設定。

疑難排解錯誤訊息

如果您收到的錯誤訊息與強化的逾時及記憶體不足相關，則可以輸入下列指令來變更逾時及記憶體設定，以潛在地解決這些錯誤訊息：

通知訊息：<enrichment_name>: Document enrichment timed out

建議動作：增加文件處理逾時。請輸入下列指令，將預設逾時從 10 分鐘增加至 20 分鐘：
```
oc patch wd wd --type=merge \
--patch='{"spec": {"orchestrator": {"docproc": {"defaultTimeoutSeconds": 1200 } } } }'
```
通知訊息：<enrichment_name>: Document enrichment failed due to lack of memory

建議動作：增加編排器儲存器記憶體限制。請輸入下列指令，將記憶體限制從 4 Gi 增加至 6 Gi：
```
oc patch wd wd --type=merge \
--patch='{"spec": {"orchestrator": {"resources": {"limits": {"memory": "6Gi"} } } } }'
```
注意訊息：Indexing request timed out

建議動作：增加將文件推送至 Elasticsearch 的逾時。請輸入下列指令，將預設逾時從 10 分鐘增加至 20 分鐘：
```
oc patch wd wd --type=merge \
--patch='{"spec": {"shared": {"elastic": {"publishTimeoutSeconds": 1200 } } } }'
```