メトリック ダッシュボード

Lakebaseアプリのメトリクスダッシュボードは、システムおよびデータベースのメトリクスを監視するためのグラフを提供します。 開くには、Lakebase Appのサイドバーで 「モニタリング 」をクリックし、「 メトリクス 」タブを選択してください。観測可能な指標には、RAM使用量、CPU使用率、接続数、データベースサイズ、デッドロック、行操作、レプリケーション遅延、キャッシュ性能、ワーキングセットサイズが含まれます。

ダッシュボードには、選択したブランチとコンピューティングのメトリックが表示されます。 ドロップダウン メニューを使用して、別のブランチまたはコンピューティングのメトリックを表示します。 定義済みの期間 (過去 1 時間、 過去 1 日、 過去 7 日間) から選択するか、[ その他 ] を選択して追加オプション ([過去 3 時間]、[ 過去 6 時間]、[ 過去 12 時間]、[ 過去 2 日間]、または [カスタム] ) を選択できます。 [更新] ボタンを使用して、表示されるメトリックを更新します。

非アクティブなコンピューティングについて

グラフにデータが表示されない場合は、 0 にスケーリングされるため、コンピューティングが非アクティブである可能性があります。

コンピューティングが非アクティブな場合、アクティブなコンピューティングがデータをレポートする必要があるため、メトリック値は 0 に低下します。 非アクティブな期間は、グラフの対角線パターンとして表示されます。

グラフにデータが表示されない場合は、別の期間を選択するか、さらに使用状況データが収集された後で戻ってみます。

RAM

RAMグラフは、選択した計算に対する割り当てされたRAMと時間経過の使用量を示します。

これには、次のメトリックが含まれます。

割り当て済み: 割り当てられた RAM の量。

RAM は、コンピューティングのサイズまたは 自動スケール 構成に従って割り当てられます。 自動スケーリングでは、負荷に応じてコンピューティングがスケールアップおよびスケールダウンされると、割り当てられた RAM が増減します。 ゼロにスケーリングが有効になっており、コンピューティングが非アクティブ状態の後にアイドル状態に移行すると、割り当てられた RAM は 0 に低下します。

使用済み: 使用された RAM の量。

このグラフには、RAM 使用率を示す線がプロットされます。 回線が定期的に割り当てられた最大 RAM に達する場合は、コンピューティング サイズを増やすことを検討してください。 コンピューティング サイズのオプションについては、「 コンピューティングのサイズ設定」を参照してください。

キャッシュ済み: 以前のクエリと操作によってメモリにキャッシュされたデータの量。

CPU

CPUグラフは、選択した計算に対して割り当てられたCPUと時間経過した使用状況を示します。

割り当て済み: 割り当てられた CPU の量。

CPU は、コンピューティングのサイズまたは 自動スケール 構成に従って割り当てられます。 自動スケールでは、負荷に応じてコンピューティングがスケールアップおよびスケールダウンされると、割り当てられた CPU が増減します。 ゼロにスケーリングが有効になっていて、コンピューティングが非アクティブ状態の後にアイドル状態に移行すると、割り当てられた CPU は 0 に低下します。

使用済み: コンピューティング ユニット (CU) で使用される CPU の量。

プロットされた線が定期的に割り当てられた最大 CPU に達する場合は、コンピューティング サイズを増やすことを検討してください。 コンピューティング サイズのオプションについては、「 コンピューティングのサイズ設定」を参照してください。

Postgresの接続もカウントされます

Postgresの接続数グラフは、選択した計算の最大接続数、アイドル接続数、アクティブ接続数、そして時間経過の接続総数を示します。

アクティブ: 選択したコンピューティングのアクティブな接続の数。

アクティブな接続を監視すると、データベースのワークロードを理解するのに役立ちます。 アクティブな接続の数が一貫して多い場合、データベースの負荷が高くなり、クエリの応答時間が遅くなるなどのパフォーマンスの問題が発生する可能性があります。

アイドル: 選択したコンピューティングのアイドル状態の接続の数。

アイドル状態の接続は開かれているが、現在は使用されていません。 一般的に、いくつかのアイドル状態の接続は無害ですが、大量の接続で不要なリソースが消費される可能性があり、アクティブな接続の領域が少なくなり、パフォーマンスに影響を与える可能性があります。 不要なアイドル状態の接続を特定して閉じると、リソースの解放に役立ちます。

合計: 選択したコンピューティングのアクティブな接続とアイドル状態の接続の合計。

最大: コンピューティング サイズに対して許可される同時接続の最大数。

[最大] 行は、接続制限に達するまでの時間を視覚化するのに役立ちます。 [合計接続数] が [最大] 行に近づく場合は、次の点を考慮してください。

• より多くの接続を可能にするためにコンピューティング サイズを増やす
• アプリケーションの接続管理の最適化 (接続プールの使用、未使用の接続の迅速な終了、有効期間の長いアイドル状態の接続の回避)

