Hologres:監視メトリクス

インスタンスの CPU 使用率 (%)

インスタンス全体の CPU ロードです。

バックグラウンドプロセスとコンパクションタスクは、アクティブなクエリがない場合でも CPU を消費するため、アイドル時にも CPU が使用されるのは正常です。Hologres はマルチコア並列処理を使用するため、単一のクエリで CPU が 100% に達することがあります。これはリソースが最大限に利用されていることを示しており、必ずしも問題ではありません。

調査の目安：CPU 使用率が 3 時間にわたり 100% 付近で推移する、または 12 時間にわたり 90% を超える場合、インスタンスは高負荷状態であり、CPU がボトルネックである可能性が高いです。次の点を確認してください：

• データ量の増加に伴い、大規模なオフラインデータインポート (INSERT) が実行されている。

• 高 QPS のクエリまたは書き込みが、CPU リソースをすべて消費している。

• ハイブリッドワークロードで、上記のシナリオが組み合わさっている。

CPU の高負荷が継続すると見込まれる場合は、インスタンスをスケールアップしてください。

詳細については、「監視メトリクスのよくある質問」をご参照ください。

ワーカーノードの CPU 使用率 (%)

各ワーカーノードの CPU ロードです。ワーカーノード数はインスタンスタイプによって異なります。詳細については、「Instance management」をご参照ください。

バージョン：V1.1 以降

• すべてのワーカーノードで CPU 使用率が継続して 100% 付近である場合、インスタンスは高負荷状態です。クエリを最適化するか、インスタンスをスケールアップしてください。

• 一部のワーカーノードのみで CPU 使用率が高い場合、リソーススキューが発生しています。一般的な原因とトラブルシューティングについては、「監視メトリクスのよくある質問」をご参照ください。

クラスターの CPU 使用率 (%)

コンピューティンググループ内の各クラスターの CPU 使用率です。

バージョン：V4.0 以降 (コンピューティンググループインスタンスのみ)

インスタンスメモリ使用率 (%)

インスタンス全体のメモリ消費量。

Hologres は、クエリを高速化するために、メタデータ、インデックス、キャッシュ用のメモリを確保します。アイドル時の使用率が 30%～40% となるのは一般的です。使用率が 80% に近づくと、メモリがボトルネックになる可能性があります。

メモリ分布メトリクスを QPS やその他の指標と組み合わせて使用して、メモリ消費量の多い要因を特定してください。詳細については、「メモリ不足問題のトラブルシューティングガイド」をご参照ください。

ワーカーノードメモリ使用率 (%)

各ワーカーノードのメモリ負荷。ワーカーノードの数はインスタンスタイプによって異なります。詳細については、「インスタンス管理」をご参照ください。

バージョン： V1.1+

• すべてのワーカーノードでメモリ使用率が 80% 近くで持続する場合、インスタンスは高負荷状態にあります。クエリを最適化するか、インスタンスをスケールアップしてください。

• 一部のワーカーノードのみで高いメモリ使用率が発生する場合、リソーススキューが発生しています。一般的な原因とトラブルシューティングについては、「監視メトリクスに関するよくある質問」をご参照ください。

詳細インスタンスメモリ使用率 (%)

バージョン： V2.0+ (メモリ分布メトリクスは V2.0.15 以降で利用可能)

Hologres はメモリを 6 つのカテゴリに分類します。

トラブルシューティング： Query メモリ使用量が高い場合、またはメモリ不足 (OOM) イベントが発生する場合は、通常、複雑なクエリまたは高い同時実行性を示しています。最適化のガイダンスについては、「クエリパフォーマンスの最適化」をご参照ください。

QE クエリメモリ使用量 (bytes)

HQE、SQE、またはその他の XQE エンジンがクエリの実行で使用するメモリ (バイト単位)。

バージョン： V2.0.44+ / V2.1.22+

メモリの内訳では、Query メモリ使用量は QE クエリメモリ使用量を上回ります。これは、Query にすべてのエンジンタイプが含まれるためです。QE クエリメモリ使用量が高い場合は、より多くのメモリを必要とする複雑なクエリを示しています。

QE クエリメモリ使用率 (%)

QE エンジンがクエリで使用するメモリの割合。

バージョン： V2.0.44+ / V2.1.22+

使用率が高いと、メモリ不足 (OOM) エラーが発生する可能性があります。クエリを最適化するか、インスタンスをスケールアップしてください。

クラスターメモリ使用率 (%)

コンピュートグループ内の各クラスターのメモリ使用率。

