コンテンツにスキップ
JelinaJelina Documentation技術ドキュメント
公式サイトに戻る

AFE-E620 における EMS Builder 性能試験報告

報告バージョン： v1.0
試験日： 2026-07-30 ～ 2026-07-31
報告日： 2026-07-31
集計方法： 各シナリオで 2,002 回取得し、先頭・末尾を除外した sample_no=2～2001 の 2,000 件の有効リソースサンプルのみを集計
関連マニュアル： Edge-EMS Builder 性能試験マニュアル

1. 性能結果の概要

Section titled “1. 性能結果の概要”
✅ AFE-E620 の推奨稼働シナリオ：S2.5
今回実測した 6 シナリオでは、S2.5 がタスク達成率 99% の参考基準を満たす最大負荷でした。AFE-E620 のメモリーは 982 MB のみで、全シナリオで使用率が高く、メモリーが主な容量制約です。変化時保存（値が変化しない場合も遅くとも 10 秒ごとに保存）を使用し、次の負荷を現在検証済みの推奨設定とします。
📡
2,000 ポイント/秒
データ収集設定量
🧮
20 個
集約演算
⚡
40 回/秒
Trigger 目標
☁️
10 回/秒
MQTT タスク目標
🤝
2 回/秒
協調タスク
💾
変化時保存
遅くとも 10 秒ごとに保存
🧠
26.24% / 45.54%
装置全体 CPU 平均 / P95
🗄️
80.01% / 86.10%
装置全体メモリー 平均 / P95
⏱️
25 ms
Trigger P95
📨
56 ms
MQTT P95

Trigger の 1 回の実行は、デバイス制御 1 回、ローカルアラームと MQTT アラーム、集約データ書き込み 1 回を表します。Edge-EMS Builder はデバイスのメモリーに応じて PostgreSQL へリソースを割り当てるため、デバイス、データベース規模、キャッシュ状態によって使用量は大きく変わる場合があります。AFE-E620 の物理メモリーは 982 MB で、AFE-E630 より余裕が小さいため、容量計画ではメモリーを優先的に確認してください。

1.1 主な結論

Section titled “1.1 主な結論”

AFE-E620 は S2.5 での運用を推奨します。2,000 ポイント/秒、集約演算 20 個、Trigger 40 回/秒、MQTT 10 回/秒、協調タスク 2 回/秒とし、10 秒の変化時保存を有効にします。

S2.5 の実測は Trigger 39.96 回/秒、MQTT 9.98 回/秒、達成率は 99.91% / 99.82%、P95 は 25 ms / 56 ms でした。CPU 使用率 P95 は 45.54%、装置全体の実メモリー P95 は 86.10%、サンプリングタイムアウトは 8 回でした。

長期の本番稼働では、S2.5 の実測負荷に約 20% の設計余裕を確保し、初期容量をおおむね 1,600 ポイント/秒、Trigger 32 回/秒、MQTT 8 回/秒、協調タスク 2 回/秒以下として計画することを推奨します。これは実測設定から換算した設計上の値であり、独立したシナリオとして試験したものではありません。本番前には実際のスクリプト、メッセージサイズ、履歴データ量で再試験してください。

1.2 シナリオ別状態

Section titled “1.2 シナリオ別状態”
アイコン シナリオ 結論
🟢 S1 基準シナリオに合格、達成率 100%。ただし装置全体の平均メモリー使用率はすでに 74.02% と高い。
🟡 S2 リアルタイム保存で Trigger / MQTT 達成率は 98.65% / 98.76% と 99% 基準をわずかに下回り、サンプリングタイムアウトは 34 回。
🟢 S2.5 99% 基準を達成した最大負荷で、AFE-E620 の現在の推奨シナリオ。
🔴 S3 不合格。Trigger / MQTT 達成率は 43.08% / 44.65% にとどまり、遅延が大幅悪化。サンプリングタイムアウトは 617 回。
🔴 S3.5 不合格。変化時保存で S3 より改善したが、達成率 87.30% / 86.69% は 99% 基準未満。
🔴 S6 深刻な過負荷。Trigger / MQTT 達成率は 19.15% / 19.18%、サンプリングタイムアウトは 886 回。