接続制限は Postgres max_connections 設定によって定義され、コンピューティング サイズの構成によって決まります。 コンピューティング サイズ別の最大接続の完全な一覧については、 コンピューティングの仕様に関するページを参照してください。

データベース サイズ

データベースサイズグラフは、選択したデータベースまたは選択したブランチのすべてのデータベースの実際のデータサイズを示します。

データベースが ストレージ クォータに達すると、書き込みパフォーマンスが低下します。

デッドロック

デッドロックグラフは、時間経過によるデッドロックの数を示しています。

デッドロックは、他のトランザクションが必要とするリソースを保持し、トランザクションの進行を妨げる依存関係のサイクルを作成することによって、2 つ以上のトランザクションが同時に互いをブロックした場合に発生します。 これにより、パフォーマンスの問題やアプリケーション エラーが発生する可能性があります。 Postgres でのデッドロックの詳細については、 PostgreSQL のデッドロックに関するドキュメントを参照してください。

Rows

行グラフは、時間とともに削除、更新、挿入された行の数を示しています。 行メトリックは、コンピューティングが再起動されるたびに 0 にリセットされます。

挿入、更新、削除された行を時系列で追跡すると、データベースのアクティビティ パターンに関する分析情報が得られます。 このデータを使用して、挿入の急増や異常な数の削除など、傾向や不規則性を特定できます。

キャッシュヒット率の計算

Compute cache hitrate グラフは、ストレージからではなく、計算キャッシュから提供された読み取りリクエストの割合を示しています。 ストレージからのリードはコストが高く、クエリ性能が遅くなることがあります。

OLTP ワークロードの場合は、キャッシュ ヒット率 99% 以上を目指します。 レートが 99%を下回る場合、ワーキング セットがメモリに収まらないため、パフォーマンスが低下する可能性があります。 キャッシュヒット率を向上させるには、計算容量を増やしてキャッシュを拡張してください。 理想的な比率は作業負荷によって異なります。大きなテーブルを逐次スキャンするワークロードは、やや低い比率でも許容範囲で動作することがあります。

:::情報 コンピュートキャッシュについて

コンピュートキャッシュは頻繁にアクセスされるデータをコンピュートのローカルメモリに保存するため、ストレージからの読み込みを減らします。 コンピュートキャッシュは最大75% のコンピュートRAMを使用できます。 例えば、8 GB RAMの計算は6 GBの計算キャッシュを持っています。 最適なパフォーマンスを得るためには、計算セットのサイズを計算キャッシュ内に収めるように調整してください。

:::

ワーキング セットのサイズ

ワーキング セットは、特定の時間間隔でアクセスされる Postgres ページ (リレーション データとインデックス) の個別のセットのサイズです。 最適なパフォーマンスと一貫したレイテンシのために、ワーキングセットが計算キャッシュに収まるように計算サイズを調整し、迅速にアクセスできるようにしましょう。

ワーキングセットサイズグラフは、一定区間でアクセスされたデータ量(ページサイズ×アクセスされたユニークなページ数として計算)を可視化します。 グラフには次の情報が表示されます。

5 分 (5 分): 過去 5 分間にアクセスされたデータ。

15 分 (15 分): 過去 15 分間にアクセスされたデータ。

1h (1 時間):過去 1 時間にアクセスされたデータ。

計算キャッシュサイズ:計算キャッシュのサイズで決まります。 コンピューティングが大きいほど、キャッシュが大きくなります。

最適なパフォーマンスを得るためには、計算キャッシュは一定時間間でワーキングセットのサイズより大きくする必要があります。 ワーキングセットのサイズが計算キャッシュサイズより大きい場合は、キャッシュヒット率を向上させるために計算の最大サイズを増やしてください。 コンピューティングのサイズ設定のオプションと仕様については、「 コンピューティングの仕様」を参照してください。

作業量のパターンが時間とともにあまり変わらない場合は、1時間のワーキングセットサイズと計算キャッシュサイズを比較し、ワーキングセットのサイズが計算キャッシュサイズより小さいことを確認してください。

レプリケーション遅延バイト数

レプリケーション遅延バイトグラフは、プライマリ計算から送信されたがまだレプリカに適用されていないデータの総サイズ(バイト単位)を示します。 値が大きいほど、レプリケートを待機しているデータのバックログが高いことを示します。これは、レプリカでのレプリケーションスループットまたはリソースの可用性に関する問題を示唆する可能性があります。

レプリケーションの遅延時間 (秒)

レプリケーション遅延秒グラフは、プライマリ計算で最後にコミットされたトランザクションからそのトランザクションがレプリカに適用されるまでの時間遅延(秒単位)を示しています。 値が大きいほど、レプリカがプライマリの背後にあることを示します。これは、ネットワーク待機時間、レプリケーションの負荷の高さ、レプリカのリソースの制約が原因である可能性があります。

その他のリソース

• アクティブなクエリ
• クエリ パフォーマンス
• システム操作
• 自動スケーリング
• ゼロにスケールする