バージョン： V4.0+ (コンピュートグループインスタンスのみ)

クエリ QPS (カウント/秒)

SELECT、INSERT、UPDATE、DELETE、UTILITY、UNKNOWN を含む、1 秒あたりに実行される SQL ステートメントの平均数です。

関係： Query QPS >= QE Query QPS + FixedQE Query QPS

合計 QPS にはすべてのクエリ (UNKNOWN、UTILITY、Engine Type={PG}) が含まれるため、QE と FixedQE の QPS の合計以上になります。

QE クエリ QPS (カウント/秒)

QE エンジンによって実行される 1 秒あたりのクエリ数で、SELECT、INSERT、UPDATE、DELETE を含みます。

バージョン： V2.2+

FixedQE クエリ QPS (カウント/秒)

FixedQE エンジン (Fixed Plan パス、旧 SDK) によって実行される 1 秒あたりのクエリ数で、SELECT、INSERT、UPDATE、DELETE を含みます。

バージョン： V2.2+

DML RPS (カウント/秒)

INSERT、UPDATE、DELETE を含む、1 秒あたりにインポートまたは更新されるデータレコードの平均数です。

関係： DML RPS = QE DML RPS + FixedQE DML RPS

QE DML RPS (カウント/秒)

QE エンジンによって 1 秒あたりにインポートまたは更新されるデータレコード数で、INSERT、UPDATE、DELETE を含みます。

バージョン： V2.2+

一般的な QE シナリオ：

• MaxCompute または OSS 外部テーブルからのバッチインポートまたは更新

• COPY を使用したバッチ書き込みまたは更新

• Hologres テーブル間のバッチインポート

FixedQE DML RPS (カウント/秒)

FixedQE エンジン (Fixed Plan パス、旧 SDK) によって 1 秒あたりにインポートまたは更新されるデータレコード数で、INSERT、UPDATE、DELETE を含みます。

バージョン： V2.2+

一般的な FixedQE シナリオ：

• Flink を使用したリアルタイム書き込み

• Holo-Client を使用した書き込み

• Spark を使用したインポート

• Hologres への MySQL バイナリログのリアルタイム同期

• DataHub からのインポート

• Data Integration (DataX) を使用したオフライン書き込み

• INSERT INTO VALUES() を使用した SQL または JDBC による書き込み

クエリレイテンシー (milliseconds)

すべてのクエリの平均レイテンシーです。SELECT、INSERT、UPDATE、DELETE、UTILITY、UNKNOWN を含みます。

関係： クエリレイテンシー >= MAX(QE クエリレイテンシー、FixedQE クエリレイテンシー)

QE クエリレイテンシー (milliseconds)

QE エンジンで実行されるクエリの平均レイテンシーです。SELECT、INSERT、UPDATE、DELETE を含みます。

バージョン： V2.2+

QE クエリレイテンシーの上昇をトラブルシューティングするには、最適化フェーズ期間、クエリ開始フェーズ期間、Get Next フェーズ期間、および QE QPS メトリクスを確認してください。

FixedQE クエリレイテンシー (milliseconds)

FixedQE エンジンで実行されるクエリの平均レイテンシーです。SELECT、INSERT、UPDATE、DELETE を含みます。

バージョン： V2.2+

トラブルシューティング：

• 時折発生するスパイク： HQE ロックを示している可能性があります。FixedQE Backend Lock Wait Time が増加しているかどうかを確認してください。増加している場合は、Get query insightsを使用して、ロックしているクエリを特定してください。

• 継続的な高レイテンシー： 非最適なテーブル設計または複雑なクエリの干渉が原因である可能性があります。Blink と Flink に関する一般的な問題と診断をご参照ください。

最適化フェーズ期間 (milliseconds)

最適化フェーズで費やされる時間です。このフェーズでは、オプティマイザーが SQL を解析し、物理プランを生成します。

バージョン： V2.0.44+ / V2.1.22+

最適化期間が長い場合は、クエリが複雑であることを示しています。パラメータのみが異なるクエリの場合は、プリペアドステートメントを使用して最適化のオーバーヘッドを削減してください。詳細については、「JDBC」をご参照ください。

クエリ開始フェーズ期間 (milliseconds)

クエリ開始フェーズで費やされる時間です。このフェーズは、クエリ実行前の初期化であり、ロック待ちとスキーマバージョンの整合を含みます。

バージョン： V2.0.44+ / V2.1.22+