2. 結論の要約

Section titled “2. 結論の要約”
  • 今回は S1、S2、S2.5、S3、S3.5、S6 の 6 シナリオを試験しました。その他のシナリオは表、比較、結論に含めません。
  • S2.5 は設定負荷 2,000 ポイント/秒で、Trigger 達成率 99.91%、MQTT 達成率 99.82%、Trigger / MQTT の P95 は 25 ms / 56 ms でした。
  • S2 と S2.5 の業務負荷は同じです。変化時保存により CPU 使用率平均は 29.41% から 26.24%、P95 は 52.01% から 45.54% へ低下し、Trigger 達成率は 98.65% から 99.91% へ改善しました。
  • S3 と S3.5 の業務負荷は同じです。変化時保存により Trigger 達成率は 43.08% から 87.30%、MQTT は 44.65% から 86.69% へ改善し、CPU 使用率 P95 は 82.71% から 66.05% へ低下しましたが、不合格でした。5,000 ポイント/秒は AFE-E620 の持続的な処理能力を超えています。
  • AFE-E630 との比較：E630 は S3.5（5,000 ポイント/秒、Trigger 90 回/秒）を処理でき、E620 の検証済み上限は S2.5（2,000 ポイント/秒、Trigger 40 回/秒）です。メモリーの差（3.81 GB と 982 MB）が主な要因です。
  • 全シナリオの Trigger に約 10～11 秒の単一実行ロングテールがありました。過負荷ではさらに増大し、S3.5 の単一実行最大値は Trigger 53,472 ms、MQTT 53,373 ms でした。
  • 全シナリオで装置全体のメモリー使用率平均は 74% を超え、S3 以降の P95 は 91% 超でした。メモリーは E620 の全シナリオ共通のボトルネックで、継続監視が必要です。
  • 各シナリオの有効サンプルは 2,000 秒（約 33 分 20 秒）のみです。性能比較には適しますが、72 時間安定性試験の代わりにはなりません。

3. 集計方法

Section titled “3. 集計方法”

3.1 サンプル選択

Section titled “3.1 サンプル選択”

監視は回数指定で行いました。各シナリオの元リソースデータは sample_no=1～2002 を含みます。

除外：sample_no = 1
集計：sample_no = 2～2001，計 2,000 回
除外：sample_no = 2002

先頭・末尾のサンプルを除くことで、開始・終了時の 1 秒未満のデータを集計から外します。Trigger と MQTT の全体結果は 2,000 秒を分母とします。タスク記録のない秒も平均処理量に含め、記録のある秒だけを集計してスループットを過大評価しないようにします。

3.2 EMS Builder 全体の範囲

Section titled “3.2 EMS Builder 全体の範囲”

次の 5 サービスを合計し、Edge-EMS Builder 全体として扱います。

サービス 役割
cb_core データ収集と中核通信
cb_nginx CommBridge Web／リバースプロキシ
cb_backend CommBridge バックエンド
ems_backend EMS Builder の計算、制御、業務ロジック
ems_postgresql EMS Builder データ保存

各 sample_no で 5 サービスを合計し、2,000 個の合計値から平均、P95、P99、ピークを計算します。異なる時刻の各サービスの独立ピークを直接合計しません。

3.3 CPU、メモリー、タスク遅延

