AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post

Amazon OpenSearch Service クラスターの高い CPU 使用率をトラブルシューティングする方法を教えてください。

所要時間3分
0

Amazon OpenSearch Service クラスターのデータノードの CPU 使用率が高くなっています。

簡潔な説明

OpenSearch Service がタスクを実行するのに十分なリソースを確保できるように、CPU 使用率を維持するのがベストプラクティスです。CPU 使用率が高い状態で常に実行されるクラスターは、クラスターのパフォーマンスを低下させる可能性があります。クラスターが過負荷になると、OpenSearch Service は応答を停止し、タイムアウト要求が発生します。

クラスターの CPU 使用率が高いことをトラブルシューティングするには、次の方法を検討してください。

  • **ノードのホットスレッド ** API を使用してください。
  • [書き込み] 操作または [バルク] API スレッドプールを確認してください。
  • [検索] スレッドプールを確認してください。
  • Apache Lucene の [マージ] スレッドプールを確認してください。
  • [JVM のメモリ負荷] をチェックしてください。
  • [シャーディング戦略] を見直してください。
  • クエリを最適化しましょう。

解決方法

ノードのホットスレッド API を使用する

OpenSearch Service クラスターで CPU のスパイクが絶えず発生している場合は、[**ノードのホットスレッド **] API を使用してください。[ノードのホットスレッド] APIはタスクマネージャーとして機能し、クラスターで実行されているすべてのリソースを大量に消費するスレッドの詳細を表示します。

[ノードのホットスレッド] API の出力例:

GET _nodes/hot_threads

100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[xxx][search][T#62]'
10/10 snapshots sharing following 10
elements sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737)

java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647)

java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269)

org.opensearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:162)

java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)

注：[ノードのホットスレッド] 出力には、各ノードの情報が一覧表示されます。出力の長さは、OpenSearch Service クラスターで実行されているノードの数によって異なります。

さらに、[cat nodes] API を使用して、現在のリソース使用率の内訳を表示できます。次のコマンドを使用して、CPU 使用率が最も高いノードのサブセットを絞り込むことができます。

GET _cat/nodes?v&s=cpu:desc

出力の最後の列には、ノード名が表示されます。詳細については、Elasticsearch ウェブサイトの キャットノード API を参照してください。

次に、関連するノード名を [ホットスレッド] API に渡します。

GET _nodes/<node-name>/hot_threads

詳細については、Elasticsearch ウェブサイトの ホットスレッド API を参照してください。

[ノードのホットスレッド] 出力の例:

<percentage> of cpu usage by thread 'opensearch[<nodeName>][<thread-name>]'

スレッド名は、どの OpenSearch サービスプロセスが CPU を大量に消費しているかを示します。

詳細については、Elasticsearch ウェブサイトの ノードのホットスレッド API を参照してください。

書き込み操作またはバルク API スレッドプールを確認してください

OpenSearch Service の [429 エラー] は、クラスターが処理している一括インデックスリクエストが多すぎることを示している可能性があります。クラスター内で CPU のスパイクが絶えず発生している場合、OpenSearch Service は一括インデックス作成リクエストを拒否します。

[書き込み] スレッドプールは、[Bulk API] 操作を含むインデックス作成リクエストを処理します。クラスターが処理する一括インデックスリクエストが多すぎるかどうかを確認するには、Amazon CloudWatch の [** IndexingRate **] メトリックスを確認してください。

クラスターが処理する一括インデックスリクエストが多すぎる場合は、次の方法を検討してください。

  • クラスターの一括リクエストの数を減らしてください。
  • ノードがより効率的に処理できるように、各一括リクエストのサイズを小さくしてください。
  • Logstash を使用して OpenSearch Service クラスターにデータをプッシュする場合は、バッチサイズまたはワーカー数を減らしてください。
  • クラスターの取り込み速度が遅くなる場合は、クラスターを (水平方向または垂直方向に) スケーリングします。クラスターをスケールアップするには、OpenSearch Service が受信リクエストを処理できるように、ノードの数とインスタンスタイプを増やします。

詳細については、Elasticsearch ウェブサイトの バルク API を参照してください。

検索スレッドプールをチェック

CPU を大量に消費する [検索] スレッドプールは、検索クエリが OpenSearch Service クラスターに負荷をかけていることを示しています。実行時間の長いクエリが 1 つあれば、クラスターに負荷がかかる可能性があります。クラスターで実行されるクエリが増えると、[検索] スレッドプールにも影響する可能性があります。

1 つのクエリで CPU 使用率が増加しているかどうかを確認するには、[タスク管理] API を使用してください。例えば:

GET _tasks?actions=*search&detailed

[タスク管理] API は、クラスターで実行されているすべてのアクティブな検索クエリを取得します。詳細については、Elasticsearch ウェブサイトの [タスク管理 API] を参照してください。

注： [タスク管理] API によって [検索] タスクがリストされている場合のみ、出力に説明フィールドが含まれます。

出力例:

{
    "nodes": {
        "U4M_p_x2Rg6YqLujeInPOw": {
            "name": "U4M_p_x",
            "roles": [
                "data",
                "ingest"
            ],
            "tasks": {
                "U4M_p_x2Rg6YqLujeInPOw:53506997": {
                    "node": "U4M_p_x2Rg6YqLujeInPOw",
                    "id": 53506997,
                    "type": "transport",
                    "action": "indices:data/read/search",
                    "description": """indices[*], types[], search_type[QUERY_THEN_FETCH], source[{"size":10000,"query":{"match_all":{"boost":1.0}}}]""",
                    "start_time_in_millis": 1541423217801,
                    "running_time_in_nanos": 1549433628,
                    "cancellable": true,
                    "headers": {}
                }
            }
        }
    }
}