クエリ開始期間が長い場合は、多くの場合、ロック待ちまたは高い CPU 使用率が原因です。詳細な分析には、実行計画を使用してください。

Get Next フェーズ期間 (milliseconds)

クエリ開始フェーズの終了から、すべての結果が返されるまでの時間です。計算と結果の配信を含みます。

バージョン： V2.0.44+ / V2.1.22+

Get Next 期間が長い場合は、多くの場合、計算が複雑であることを示しています。QE メモリ使用量と QE QPS との相関を確認してください。これらのメトリクスに異常がない場合、クライアントが結果の消費に時間がかかっている可能性があります。

P99 クエリレイテンシー (milliseconds)

すべてのクエリの 99 パーセンタイルレイテンシーです。SELECT、INSERT、UPDATE、DELETE、UTILITY、およびシステムクエリを含みます。

このインスタンスにおける最長実行クエリの期間 (milliseconds)

最も実行時間が長いアクティブなクエリの期間です。SELECT、INSERT、UPDATE、DELETE、UTILITY、UNKNOWN を含みます。

バージョン： V1.1+

クエリはワーカーノード間で分散されます。このメトリックは、すべてのワーカーノードの中で最も実行時間が長いクエリを示します。たとえば、ワーカーノードが 10 分、5 分、30 秒のクエリを実行している場合、報告される値は 10 分です。

このメトリックをアクティブなクエリまたはスロークエリログと組み合わせて使用し、長時間実行されるクエリを診断し、デッドロックを解決してください。

メトリックは 1 分ごとに報告されるため、「現在の実行期間」はクエリ開始後わずかに遅れて開始されます。このメトリックは異常検出には有用ですが、正確なタイミングを示すものではありません。

失敗クエリ QPS (count/s)

1 秒あたりの失敗した SQL ステートメントの平均数です。SELECT、INSERT、UPDATE、DELETE、UTILITY、UNKNOWN を含みます。

関係式： 失敗クエリ QPS >= QE 失敗クエリ QPS + FixedQE 失敗クエリ QPS

失敗クエリの合計 QPS は、すべての失敗したクエリ (UNKNOWN、UTILITY、Engine Type={PG}) を含むため、QE と FixedQE の失敗 QPS の合計以上になります。

失敗したクエリのタイプと頻度を使用して、スロークエリログ で失敗したクエリを見つけ、根本原因を分析して可用性を向上させてください。

QE 失敗クエリ QPS (count/s)

QE エンジンによる 1 秒あたりの失敗したクエリ数です。SELECT、INSERT、UPDATE、DELETE を含みます。

バージョン： V2.2+

FixedQE 失敗クエリ QPS (count/s)

FixedQE エンジンによる 1 秒あたりの失敗したクエリ数です。SELECT、INSERT、UPDATE、DELETE を含みます。

バージョン： V2.2+

最大 FE ロック待ち時間 (milliseconds)

Hologres には、SQL ステートメントを解析、ディスパッチ、ルーティングする複数の FE ノードがあります。同一の FE 上の複数の接続が、同一のテーブルに対して DDL 操作 (CREATE や DROP など) を実行すると、FE ロックが発生します。このメトリックは、FE ごとの DDL ロック待ち時間を示します。

バージョン： V2.2+

FE ロック待ち時間が 5 分を超え、FE Replay Delay もスパイクしている場合、DDL 操作がスタックしている可能性があります。「Manage queries」を使用して、長時間実行中のクエリを特定して終了してください。

FixedQE バックエンドロック待ち時間 (milliseconds)

HQE を使用する INSERT、DELETE、または UPDATE クエリはテーブルロックを取得し、FixedPlan クエリは行ロックを取得します。このメトリックは、HQE クエリが同一テーブルのテーブルロックを保持している間に FixedPlan クエリが行ロックを待機した場合に増加します。

バージョン： V2.2+

この値が高い場合は、スロークエリログで遅い FixedQE クエリを確認し、その後「Get query insights」を使用して、ロックしている HQE クエリを特定してください。

インスタンスのバックエンドロック待ち時間の合計 (milliseconds)

インスタンス内の INSERT、DELETE、または UPDATE クエリのロック待ち時間の合計です。FixedQE と HQE のロック待ちを含みます。

バージョン： V2.2+

この値が高い場合は、スロークエリログで遅い INSERT、DELETE、または UPDATE クエリを確認し、その後「Get query insights」を使用して、ロックしている HQE クエリを特定してください。

ゲートウェイ接続数 (count)

インスタンスのゲートウェイ層における接続数の合計で、アクセス層における全体的な接続負荷を反映します。

