はじめに

Oracle CloudのARM インスタンス（Ampere A1）でSymbolノードをセットアップしたところ、300万ブロックを超えたあたりでノードがダウンし、同期が進まなくなる問題に遭遇しました。

本記事では、この問題の調査過程と暫定的な対処法を共有します。なお、根本的な解決には至っておらず、現時点では未解決の問題として記録しています。

結論: エラー原因については未解決。でもfast-syncしたらOK

先に結論をお伝えすると、エラーの解決方法はまだわかってないです。
しかし、他の同期済みのノードから以下の2つのディレクトリを持ってくることである程度同期を済ませておくと問題なく動作します。
半年ぐらい回してみましたが、特にx86_64版のサーバーで動かす場合と差異はなく動いています。

回避策: 持ってくるディレクトリ

data/ - ブロックデータや状態情報
databases/ - MongoDBのデータ

結論はここまでで、以下は調査・試した内容のまとめです。

発生した事象

環境

項目	詳細
サーバー	Oracle Ampere A1 Compute（ARM64）
OS	Ubuntu Server 24.04
CPU	4 OCPU
RAM	24GB
Storage	250GB Block Storage
Node.js	v24.11.1
symbol-bootstrap	v1.1.12 linux-arm64
Docker	v29.0.1
Docker Compose	v2.40.3

エラーログ

同期処理中、320万ブロックあたりまで同期したタイミングで以下のエラーが発生しました:

$ docker compose logs -f node

node  | 2025-11-24 08:38:10.671622 <error> failed when connecting to 'node.example.com': Too many open files (cancelled? false)
node  | 2025-11-24 08:38:10.671671 <warning> unable to resolve and connect to static node node.example.com @ node.example.com:7900
node  | 2025-11-24 08:38:10.672102 <fatal> 
node  | thread: server catapult
node  | unhandled exception while running local node!
node  | Dynamic exception type: boost::wrapexcept<boost::filesystem::filesystem_error>
node  | std::exception::what: Failed to open file for writing: Input/output error [generic:5]: "/symbol-workdir/logs/catapult_server0000.log"
node  |
node  | Shutting down server

重要なのは1行目のここ: Too many open files

ログから読み取れる流れは以下の通りです:

同期処理中にpeerへの接続が増加
ファイルディスクリプタ（FD）が枯渇
ログファイルへの書き込みすら失敗
ノードがクラッシュ

調査内容

試したこと1: コンテナ内プロセスのFD数を確認

まず、コンテナ内でどれだけのFDが使用されているかを確認しました。

PID=$(docker inspect -f '{{.State.Pid}}' node)

echo "FD Count:"; ls /proc/$PID/fd | wc -l
echo "FD Limit:"; grep FDSize /proc/$PID/status
echo "RSS:"; grep VmRSS /proc/$PID/status

結果:

FD Count: 4  
FDSize:   256  
VmRSS:    約3MB

FDの上限が256しかありません。これは流石に不足してるかも？

試したこと2: OS全体のFD上限を確認

次に、OS側の制限を確認しました。

$ cat /proc/sys/fs/file-max
9223372036854775807

64bit整数の最大値が設定されており、OS側の制限ではないことがわかりました。

試したこと3: docker-compose.ymlの修正

OS側は問題なかったため、Docker Compose側でFD上限を引き上げることにしました。

target/docker/docker-compose.ymlのrest-gateway外のサービスにulimitsを追加:

# 抜粋
services:
  db:
    ulimits: #追加
      nofile:
        soft: 8192
        hard: 16384
  node:
    ulimits: #追加
      nofile:
        soft: 8192
        hard: 16384
  broker:
    ulimits: #追加
      nofile:
        soft: 8192
        hard: 16384

設定が反映されたか確認:

# node起動後に以下のコマンドをdocker-compose.ymlと同じディレクトリで実行
$ docker exec -it node bash -c "ulimit -n"
8192 # OK

一見すると、8192に上がっており問題なさそうに見えます。

しかし、問題は解決しなかった

FD上限を引き上げたにもかかわらず、同期は依然として途中で停止してしまいました。

調査を進めると、以下の状況が判明しました:

ulimit -nでは8192と表示される
しかし同期途中(今回は60万block程度)でなぜかblockが0にしまって以後起動しなくなる

どうやら、docker-composeのulimits設定がコンテナ全体に一貫して適用されないという挙動があるようです。これはcgroup v2 + systemd + Dockerの組み合わせで発生する既知の問題のようです。(これはAIによる推測で未確認)

現時点でのまとめ

わかったこと

ARMサーバー自体のスペックは十分（4 OCPU、24GB RAM）
OSのfile-maxは正常に設定されている
問題はDocker側のFD管理にある
docker-composeのulimits指定がサービス単位で整合性が取れない
Symbolノードは複数プロセスが協調動作するため、この差異が致命的になる

未解決の課題

Docker daemonレベルでFDを強く制限している可能性
cgroup v2環境でのulimits設定の挙動
ARM + Docker + Symbolという組み合わせ特有の問題かどうか

根本的な解決には至っていませんが、原因の方向性は「DockerのFD管理まわり」が濃厚です。

アドベントカレンダーの日までに解決したら良かったのですが残念ながら間に合わなかったので今回はここまでです。