[説明]フィールドをチェックして、どのクエリが実行されているかを確認してください。running_time_in_nanos フィールドは、クエリが実行されていた時間を示します。CPU 使用率を下げるには、CPU を大量に消費している検索クエリをキャンセルしてください。[タスク管理] API は**\ _cancel ** 呼び出しもサポートしています。

**注：**特定のタスクをキャンセルするには、必ず出力からタスク ID を記録してください。この例では、タスク ID は「U4M\ _p\ _x2RG6YQLUJEINPOW: 53506997」です。

[**タスク管理 POST **] 呼び出しの例:

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

[**タスク管理 POST **] 呼び出しは、タスクを「キャンセル」としてマークし、依存している AWS リソースをすべて解放します。クラスターで複数のクエリを実行している場合は、[POST] 呼び出しを使用してクエリを 1 つずつキャンセルします。クラスターが通常の状態に戻るまで、各クエリをキャンセルします。また、CPU の急上昇を防ぐために、クエリ本文にタイムアウト値を設定することもベストプラクティスです。詳細については、Elasticsearch ウェブサイトの [リクエストボディ検索パラメーター] を参照してください。アクティブなクエリの数が減ったかどうかを確認するには、Amazon CloudWatch の [SearchRate] メトリックスを確認してください。

**注：**OpenSearch Service クラスター内のアクティブな検索クエリをすべて同時にキャンセルすると、クライアントアプリケーション側でエラーが発生する可能性があります。

詳細については、Elasticsearch ウェブサイトの [スレッドプール] を参照してください。

Apache Lucene のマージスレッドプールを確認してください

OpenSearch Service は Apache Lucene を使用してクラスター上のドキュメントのインデックス作成と検索を行います。Apache Lucene は [**マージ **] 操作を実行して、各シャードに必要な有効セグメント数を減らし、削除されたドキュメントをすべて削除します。このプロセスは、シャードに新しいセグメントが作成されるたびに実行されます。

Apache Lucene の [マージ] スレッド操作が CPU 使用率に影響を与えていることがわかった場合は、OpenSearch Service クラスターインデックスの refresh\ _interval 設定を増やしてください。[**refresh\ _interval **] 設定を増やすと、クラスターのセグメント作成が遅くなります。

注： インデックスを UltraWarm ストレージに移行するクラスターは、CPU 使用率を高めることができます。UltraWarm の移行には通常、強制結合 API 操作が必要で、CPU に負荷がかかる可能性があります。

UltraWarm のマイグレーションを確認するには、次のコマンドを使用します。

GET _ultrawarm/migration/_status?v

詳細については、Elasticsearch ](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-merge.html) ウェブサイトの「[マージ」を参照してください。

JVM のメモリ負荷をチェック

クラスタノードの Java ヒープの JVM メモリ負荷率を確認します。JVM のメモリ使用量が 75% に達すると、Amazon OpenSearch Service はコンカレントマークスイープ (CMS) ガベージコレクタをトリガーします。JVM のメモリ使用量が 100% に達すると、OpenSearch Service JVM は終了し、最終的にはメモリ不足 (OOM) で再起動するように設定されます。

次のログ例では、JVM は推奨範囲内ですが、クラスターは長時間実行されるガベージコレクションの影響を受けます。

[2022-06-28T10:08:12,066][WARN ][o.o.m.j.JvmGcMonitorService]
[515f8f06f23327e6df3aad7b2863bb1f] [gc][6447732] overhead, spent [9.3s]
collecting in the last [10.2s]

詳細については、「Amazon OpenSearch Service クラスターの JVM メモリ負荷が高い場合のトラブルシューティングをするには？」を参照してください。

**シャーディング戦略の見直し **

クラスターのサイズによっては、シャードが多すぎるとクラスターのパフォーマンスが低下する可能性があります。Java ヒープの GiB あたりのシャードは 25 個以下にするのが最適です。

デフォルトでは、Amazon OpenSearch Service は 5:1 のシャーディング戦略を採用しており、各インデックスは 5 つのプライマリシャードに分割されます。各インデックス内には、各プライマリシャードにも独自のレプリカがあります。OpenSearch Service は、プライマリシャードとレプリカシャードを別々のデータノードに自動的に割り当て、障害が発生した場合に備えてバックアップがあることを確認します。

詳細については、Amazon OpenSearch Service クラスター内の不均一なシャード分布を再調整するにはどうすればよいですか? を参照してください。

クエリを最適化

大量の集約、ワイルドカードクエリ (特に先頭のワイルドカード)、正規表現クエリは計算負荷が高く、CPU 使用率が急上昇する可能性があります。スローログを検索してスローログにインデックスを付けると、高価で問題のあるクエリを診断するのに役立ちます。

詳細については、Amazon CloudWatch Logs による OpenSearch ログのモニタリングを参照してください。

関連情報

Amazon OpenSearch Serviceクラスターのインデックス作成パフォーマンスを向上させるにはどうすればよいですか?

Amazon OpenSearch Serviceで検索拒否または書き込み拒否を解決するにはどうすればいいですか？

Amazon OpenSearch Serviceドメインのサイジング

トピック
サーバーレス分析
タグ
Amazon OpenSearch Service
言語
日本語
AWS公式
AWS公式更新しました 1年前
コメントはありません

関連するコンテンツ