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

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

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

1. 性能結果の概要

Section titled “1. 性能結果の概要”
✅ AFE-E630 の推奨稼働シナリオ：S3.5
今回実測した 6 シナリオでは、S3.5 が処理負荷、タスク遅延、装置全体のリソース余裕のバランスに最も優れています。変化時保存（値が変化しない場合も遅くとも 10 秒ごとに保存）を使用し、次の負荷を現在検証済みの推奨設定とします。
📡
5,000 ポイント/秒
データ収集設定量
🧮
30 個
集約演算
⚡
90 回/秒
Trigger 目標
☁️
20 回/秒
MQTT タスク目標
🤝
10 回/秒
協調タスク
💾
変化時保存
遅くとも 10 秒ごとに保存
🧠
50.16% / 71.09%
装置全体 CPU 平均 / P95
🗄️
40.49% / 41.41%
装置全体メモリー 平均 / P95
⏱️
56 ms
Trigger P95
📨
77 ms
MQTT P95

Trigger の 1 回の実行は、デバイス制御 1 回、ローカルアラームと MQTT アラーム、集約データ書き込み 1 回を表します。Edge-EMS Builder はデバイスのメモリーに応じて PostgreSQL へリソースを割り当てるため、デバイス、データベース規模、キャッシュ状態によりメモリー使用量が大きく異なる場合があります。

1.1 主な結論

Section titled “1.1 主な結論”

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

S3.5 の実測は Trigger 89.97 回/秒、MQTT 19.98 回/秒、Trigger / MQTT の P95 は 56 ms / 77 ms です。装置全体の CPU 使用率 P95 は 71.09%、実メモリー使用率 P95 は 41.41% で、サンプリングのタイムアウトはありませんでした。

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

1.2 シナリオ別状態

Section titled “1.2 シナリオ別状態”
アイコン シナリオ 結論
🟢 S1 基準シナリオに合格。リソースとタスク遅延に十分な余裕あり。
🟢 S2 合格。リアルタイム保存で 2,000 ポイント/秒を安定処理。サンプリングタイムアウトが 1 回発生。
🟢 S2.5 合格。変化時保存により S2 より CPU 負荷が大幅に低下し、サンプリングタイムアウトなし。
🟡 S3 タスク指標は合格。ただし CPU 使用率 P95 が 81.06% で継続稼働の限界に近く、サンプリングタイムアウトが 2 回発生。
🟢 S3.5 総合的に最良で、AFE-E630 の現在の推奨シナリオ。
🔴 S6 短時間負荷の事前確認にのみ適する。CPU 使用率 P95 は 94.02%、MQTT 処理量は推奨基準 99% 未満、サンプリングタイムアウトは 11 回。

2. 結論の要約

Section titled “2. 結論の要約”
  • 今回は S1、S2、S2.5、S3、S3.5、S6 の 6 シナリオを試験しました。その他のシナリオは表、比較、結論に含めません。
  • S3.5 は設定負荷 5,000 ポイント/秒で、Trigger 達成率 99.97%、MQTT 達成率 99.90%、Trigger / MQTT の P95 は 56 ms / 77 ms でした。
  • S3 と S3.5 の業務負荷は同じです。変化時保存により CPU 使用率平均が 57.95% から 50.16%、P95 が 81.06% から 71.09% へ下がり、継続稼働に適した結果となりました。
  • S6 の Trigger 達成率は 99.49% でしたが、MQTT は 98.73%、CPU 使用率 P95 は 94.02%、ピークは 100% で、継続的な本番設定には推奨しません。
  • 全シナリオで Trigger 全体の P99 は 200 ms 未満でしたが、約 10～12 秒の単一実行のロングテールがありました。S6 の MQTT P99 は 236.62 ms で、200 ms を超えています。
  • 各シナリオの有効サンプルは 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-E630 は 4 コアのため、「Edge-EMS Builder 4 コア相当 CPU」は 5 サービス合計 ÷ 4 です。
  • 「装置全体 CPU」はワークブックの _system_total を使用し、全 CPU 容量で正規化した 0～100% の使用率です。装置容量を判断する主な指標です。
  • 「Edge-EMS Builder 帰属メモリー」は、5 サービスの cgroup に帰属するメモリーの合計です。共有ページやキャッシュが重複帰属する場合があり、装置全体の実使用量を上回ることがあります。物理メモリーで直接割って容量使用率にしてはいけません。
  • 「装置全体の実メモリー」は MemTotal - MemAvailable で計算し、物理メモリーの余裕を判断する主な指標とします。
  • Trigger / MQTT の平均、P50、P95、P99 は、有効区間の全タスク記録から計算したもので、毎秒平均の分位数ではありません。
  • 全ワークブックで「集計前に試験負荷を停止済み」の確認に合格しました。Trigger、MQTT、CommBridge を集計前に停止し、30 秒待機しています。

4. 試験対象と環境

