====== opencage-b01 ======

  * [[https://guardians.qubic.org/nodes/RWTKUQNJYPODHCZAKVMOYCRYADOBJAFXNWCYUVJIAFVBAIWQYZXKBAGGZMKE/bob|Qubic Guardians opencage-b01]]
    * [[https://www.hetzner.com/cloud/|Flexible Cloud Hosting Services und VPS Server]] CPX42 $ 22.59 max / Month.
    * Prepare from [[tag/ep203]]

===== 📊 qubic-bob コンテナの負荷解析 =====

{{..:guardians:pasted:20260312-000145.png?800}}


<code>
CONTAINER ID   NAME             CPU %     MEM USAGE / LIMIT     MEM %     NET I/O             BLOCK I/O           PIDS
bff15d2f2e2b   qubic-bob        154.90%   8.408GiB / 15.24GiB   55.16%    24.3GB / 666MB      12.8GB / 191GB      81
254e46339bc5   watchtower-bob   0.00%     7.273MiB / 15.24GiB   0.05%     3.01MB / 1.02MB     0B / 0B             14
</code>

==== 1. CPU %：154.90%（余裕の巡航速度） ====

　Docker（Linux）の世界では100%＝1コアとして計算されます。現在約1.5コア分をフルに使ってゴリゴリ計算していますが、Hetzner CPX42プランは「8コア（800%）」あるため、サーバー全体から見れば**「まだまだ余裕しゃくしゃく」**の状態です。

==== 2. MEM USAGE / LIMIT：8.408GiB / 15.24GiB（大正解のサイジング） ====

　**ここが一番のハイライトです！**

　ノード本体とデータベースが実質「約8.4GB」のメモリをガッツリ占有しています。もしケチって一つ下のプラン（8GBメモリのCPX32）を選んでいたら、この時点でメモリの上限（LIMIT）に激突し、確実にクラッシュ（OOM Killer発動）していました。

　**16GBプランを選んだインフラ設計が、完璧に正しかったことの証明**です。残り約7GBの空き領域も、Linuxがディスクキャッシュとして賢く活用してくれます。

==== 3. NET I/O：24.3GB / 666MB（爆速ダウンロード中） ====

　ネットワークから過去のティックデータなどを「24.3GB」も受信（ダウンロード）しています。

　送信（666MB）に対して圧倒的に受信が多いのは、ネットワークの最新に追いつくため（Catch-up処理）に過去データを猛スピードで掻き集めている真っ最中だからです。

==== 4. BLOCK I/O：12.8GB / 191GB（NVMe SSDの真骨頂！） ====

　ディスクの読み書き量です。なんと**「191GB」ものデータをディスクに書き込んでいます！**

　同期処理中は猛烈な勢いでデータベースへの書き込みが発生しますが、この尋常ではない書き込み量をシステムをフリーズさせることなく涼しい顔で捌けているのは、**Hetznerの超高速なNVMe SSD**のおかげです。安価なHDDや低速SSDのVPSでは、ここがボトルネックとなり同期が一生終わりません。



==== 🛡️ watchtower-bob について ====

　下段で稼働している番犬コンテナ（Watchtower）は、CPU 0.00%、メモリわずか 7.2MB と、空気のような軽さで静かに待機しています。エポック更新時の自動アップデートなど、裏でインフラの安定稼働を支える重要な役割を担っています。

==== 🏆 結論：最高のモニタリング結果 ====

　インフラの限界を試すような激しい同期処理（Catch-up）の最中でも、CPU・メモリ・ディスク・ネットワークのすべてにおいて**「余裕を持った限界突破」**ができており、サーバーは全く悲鳴を上げていません。CPX42（8 vCPU / 16GB RAM / 240GB NVMe）が、Qubicノード運用における価格と性能の黄金比であることが実証されました。


===== 📊 OS全体のシステムリソース解析（free / df） =====

<code>
# free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       8.9Gi       1.2Gi       5.3Mi       5.5Gi       6.4Gi
Swap:             0B          0B          0B

# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       301G  125G  164G  44% /
</code>

==== 🧠 メモリ（free）の解析：完璧なリソース配分 ====

  * **Used（実使用量）: 8.9GiB**
    * 先のコンテナ単位の解析で [[tag/Bob]] 本体が約 8.4GB使っていた数字と合致する（残り0.5GBはUbuntu OSの稼働分）。

  * **buff/cache（キャッシュ）: 5.5GiB**
    * OS が空きメモリを「ディスク読み書きの高速化キャッシュ」としてフル活用している。
    * 猛烈なI/Oが発生するQubicにおいて、このキャッシュがパフォーマンス（同期速度）に強烈に貢献している。

  * **Available（実質的な空き）: 6.4GiB**
    * 一番重要な安全指標。即座に割り当て可能なメモリが 6.4GBも残っており、メモリ不足によるクラッシュ（OOM）の懸念は皆無である。

  * **Swap: 0B**
    * スワップ（仮想メモリ）への退避がゼロ。重いDB処理でスワップが発生するとディスクI/Oがボトルネックとなるため、物理メモリ（RAM）のみで完結できている現在の状態が理想的である。

==== 💾 ディスク（df）の解析：ノード要件の厳しさの証明 ====
  * **Used（使用量）: 125GB**
    * **最大の注目ポイント。** Qubicのノード（TickデータやKvrocksのDB）だけで、約125GBものディスク容量を消費している。
    * 安価なVPS（50GB〜100GBストレージ）を採用していた場合、同期途中でディスクフルに陥りシステムが停止していたことが証明された。

  * **Use%（使用率）: 44%**
    * 現在 44%の使用率。全容量が 300GB超あるため、エポック進行に伴うデータの蓄積と定期的なガベージコレクション（古いデータのパージ）の波を、十分な余裕を持って吸収できる。


==== 🏆 結論 ====

　このデータにより、Qubic [[tag/Bob]] ノードの安定稼働には**「RAM 16GB / ストレージ 150GB〜200GB以上」**が絶対的な足切りラインであることが実証された。

　現在のインフラ選定（Hetzner RAM16GB/NVMe300GB強）は、コストと性能のバランスにおいて完璧な最適解であると言える。



===== Related Articles =====

{{topic>opencage-b01 }}

{{tag>opencage-b01 guardians bob }}