Section titled “3.3 CPU、メモリー、タスク遅延”
  • 5 サービスの元 CPU 値は 1 コア相当の百分率です。AFE-E620 は 4 コアのため、「Edge-EMS Builder 4 コア相当 CPU」は 5 サービス合計 ÷ 4 です。
  • 「装置全体 CPU」はワークブックの _system_total を使用し、全 CPU 容量で正規化した 0～100% の使用率です。装置容量を判断する主な指標です。
  • 「Edge-EMS Builder 帰属メモリー」は、5 サービスの cgroup に帰属するメモリーの合計です。共有ページやキャッシュが重複帰属する場合があり、装置全体の実使用量を上回ることがあります。物理メモリーで直接割って容量使用率にしてはいけません。
  • 「装置全体の実メモリー」は MemTotal - MemAvailable で計算し、物理メモリー余裕の主な判断指標とします。この報告の百分率は MemTotal = 982 MB で計算しています。
  • Trigger / MQTT の平均、P50、P95、P99 は、有効区間の全タスク記録から計算したもので、毎秒平均の分位数ではありません。
  • 全ワークブックで「集計前に試験負荷を停止済み」の確認に合格しました。Trigger、MQTT、CommBridge を集計前に停止し、30 秒待機しています。

4. 試験対象と環境

Section titled “4. 試験対象と環境”
項目 設定
デバイスモデル AFE-E620
CPU Arm Cortex-A55、4 コア
メモリー 982 MB DDR3
OS JelinaOS、Ubuntu 20.04 ベース
ストレージ eMMC
ソフトウェアバージョン 追記予定（今回のワークブックには未記録。保管前に CommBridge / EMS Builder / PostgreSQL のバージョンを追記する必要あり）
ネットワーク LAN；MQTT / TCP
監視サンプリング 毎秒 1 回。各シナリオ 2,002 回、中間の 2,000 回を集計
試験データソース perf_S1_20260730_101351.xlsx、perf_S2_20260730_105126.xlsx、perf_S2.5_20260730_113029.xlsx、perf_S3_20260730_152548.xlsx、perf_S3.5_20260731_122356.xlsx、perf_S6_20260731_173626.xlsx

5. シナリオと負荷

Section titled “5. シナリオと負荷”
シナリオ データ収集 集約演算 通常 Trigger 100 ms Trigger Trigger 目標 MQTT 目標 協調タスク 保存方式
S1 500 ポイント/秒 10 10 回/秒 0 10 回/秒 5 回/秒 0 回/秒 リアルタイム
S2 2,000 ポイント/秒 20 20 回/秒 2 40 回/秒 10 回/秒 2 回/秒 リアルタイム
S2.5 2,000 ポイント/秒 20 20 回/秒 2 40 回/秒 10 回/秒 2 回/秒 変化時保存（10 秒）
S3 5,000 ポイント/秒 30 50 回/秒 4 90 回/秒 20 回/秒 10 回/秒 リアルタイム
S3.5 5,000 ポイント/秒 30 50 回/秒 4 90 回/秒 20 回/秒 10 回/秒 変化時保存（10 秒）
S6 5,000 ポイント/秒 20 50 回/秒 10 150 回/秒 30 回/秒 15 回/秒 リアルタイム

「データ収集」はマニュアルのシナリオ定義に従う設定負荷です。ワークブックにはポイント別の収集成功数も、シナリオ別の設定明細もないため、独立検証済みの保存成功スループットとは表現できません。各シナリオの Trigger / MQTT 目標は、ワークブックの達成率検証目標と一致します。

6. 試験時間

Section titled “6. 試験時間”
シナリオ 有効集計区間 有効時間
S1 2026-07-30 10:13:55 ～ 10:47:13 2,000 秒
S2 2026-07-30 10:51:30 ～ 11:24:48 2,000 秒
S2.5 2026-07-30 11:30:33 ～ 12:03:51 2,000 秒
S3 2026-07-30 15:25:51 ～ 15:59:09 2,000 秒
S3.5 2026-07-31 12:23:59 ～ 12:57:17 2,000 秒
S6 2026-07-31 17:36:29 ～ 18:09:47 2,000 秒

時刻はすべて UTC+8 です。

7. CPU の結果

Section titled “7. CPU の結果”

7.1 EMS Builder 5 サービス合計（4 コア相当）