• ゲートウェイ接続数 = FE 接続数 + FE WAL センダー + Fixed FE non-Binlog + Fixed FE Binlog。

• ゲートウェイ接続数が長時間にわたりインスタンスの制限値付近で推移している場合、接続リソースが飽和状態に近づいています。アイドル接続をクリーンアップするか、スケールアップして接続キャパシティを増やしてください。

最大ゲートウェイ接続使用率 (%)

ゲートウェイ接続使用率のピーク値で、アクセス層の接続プールに対するピーク時の負荷を反映します。使用率が継続的に 100% に近づく場合、新規接続が失敗する可能性があります。ゲートウェイ接続数のメトリックとあわせて調査し、スケールアップを検討してください。

FE 接続数 (count)

FE (フロントエンド) ノードの接続数で、SQL の解析およびルーティング層における接続負荷を反映します。Hologres はインスタンスの仕様に基づいて、FE 接続数のデフォルトの制限値を設定します。詳細については、「Instance management」をご参照ください。アクティブ、アイドル、およびトランザクション中でアイドル状態の接続を含みます。[Manage connections] を使用して現在の接続使用状況を確認し、リソースが不足している場合はアイドル接続を終了してください。

データベース別の FE 接続数 (count)

データベース別に分類した FE 接続数で、最も多くの接続を消費しているデータベースの特定に使用します。

FE ノード別の FE 接続数 (count)

FE ノード別に分類した FE 接続数で、ノード間で接続負荷が均等に分散されているかどうかを評価するために使用します。

• FE ノードあたりのデフォルトの接続上限：128。合計の上限については、「Instance management」をご参照ください。

• いずれかのノードの接続数が上限に近づいた場合は、アイドル接続とアクティブ接続を確認してください。[Manage connections] を使用してアイドル接続をクリーンアップするか、スケールアップしてください。

• ノード間で接続負荷に偏りがある場合は、[Manage connections] を使用してアイドル接続を特定し、クリーンアップしてください。

最大 FE 接続使用率 (%)

FE 接続使用率のピーク値 (Max(frontend_connection_used_rate)) です。このメトリックは、いずれかの FE ノードが接続上限に近づいている状態を検出するために使用します。FE ノードは、ラウンドロビン方式で負荷を分散します。[Manage connections] を使用して使用状況の詳細を確認し、必要に応じてアイドル接続を終了してください。

FE ノード別の FE WAL センダー数 (count)

FE ノードあたりの WAL センダー数です。JDBC 経由で Binlog を消費する場合、各テーブルの各シャードで 1 つの WAL センダー接続を使用します。WAL センダー接続は通常の接続とは独立しており、独自の制限が設けられています。このメトリックを使用して、FE ノードごとの WAL センダー使用率を監視してください。

最大 WAL センダー使用率 (%)

WAL センダー使用率のピーク値で、Binlog 関連の接続に対する最大の負荷を反映します。使用率が制限値に近づいた場合、Binlog の消費に影響が出る可能性があります。必要に応じて調査し、スケールアップしてください。

Fixed FE 接続数 (non-Binlog) (count)

Fixed FE ノードの non-Binlog 接続数で、Fixed Plan の実行パスにおける接続負荷を反映します。

Fixed FE Binlog 接続数 (count)

Fixed FE ノードの Binlog 接続数で、Fixed Plan の実行パスにおける Binlog 関連の接続負荷を反映します。

キュー内のクエリ数 (count)

実行待ちのクエリリクエスト数。

バージョン： V3.0+

クエリキュー投入 QPS (count/s)

システムキューに 1 秒あたりに投入されるクエリ数。システム負荷とクエリ頻度の目安として使用します。

バージョン： V3.0+

待機状態から実行状態へ遷移するクエリの QPS (count/s)

待機状態から実行状態へ遷移するクエリ数 (1 秒あたり)。

バージョン： V3.0+

クエリキューの最終状態別 QPS (count/s)

1 秒あたりにクエリキューの処理を終えたクエリ数を、最終状態別に示します：

• kReadyToRun：実行可能

• kQueueTimeout：キュータイムアウトにより失敗

• kCanceled：キャンセルにより失敗

• kExceedConcurrencyLimit：同時実行数制限により失敗

バージョン： V3.0+

平均クエリキュー待機時間 (ミリ秒)

キューに入ってから処理が開始されるまでの平均時間です。実際のクエリ実行時間は含まれません。

バージョン: V3.0+

