Sizing PEM deployments

Sizing PEM deployments#

適切な量のリソースをPEMサーバーに割り当て、PEMのリソース要件を促進する重要な要素を理解することが重要です。 Tシャツのサイズは、開始するのに役立ちます。

!!!重要PEMはPostgresです PEMは基本的にPostgresデータベースに基づいて構築されており、コアロジックのほとんどはSQLファンクションを介して実行されます。 PEMを標準のPostgresインスタンスとして扱うことが重要です。最適な応答性を保証には、従来のPostgresの構成と調整のベストプラクティスをすべて遵守してください。 PEMはパフォーマンスも監視します。ダッシュボード、 Performance Diagnostic 、 Upgrading SQL Profiler などの統合ツールを使用して、その動作を分析および理解できます。

リソース要件に影響を与える要因#

エージェント/接続の数#

エージェントの数は、Postgresデータベースへの接続数を直接決定します。すべての接続が新しいプロセスを開始するため、接続数はPostgres展開全体のリソース消費における重要な要素です。

デフォルトでは、ほとんどのエージェントは1つの接続を使用します。 enable_heartbeat_connection がtrueに設定されている場合、各エージェントは2つの接続を使用します。 alert_threads 、enable_smtp 、enable_webhooks 、またはenable_snmp セットで構成されたエージェントは、これらの機能用に追加の接続を開きます。

これらの接続の多くは、ほとんどの時間アイドル状態であるため、 max_connections を他の方法よりもわずかに高く設定しても安全です。ただし、これはまだPostgresであることに注意することが重要です。接続数が100を超えると、接続オーバーヘッドが急速にリソースを消費します。このため、大規模なPEM展開の場合、pgBouncerを展開して接続を効率的に管理することを強くお勧めします。

適度な数または適切な接続プーリングを使用して接続を効果的に管理すると仮定すると、メモリとCPUのニーズは次の要素によって決定されます。

頻繁にアクセスされるデータのサイズ - メモリ#

メモリサイズの推奨事項は、最も頻繁に使用されるデータがPostgresの共有バッファに完全に存在し、ディスクI/Oを最小限に抑え、パフォーマンスを最大化するように設計されています。この優先度の高い、頻繁にアクセスされるデータには次のものが含まれます。

  • pemdata スキーマ、すべてのプローブによって収集された最新のデータポイントを保存します。

  • プローブの実行とアラートディスパッチを管理するために使用されるpem スキーマのさまざまなテーブル。

この重要なデータのサイズは、主にプローブの合計数と各プローブが返すデータの量によって決まります。実際、このサイズは、監視対象データベースオブジェクトの数、特にテーブルやインデックスのような多数のオブジェクトによって決まります。

以下の推奨サイズは、RAMの約25%が共有バッファー専用にされるという仮定に基づいています。

プローブとアラートの実行速度 - CPUおよびアラートスレッド#

PEMは、新しいプローブデータの取り込みと、構成されたアラートしきい値と比較してそのデータの評価という2つの重要なタスクを常に実行します。したがって、PEMには、設定済みのすべてのプローブとアラートを指定された周波数で実行するための十分なCPU時間が必要です。たとえば、1分に1回実行するように設定された100のアラートを使用したセットアップでは、1分あたり100のアラート評価の処理能力が必要です。この必要な実行レートを満たさないと、アラートが遅延されるか、アラートが完全にトリガーされない可能性があります。

アラートとプローブの実行数は次のようにスケールします。

  • プローブとアラートの数

  • プローブとアラートの設定された頻度

推奨されるCPU数は、PEMがデフォルト構成を使用してすべてのプローブとアラートに必要な実行レートを維持できるように計算されます。多くの追加アラートまたはプローブを有効にするか、実行周波数を増やすことによりセットアップをカスタマイズする場合、遅延を防ぐためにそれに応じてCPUをスケーリングする必要がある場合があります。