Section titled “7.1 EMS Builder 5 サービス合計（4 コア相当）”
状態 シナリオ 平均 P95 P99 ピーク
🟢 S1 9.87% 19.19% 27.73% 32.42%
🟡 S2 22.39% 41.93% 51.69% 110.22%
🟢 S2.5 19.86% 36.67% 47.88% 75.63%
🔴 S3 32.80% 57.33% 71.41% 115.84%
🔴 S3.5 32.25% 52.81% 64.87% 130.65%
🔴 S6 30.90% 63.74% 77.34% 99.06%

S2、S3、S3.5 の Edge-EMS Builder ピーク 110.22%、115.84%、130.65% は、単一サンプリング区間の瞬時値です。5 サービス合計 CPU 時間が通常の 4 コア容量を超えています（例えば S2 の ems_backend 単一サービス・単一サンプルのピークは 402%）。サンプリングタイムアウトと合わせると、測定区間のずれや突発的なスケジューリングが考えられ、持続可能な使用量とは見なしません。

7.2 装置全体 CPU（全 CPU 容量で正規化）

Section titled “7.2 装置全体 CPU（全 CPU 容量で正規化）”
状態 シナリオ 平均 P95 P99 ピーク
🟢 S1 15.27% 26.83% 34.00% 50.88%
🟡 S2 29.41% 52.01% 70.29% 100.00%
🟢 S2.5 26.24% 45.54% 58.41% 97.05%
🔴 S3 48.29% 82.71% 97.18% 100.00%
🔴 S3.5 41.32% 66.05% 90.63% 100.00%
🔴 S6 49.35% 88.33% 98.30% 100.00%

装置全体 CPU を容量判断の主な根拠とします。S2.5 の P95 は S2 より 6.47 ポイント低く、S3 以降の P95 はすべて 66% を超え、ピークは 100% で、CPU は飽和領域に入っています。

8. メモリーの結果

Section titled “8. メモリーの結果”
状態 シナリオ EMS Builder 帰属メモリー平均 EMS Builder 帰属メモリー P95 装置全体の実メモリー平均 装置全体の実メモリー P95 装置全体の実メモリーピーク
🟢 S1 484.14 MB 529.22 MB 726.92 MB（74.02%） 810.83 MB（82.57%） 825.71 MB（84.08%）
🟡 S2 567.86 MB 589.11 MB 788.52 MB（80.30%） 878.61 MB（89.47%） 900.03 MB（91.65%）
🟢 S2.5 562.11 MB 580.93 MB 785.65 MB（80.01%） 845.52 MB（86.10%） 918.53 MB（93.54%）
🔴 S3 573.27 MB 603.92 MB 843.22 MB（85.87%） 930.97 MB（94.80%） 938.00 MB（95.52%）
🔴 S3.5 560.39 MB 590.84 MB 838.25 MB（85.36%） 902.91 MB（91.95%） 937.29 MB（95.45%）
🔴 S6 549.24 MB 608.00 MB 827.91 MB（84.31%） 932.14 MB（94.92%） 939.57 MB（95.68%）

5 サービスの帰属メモリーは共有ページとキャッシュを含み、物理メモリーの正味使用量ではありません。残容量をより適切に示す装置全体の実メモリーで判定します。AFE-E620 の物理メモリーは 982 MB のみです。基準 S1 の平均使用率が 74.02% で、OS と Edge-EMS Builder の常駐使用量は容量の約 4 分の 3 に達しています。S3 以降の P95 は 91% 超、利用可能メモリーは 90 MB 未満で、メモリー負荷が高い状態です。データベースの初期状態やキャッシュ状態も影響するため、ポイント数だけで使用量を推測しないでください。

9. 処理量の結果

Section titled “9. 処理量の結果”

平均処理量は 2,000 秒の有効区間全体を分母とし、達成率は総タスク数を総目標数で割って計算します。ワークブック表示値の丸めによる誤差を避けます。