Section titled “4. 試験対象と環境”
項目 設定
デバイスモデル AFE-E630
CPU Arm Cortex-A55、4 コア
メモリー 3.81 GB DDR4
OS JelinaOS、Debian 11 ベース
ストレージ eMMC
ソフトウェアバージョン CommBridge-rc-2026-07-08T17-52-07；EMS Builder v1.2；PostgreSQL v18.3
ネットワーク LAN；MQTT / TCP
監視サンプリング 毎秒 1 回。各シナリオ 2,002 回、中間の 2,000 回を集計
試験データソース perf_S1_20260729_171807.xlsx、perf_S2_20260729_175426.xlsx、perf_S2.5_20260729_183152.xlsx、perf_S3_20260729_190918.xlsx、perf_S3.5_20260729_194703.xlsx、perf_S6_20260729_202445.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 回/秒 リアルタイム

「データ収集」はシナリオの設定負荷です。現在のワークブックにはポイント別の収集成功数がなく、設定値を独立検証済みの保存成功スループットとして表現することはできません。

6. 試験時間

Section titled “6. 試験時間”
シナリオ 有効集計区間 有効時間
S1 2026-07-29 17:18:09 ～ 17:51:29 2,000 秒
S2 2026-07-29 17:54:29 ～ 18:27:49 2,000 秒
S2.5 2026-07-29 18:31:54 ～ 19:05:14 2,000 秒
S3 2026-07-29 19:09:20 ～ 19:42:40 2,000 秒
S3.5 2026-07-29 19:47:06 ～ 20:20:26 2,000 秒
S6 2026-07-29 20:24:47 ～ 20:58:07 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 13.48% 23.97% 41.50% 62.53%
🟢 S2 28.47% 48.33% 56.36% 67.17%
🟢 S2.5 26.11% 38.36% 49.96% 65.76%
🟡 S3 50.58% 72.31% 78.55% 95.43%
🟢 S3.5 43.50% 61.27% 70.93% 86.75%
🔴 S6 65.95% 85.87% 91.61% 208.59%

S6 の Edge-EMS Builder ピーク 208.59% は、単一サンプリング区間の異常値で、5 サービス合計 CPU 時間が通常の 4 コア容量を超えています。このシナリオの 11 回のサンプリングタイムアウトと合わせると、測定区間のずれや突発的なスケジューリングが考えられます。持続可能なリソース使用量とは見なしません。

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

Section titled “7.2 装置全体 CPU（全 CPU 容量で正規化）”
状態 シナリオ 平均 P95 P99 ピーク
🟢 S1 20.22% 38.67% 48.57% 67.70%
🟢 S2 35.88% 57.58% 66.41% 82.42%
🟢 S2.5 32.72% 45.28% 57.03% 75.06%
🟡 S3 57.95% 81.06% 89.16% 98.64%
🟢 S3.5 50.16% 71.09% 79.84% 96.98%
🔴 S6 73.86% 94.02% 97.95% 100.00%

この報告では、装置全体 CPU を CPU 容量判断の主な根拠とします。S3.5 の P95 は S3 より 9.97 ポイント低く、S6 の P95 は 90% を超えており、継続稼働の余裕が不足しています。

8. メモリーの結果

Section titled “8. メモリーの結果”
状態 シナリオ EMS Builder 帰属メモリー平均 EMS Builder 帰属メモリー P95 装置全体の実メモリー平均 装置全体の実メモリー P95 装置全体の実メモリーピーク
🟢 S1 2,666.77 MB 2,704.44 MB 1,550.46 MB（39.74%） 1,637.29 MB（41.97%） 1,694.09 MB（43.42%）
🟢 S2 2,805.86 MB 2,895.39 MB 1,579.23 MB（40.48%） 1,675.40 MB（42.94%） 1,736.57 MB（44.51%）
🟢 S2.5 2,881.41 MB 2,933.45 MB 1,507.67 MB（38.64%） 1,596.94 MB（40.93%） 1,667.61 MB（42.74%）
🟡 S3 3,067.36 MB 3,119.55 MB 1,591.41 MB（40.79%） 1,684.10 MB（43.17%） 1,759.92 MB（45.11%）
🟢 S3.5 3,059.29 MB 3,106.37 MB 1,579.83 MB（40.49%） 1,615.76 MB（41.41%） 1,702.34 MB（43.63%）
🔴 S6 3,071.13 MB 3,123.09 MB 1,636.22 MB（41.94%） 1,721.25 MB（44.12%） 1,791.94 MB（45.93%）

5 サービスの帰属メモリーは cgroup に帰属する共有ページとキャッシュを含み、物理メモリーの正味使用量ではありません。装置全体の実メモリーが残容量をより適切に表すため、シナリオ判定にはこちらを使用します。データベースの初期状態やキャッシュのウォームアップ状態も影響するため、ポイント数だけでメモリー変化を推測しないでください。

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 79,990 40.00 / 40 99.99% 19,995 10.00 / 10 99.98%
🟢 S2.5 79,990 40.00 / 40 99.99% 20,000 10.00 / 10 100.00%
🟡 S3 179,788 89.89 / 90 99.88% 39,800 19.90 / 20 99.50%
🟢 S3.5 179,943 89.97 / 90 99.97% 39,960 19.98 / 20 99.90%
🔴 S6 298,469 149.23 / 150 99.49% 59,239 29.62 / 30 98.73%

