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ホストで実行されているPEMエージェントのalert_threads
設定を変更することにより変更できます。
履歴データのサイズ - ストレージ#
PEMのストレージニーズは、主に保持する履歴データの量によって決まります。
この量を促進する3つの主な要因。
監視対象オブジェクト数 この数は、収集されたデータの生の量を決定します通常はテーブルやインデックスなどの多数のオブジェクトによって支配されます。
データの更新頻度 プローブデータが変更される頻度PEMは圧縮を適用するため、繰り返される未変更の値が追加の領域を消費しません。
データ保持期間 履歴データが保持されるように構成されている期間。
推奨されるストレージサイズは、PEMのデフォルトのプローブ頻度、標準の保持期間、および推定データ圧縮率に基づいています。
PEM Tシャツのサイズ#
重要
上記で説明したすべての理由から、PEMサーバーの負荷は、監視している不動産の性質に大きく依存します。 以下のサイズガイドは単なる開始点です。 大規模なサイズの場合、監視対象サーバーのサブセットをPEMに追加し、リソース使用量を測定することから始めることを強くお勧めします。 最終的なリソースニーズが以下に提案されるものと大幅に異なっていても、驚かないでください。
Size |
Description |
Component |
CPUs |
RAM |
Storage |
IOPS |
Other Notes |
|---|---|---|---|---|---|---|---|
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のテーブル/インデックスの場合、より高くなります |
— |
4 |
8 GB |
200 GB |
300 |
— |
Medium |
サーバー100以下の場合、最大5人の同時Webユーザー。 >100,000のテーブル/インデックスの場合、より高くなります |
— |
6 |
16 GB |
300 GB |
500 |
Use pgBouncer if heartbeat connections are enabled |
Large |
サーバー300以下の場合、同時ユーザー数〜10。 >250,000のテーブル/インデックスの場合、より高くなります |
Backend |
8 |
32 GB |
1.5 TB |
2000 |
~2 alert threads, pgBouncer |
NA |
Frontend |
1–2 |
2–4 GB |
20 GB |
<100 |
— |
|
X Large |
サーバー600以下の場合、同時ユーザー10人以上。 >500,000テーブル/インデックスの場合、より高くなります |
Backend |
12 |
48 GB |
3 TB |
4000 |
~3 alert threads, pgBouncer |
NA |
Frontend |
2 |
4 GB |
20 GB |
100 |
— |
|
XX Large |
600を超えるサーバーの場合、 - 複数のPEMドメインをお勧めします |
— |
— |
— |
— |
— |
Segment estate into multiple PEM deployments |