状態 シナリオ Trigger 総数 Trigger 平均／目標 Trigger 達成率 MQTT 総数 MQTT 平均／目標 MQTT 達成率
🟢 S1 20,000 10.00 / 10 100.00% 10,000 5.00 / 5 100.00%
🟡 S2 78,917 39.46 / 40 98.65% 19,752 9.88 / 10 98.76%
🟢 S2.5 79,924 39.96 / 40 99.91% 19,964 9.98 / 10 99.82%
🔴 S3 77,536 38.77 / 90 43.08% 17,860 8.93 / 20 44.65%
🔴 S3.5 157,134 78.57 / 90 87.30% 34,676 17.34 / 20 86.69%
🔴 S6 57,442 28.72 / 150 19.15% 11,508 5.75 / 30 19.18%

推奨稼働シナリオの処理量の参考基準は 99% です。S2 はわずかに下回り、S3、S3.5、S6 は処理能力が明らかに不足しています。過負荷領域ではタスクキューが継続して滞留し、実際の完了数は目標を大きく下回ります。

10. Trigger の遅延

Section titled “10. Trigger の遅延”

以下の分位数は、有効区間の全 Trigger タスク記録に基づきます。単位はミリ秒です。

状態 シナリオ 平均 P50 P95 P99 単一実行の最大値
🟢 S1 15.57 12 18 30 10,237
🟡 S2 22.98 9 28 61 11,012
🟢 S2.5 17.28 9 25 40 10,999
🔴 S3 70.61 17 120 713.65 27,281
🔴 S3.5 76.65 13 58 170 53,472
🔴 S6 71.90 17 127 610.59 24,421

S2.5 以下の通常の分位数は低いものの、全シナリオで約 10～11 秒の極端な単一実行ロングテールがあります。過負荷では平均が大きく押し上げられます（S3.5 は平均 76.65 ms に対し P95 は 58 ms、P50 は 13 ms）。通常の応答性は P50 / P95 を優先して判断してください。ロングテールは P99 に大きく影響しなくても、個々の制御やアラームに影響し得るため、個別調査が必要です。

11. MQTT の遅延

Section titled “11. MQTT の遅延”

以下の分位数は、有効区間の全 MQTT タスク記録に基づきます。単位はミリ秒です。

状態 シナリオ 平均 P50 P95 P99 単一実行の最大値
🟢 S1 49.65 49 52 56 440
🟡 S2 54.77 51 64 90 1,182
🟢 S2.5 51.80 52 56 64 402
🔴 S3 93.56 56 249.05 944.41 2,471
🔴 S3.5 109.53 55 95 242 53,373
🔴 S6 95.33 59 201 782 19,969

12. シナリオ判定

Section titled “12. シナリオ判定”
シナリオ 判定 主な根拠
S1 合格 Trigger / MQTT 達成率はともに 100%、CPU 使用率 P95 は 26.83%。ただし平均メモリー使用率は 74.02% に達している点に注意。
S2 条件付き合格 CPU 使用率 P95 52.01% で一定の余裕はあるが、達成率 98.65% / 98.76% は 99% 基準をわずかに下回り、サンプリングタイムアウト 34 回。
S2.5 推奨 2,000 ポイント/秒で達成率 99.91% / 99.82%、P95 25 ms / 56 ms、CPU 使用率 P95 45.54%。基準を満たした最大負荷。
S3 不合格 達成率 43.08% / 44.65%、MQTT P99 944.41 ms、CPU 使用率 P95 82.71%、メモリー P95 94.80%、サンプリングタイムアウト 617 回。
S3.5 不合格 変化時保存で S3 より改善（CPU P95 66.05%、Trigger P95 58 ms）したが、達成率 87.30% / 86.69% は基準未満。サンプリングタイムアウト 96 回。
S6 すべての本番用途で非推奨 達成率 19.15% / 19.18%、CPU 使用率 P95 88.33%、メモリー P95 94.92%、サンプリングタイムアウト 886 回。深刻な過負荷。

13. 容量と配置の推奨事項

Section titled “13. 容量と配置の推奨事項”

13.1 検証済みの推奨設定