Query Queue Auto-Rate-Limit Max Concurrency (count)

The maximum concurrency for auto-rate-limited query queues.

Version: V3.1+. Compute group instances only.

標準 I/O 読み取りスループット (bytes/s)

標準ストレージの読み取りスループットです。

標準 I/O 書き込みスループット (bytes/s)

標準ストレージの書き込みスループットです。

低頻度 I/O 読み取りスループット (bytes/s)

低頻度アクセスストレージの読み取りスループットです。

低頻度 I/O 書き込みスループット (bytes/s)

低頻度アクセスストレージの書き込みスループットです。

スタンダードストレージ使用容量 (bytes)

スタンダードストレージで使用されている容量です。使用量が購入容量を超える場合は、ストレージをスケールアップしてください。

スタンダードストレージ使用率 (%)

スタンダードストレージ容量の使用率です。使用量が購入容量を超える場合は、ストレージをスケールアップしてください。

IA ストレージ使用容量 (bytes)

IA ストレージで使用されている容量です。使用量が購入容量を超える場合は、ストレージをスケールアップしてください。

IA ストレージ使用率 (%)

IA ストレージ容量の使用率です。使用量が購入容量を超える場合は、ストレージをスケールアップしてください。

ごみ箱ストレージ使用容量 (bytes)

バージョン： V3.1+

Hologres は V3.1 以降、テーブルごみ箱をサポートしています。DROP で削除されたテーブルは保持期間中ごみ箱に残るため、誤って削除されたテーブルを復元できます。これらのテーブルは、引き続きインスタンスストレージを消費します。

データベースごとにごみ箱の使用容量を監視してください。頻繁なテーブル削除によりごみ箱の使用容量が多い場合は、削除時にごみ箱をスキップするようテーブルを設定してください。

FE リプレイ遅延 (ミリ秒)

バージョン： V2.2+

Hologres には複数の FE ノードがあります。DDL 操作は、1 つの FE で実行され、他の FE でリプレイされます。ミリ秒または秒単位のリプレイ遅延は正常です。

FE のリプレイ遅延が数分を超える場合、DDL 操作が多すぎてリプレイ プロセスが処理しきれていない可能性があります。遅延が増加し続ける場合、クエリがスタックしている可能性があります。hg_stat_activity を使用して長時間実行中のクエリを特定し、終了してください。

シャードのマルチレプリカ同期遅延 (ミリ秒)

レプリケーションを有効化した後の、シャード レプリカ間の同期遅延です。

シャード レプリカの遅延は通常ミリ秒単位です。大量のデータ書き込みや更新、または頻繁な DDL 操作により、同期遅延が増加する可能性があります。

プライマリ・フォロワー同期遅延 (ミリ秒)

フォロワーインスタンスがプライマリインスタンスからデータを読み取る際の遅延です。このメトリックはプライマリインスタンスではなく、フォロワーインスタンスでのみ表示されます。

• データは、フォロワーインスタンスをプライマリインスタンスにバインドした後にのみ表示されます (初期値は 0 ms)。プライマリインスタンスで書き込みが発生すると、同期遅延は変動します。

• 正常な同期遅延はミリ秒単位です。プライマリでの DDL 操作による断続的なジッターは、無視しても問題ありません。数秒を超える遅延が継続する場合は、インスタンスの負荷が高いか、リソースが不足している可能性があります。CPU とメモリの使用量を確認し、必要に応じてスケールアップしてください。

• 再起動やアップグレードの実行中に、同期遅延が数分まで急増することがありますが、その後は自動的に復旧します。

インスタンス間ファイル同期遅延 (ミリ秒)

ディザスタリカバリ インスタンス間のファイル同期遅延です。このメトリックはフォロワーインスタンス (読み取り専用フォロワー) でのみ表示されます。

データベースごとの統計情報が欠落しているテーブル数

各データベースで統計情報が欠落しているテーブルの数です。

バージョン： V2.2+

Hologres V2.0 以降では、自動 ANALYZE はデフォルトで実行されます。テーブル作成や一括書き込み/更新の後、統計情報が一時的に遅れることがあるため、まずは短期間様子を見てください。

データベースで統計情報が数時間から数日間継続して欠落している場合、自動 ANALYZE がトリガーされていない可能性があります。HG_STATS_MISSING ビューを使用して影響を受けるテーブルをリストアップし、手動で ANALYZE を実行してください。詳細については、「ANALYZE と自動 ANALYZE」をご参照ください。

サーバーレスコンピューティングの最長実行中クエリ期間 (milliseconds)