推奨稼働シナリオの処理量の参考基準を 99% とします。S6 の MQTT はこの基準を下回り、高 CPU、遅延増大、サンプリングタイムアウトが同時に発生しているため、負荷の厳しい領域に入ったと判断します。

10. Trigger の遅延

Section titled “10. Trigger の遅延”

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

状態 シナリオ 平均 P50 P95 P99 単一実行の最大値
🟢 S1 47.86 19 32 47 10,160
🟢 S2 23.65 11 30 53 10,938
🟢 S2.5 26.06 17 46 69 10,938
🟡 S3 37.69 14 55 99 10,993
🟢 S3.5 29.88 15 56 88 10,994
🔴 S6 44.06 17 87 162 11,985

通常の分位数は低いものの、全シナリオで約 10～12 秒の極端な単一実行のロングテールがあります。P99 には大きく影響しなくても、個々の制御・アラームタスクへ影響する可能性があり、個別調査が必要です。

11. MQTT の遅延

Section titled “11. MQTT の遅延”

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

状態 シナリオ 平均 P50 P95 P99 単一実行の最大値
🟢 S1 57.90 57 65 73 122
🟢 S2 57.83 57 67 76 115
🟢 S2.5 57.13 56 65 74 330
🟡 S3 62.31 58 89 146 340
🟢 S3.5 58.60 57 77 98 220
🔴 S6 74.79 64 134 236.62 920

12. シナリオ判定

Section titled “12. シナリオ判定”
シナリオ 判定 主な根拠
S1 合格 基準負荷で CPU 使用率 P95 は 38.67%、メモリー P95 は 41.97%、タスク処理量は目標を達成。
S2 合格 Trigger と MQTT の達成率はほぼ 100% で、リソース余裕は十分。サンプリングタイムアウト 1 回に留意。
S2.5 合格 処理量は目標達成。変化時保存により CPU 使用率平均と P95 が S2 より大幅低下。
S3 条件付き合格 処理量とタスク遅延は基準達成。ただし CPU 使用率 P95 は 81.06%、サンプリングタイムアウト 2 回で、継続稼働の余裕は小さい。
S3.5 推奨 5,000 ポイント/秒で Trigger / MQTT P95 はともに 100 ms 未満。CPU 使用率 P95 は 71.09%、実メモリー P95 は 41.41%、サンプリングタイムアウトなし。
S6 継続稼働は非推奨 MQTT 達成率 98.73%、P99 236.62 ms、CPU 使用率 P95 94.02%、サンプリングタイムアウト 11 回。

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

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

13.1 検証済みの推奨設定

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

13.2 本番配置の推奨事項

Section titled “13.2 本番配置の推奨事項”
  • 長期稼働では検証済み設定に約 20% の設計余裕を確保し、実際の Lua スクリプト、メッセージ本文サイズ、履歴データ量で事前再試験してください。
  • CPU 使用率に 80% の警告、メモリー使用率に 70% の警告と 80% の重大アラームを設定し、PostgreSQL キャッシュとデータベースの増加を継続監視することを推奨します。
  • リアルタイム保存が必要なら S3 を参考にできますが、CPU 使用率 P95 はすでに 80% 超です。業務上必須でなければ、S3.5 の変化時保存を優先してください。
  • S6 は短時間負荷、流量制限、過負荷保護の検証にのみ使用し、E630 の継続的な本番負荷には推奨しません。

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

Section titled “14. 品質上の注意と追加試験”
  1. サンプリングタイムアウトは S2 で 1 回、S3 で 2 回、S6 で 11 回でした。S1、S2.5、S3.5 では確認されませんでした。
  2. 72 時間の安定性試験を完遂し、プロセス再起動、OOM、エラーログ、メモリー増加傾向、データベース増加量を記録します。
  3. 収集ポイント、Trigger、MQTT、協調タスクそれぞれに、成功・失敗・タイムアウト・破棄のカウンターを追加します。
  4. ディスクスループット、I/O wait、PostgreSQL WAL / checkpoint、接続プール、キュー深度を追加測定します。
  5. Trigger の 10～12 秒の単一実行ロングテールを、タスク ID、Lua、SQL、GC、I/O、システムログと関連付けて調査します。
  6. シナリオ開始前のデータベースサイズ、PostgreSQL 設定、キャッシュ状態を記録し、シナリオ間のメモリー比較の精度を高めます。

15. データ上の制約

Section titled “15. データ上の制約”
  • ポイント数は試験設定量であり、ポイント別成功数ではありません。現データだけでは全収集ポイントの保存成功を独立して証明できません。
  • ワークブックには業務エラー率、タスク結果状態、正確率のフィールドがありません。処理量達成は業務正確率 100% を意味しません。
  • 今回は各シナリオ約 33 分 20 秒の短時間試験で、性能比較向けです。長期安定性試験の代わりにはなりません。
  • S3.5 は今回の実測設定で総合指標が最良でした。20% の設計余裕は容量計画の提案であり、独立した実測結果ではありません。

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