Section titled “13.1 検証済みの推奨設定”
  • データ収集設定量：2,000 ポイント/秒。
  • 集約演算：20 個。
  • 通常 Trigger：20 回/秒。
  • 100 ms Trigger：2 個、すなわち 20 回/秒。
  • Trigger 合計：40 回/秒。
  • MQTT：10 回/秒。
  • 協調タスク：2 回/秒。
  • Trigger タスク記録：保存。
  • データ保存：変化時保存。値が変化しなくても遅くとも 10 秒ごとに保存。

13.2 本番配置の推奨事項

Section titled “13.2 本番配置の推奨事項”
  • 長期稼働では検証済み設定に約 20% の設計余裕を確保し、実際の Lua スクリプト、メッセージ本文サイズ、履歴データ量で事前再試験してください。
  • AFE-E620 は基準のメモリー使用量が高く（基準シナリオ S1 でも装置全体平均は 74% 超）、CPU に 80% の警告、メモリーに 85% の警告と 90% の重大アラームを設定し、PostgreSQL キャッシュとデータベース増加を継続監視することを推奨します。必要に応じて PostgreSQL のメモリー割当て削減や上位モデルを検討してください。
  • リアルタイム保存が必要なら S2 を参考にできますが、達成率は 99% 基準をわずかに下回ります。業務上必須でなければ S2.5 の変化時保存を優先してください。
  • S3（5,000 ポイント/秒）以上は AFE-E620 の持続的な処理能力を超え、変化時保存（S3.5）でも不合格でした。この容量が必要なら AFE-E630 を選択してください。
  • E620 の S6 は深刻な過負荷で、負荷事前確認の参考にはなりません。過負荷保護の検証には、S3 相当の負荷を短時間実行することを推奨します。

14. 品質上の注意と追加試験

Section titled “14. 品質上の注意と追加試験”
  1. サンプリングタイムアウトは S1：3 回、S2：34 回、S2.5：8 回、S3：617 回、S3.5：96 回、S6：886 回でした。過負荷では監視処理自体が予定どおり完了できず、リソースデータの信頼性が下がるため、処理量と遅延を主に判定します。
  2. 今回の CommBridge / Edge-EMS Builder / PostgreSQL のバージョンを追記し、環境情報を補完します。
  3. 72 時間安定性試験を完遂し、プロセス再起動、OOM、エラーログ、メモリー増加傾向、データベース増加を記録します。E620 は基準メモリー使用量が高いため、緩やかな増加にも特に注意します。
  4. 収集ポイント、Trigger、MQTT、協調タスクごとに、成功・失敗・タイムアウト・破棄のカウンターを追加します。
  5. ディスクスループット、I/O wait、PostgreSQL WAL / checkpoint、接続プール、キュー深度を追加測定します。
  6. Trigger の 10～11 秒のロングテールと、S3.5 で Trigger・MQTT に同時発生した約 53 秒の極端値を、タスク ID、Lua、SQL、GC、I/O、システムログと関連付けて調査します。
  7. 各シナリオ開始前のデータベースサイズ、PostgreSQL 設定、キャッシュ状態を記録し、メモリー比較の精度を高めます。

15. データ上の制約

Section titled “15. データ上の制約”
  • ポイント数は試験設定量であり、ポイント別成功数ではありません。現データだけでは全収集ポイントの保存成功を独立して証明できません。
  • 業務設定（集約数、Trigger 構成、協調タスク数）はマニュアルの定義に従い、ワークブックにシナリオ別の設定明細はありません。
  • ワークブックには業務エラー率、タスク結果状態、正確率のフィールドがありません。処理量達成は業務正確率 100% を意味しません。
  • 今回は各シナリオ約 33 分 20 秒の短時間試験で、性能比較向けです。長期安定性試験の代わりにはなりません。
  • ソフトウェアバージョンはワークブックに未記録のため、追記後に結果との対応を確認する必要があります。
  • S2.5 は今回、99% 処理量基準を達成した最大負荷の実測設定です。20% の設計余裕は容量計画の提案で、独立した実測結果ではありません。

その他のモデル：AFE-E630 試験報告。