サーバーレスコンピューティングにおける最長実行中クエリの期間。サーバーレスコンピューティングは、メインインスタンスから分離された専用リソースプールで特定のクエリを実行します。

バージョン： V2.1+

hg_stat_activity を使用して、サーバーレスコンピューティング クエリのステータスを確認してください。

サーバーレスコンピューティングのクエリキュー数 (count)

サーバーレスコンピューティングのリソースプールでキューに入っているクエリ数。

バージョン： V2.2+

サーバーレスコンピューティングのリソースクォータ使用率 (%)

実際に使用されているサーバーレスコンピューティング リソースの、割り当て可能な最大リソースに対する比率。

バージョン： V2.2+

バイナリログ消費レート (カウント/秒)

1 秒あたりに消費されるバイナリログ エントリの数です。Hologres は、リアルタイムのデータ階層化と高速なデータ転送のために、Hologres バイナリログのサブスクライブをサポートしています。

バージョン： V2.2+

バイナリログ消費レート (バイト/秒)

1 秒あたりにバイナリログから消費されるバイト数です。フィールドが大きい、またはデータ量が多いと、バイト数は増加します。

バージョン： V2.2+

FE ごとの WAL センダー数 (カウント)

FE ノードごとに使用される WAL センダーの数です。JDBC を使用してバイナリログを消費する場合、各テーブルの各シャードは 1 つの WAL センダー接続を消費します。WAL センダー接続は通常の接続とは独立しており、デフォルトの制限があります。

バージョン： V2.2+

最も使用率の高い FE の WAL センダー使用率 (%)

すべての FE ノードにわたる WAL センダーのピーク時の使用率です。

バージョン： V2.2+

WAL センダーの使用率が制限に達した場合は、トラブルシューティングについては「JDBC経由でHologresバイナリログを消費する」をご参照ください。

コンピューティンググループのエラスティックコア数

コンピューティンググループで、時間ベースのスケーリングによって追加されたコア数です。詳細については、「時間ベースのエラスティシティ (Beta)」をご参照ください。

バージョン： V2.2.21+。 コンピューティンググループインスタンスのみ。

コンピューティンググループの自動エラスティックコア数 (count)

コンピューティンググループで、オートスケーリングによって追加されたコア数です。詳細については、「マルチクラスターと自動エラスティシティ (Beta)」をご参照ください。

バージョン： V4.0+。 コンピューティンググループインスタンスのみ。

ゲートウェイ CPU 使用率 (%)

インスタンス内の各ゲートウェイの CPU 使用率です。

バージョン： V2.0+。 コンピューティンググループインスタンスのみ。

ゲートウェイはラウンドロビン方式のトラフィック転送を使用するため、新規接続がなくても CPU 使用率が発生します。V2.2.22 以降、ゲートウェイは接続処理を改善するために、デフォルトでより多くのワーカースレッドを起動します。これにより、ベースライン CPU 使用率が増加します。

ゲートウェイのメモリ使用率 (%)

インスタンス内の各ゲートウェイのメモリ使用率です。

バージョン： V2.0+。 コンピューティンググループインスタンスのみ。

ゲートウェイの 1 秒あたりの新規接続リクエスト (カウント/秒)

システムが 1 秒あたりに受け入れて正常に確立できる新規接続の最大数です。

バージョン： V2.1.12+。 コンピューティンググループインスタンスのみ。

1 つのゲートウェイは、1 秒あたり約 100 の新規接続を処理します。新規接続リクエストが 100 x ゲートウェイ数 に近づく場合、ゲートウェイがボトルネックです。コネクションプールを設定するか、ゲートウェイの数を増やしてください。

ゲートウェイのインバウンドトラフィックレート (B/s)

1 秒あたりにゲートウェイ経由で流入するデータの量です。

バージョン： V2.1+。 コンピューティンググループインスタンスのみ。

インバウンドトラフィックが 200 MiB/s x ゲートウェイ数 に近づく場合、ゲートウェイのネットワーク帯域幅がボトルネックです。ゲートウェイの数を増やしてください。

ゲートウェイのアウトバウンドトラフィックレート (B/s)

1 秒あたりにゲートウェイから送信されるデータの量です。

バージョン： V2.1+。 コンピューティンググループインスタンスのみ。

アウトバウンドトラフィックが 200 MiB/s x ゲートウェイ数 に近づく場合、ゲートウェイのネットワーク帯域幅がボトルネックです。ゲートウェイの数を増やしてください。