!!!重要 アラートスレッド 大規模な展開では、PEMホスト上のPEMエージェント構成のアラートスレッドの合計数を増やす必要があります。アラートスレッドの数は、PEMがアラート評価に使用できるCPUコア数を制限するため、これを正しく調整してアラート遅延の発生を回避し、PEMにプロビジョニングされたCPUリソースを効果的に利用することが重要です。

PEMホストで実行されているPEMエージェントのalert_threads 設定を変更することにより、アラートスレッドの数を変更できます。

アラート評価が複数のスレッドで共有される効率はPEM 10.5で大幅に向上したため、既存のシステムでこのパラメーターを調整する前に、PEMバージョンが少なくとも10.5であることを確認してください。

PEMのストレージニーズは、主に保持する履歴データの量によって決まります。

この量を促進する3つの主な要因。

  • 監視対象オブジェクト数 - 収集されたデータの生の量通常はテーブルやインデックスなどの多数のオブジェクトによって占められます。

  • データの更新頻度 - プローブデータが変更される頻度PEMは圧縮を適用するため、繰り返される未変更の値が追加の領域を消費しません。

  • データ保持期間 - 履歴データが保持される設定された期間。

推奨されるストレージサイズは、PEMのデフォルトのプローブ頻度、標準の保持期間、および推定データ圧縮率に基づいています。

PEM Tシャツのサイズ#

重要

上記で説明したすべての理由から、PEMサーバーの負荷は、監視している不動産の性質に大きく依存します。サイズガイドは開始点です。大規模なサイズの場合、監視対象サーバーのサブセットをPEMに追加し、リソース使用量を測定することから始めることを強くお勧めします。最終的なリソースニーズが私たちが提案するものと大幅に異なっていても、驚かないでください。

CPUおよびアラートスレッドの要件は、エージェントの数よりも速くスケールするため、システムのサイズを2倍にすると、リソース要件が単に2倍になると考えないことにも注意してください。

edb_excla_notran_3 .. csv-table::
header:

Size,Description,Component,CPUs,RAM,Storage,IOPS,Other Notes

widths:

5,10,5,5,5,5,5,8

align:

left

class:

longtable

Nano,PEMのテスト用、1〜2の監視対象サーバー、シングルユーザー,—,1,2 GB,20 GB,<100,— Tiny,少数のWebアプリユーザーを含む単一のHAクラスターの場合,—,2,4 GB,50 GB,<100,— Small,"≤50サーバー、5人未満の同時Webユーザーの場合。 >50,000のテーブル/インデックスの場合、より高くなります",—,3,6 GB,200 GB,300,— Medium,"サーバー100以下の場合、最大5人の同時Webユーザー。 >100,000のテーブル/インデックスの場合、より高くなります",—,4,8 GB,400 GB,600,Use pgBouncer if heartbeat connections are enabled Large,"サーバー300以下の場合、同時ユーザー数〜10。 >250,000のテーブル/インデックスの場合、より高くなります",Backend,6,16 GB,2 TB,2000,"~2 alert threads, pgBouncer " "",NA,Frontend,1–2,2–4 GB,20 GB,<100,— X Large,"サーバー600以下の場合、同時ユーザー10人以上。 >500,000テーブル/インデックスの場合、より高くなります",Backend,10,32 GB,3 TB,4000,"~5 alert threads, pgBouncer " "",NA,Frontend,2,4 GB,20 GB,100,— XX Large,"サーバー≤1000の場合、同時ユーザー10人以上。 >1000,000のテーブル/インデックスの場合、より高くなります",Backend,22,48 GB,4 TB,6000,"~12 alert threads, pgBouncer " "",NA,Frontend,2,4 GB,20 GB,100,—

適切な調整と十分なリソースがあれば、1000を超えるエージェントを含むPEMシステムを実行できます。ただし、追加される各エージェントの増分リソースコストの増加は、大規模なPEMシステムが複数の小規模なPEMシステムよりもはるかに効率が低いことを意味します。このため、単一のシステムが600〜800エージェントを超えないように、PEMシステム全体に不動産をセグメント化することをお勧めします。

目次