[アップデート] Mountpoint for Amazon S3 v1.24.0 でメモリ使用量を制御できるようになったので確認してみた

いわさです。

Mountpoint for Amazon S3 は S3 バケットを Linux のファイルシステムとしてマウントできる AWS 製のファイルクライアントです。

https://dev.classmethod.jp/articles/mountpoint-for-amazon-s3/

S3 との読み書きを速くするため、読み込んだデータや書き込み待ちのデータを一時的にメモリに溜めながら動きます。
このメモリ使用量はこれまで上限を指定できず、アクセスパターンに応じて増えていく一方でした。
機械学習や分析処理のように他のアプリケーションとメモリを取り合う環境では、Mountpoint が使いすぎて性能や安定性の問題になることがあったそうです。

先日のアップデートで --memory-target が追加され、メモリ使用量のターゲットを指定できるようになりました。
指定しない場合も、環境のメモリ量からデフォルトのターゲットが決まります。

https://aws.amazon.com/about-aws/whats-new/2026/08/mountpoint-for-S3-adds-memory-usage-controls/

mountpoint-s3 v1.24.0 からの機能です。
同じバージョンで書き込みファイルの同時オープン数にも上限が入ったので、あわせて見てみます。

実際に確認してみる

検証は東京リージョンの EC2 インスタンスで行いました。
t4g.small（arm64）の Amazon Linux 2023（2023.12.20260817）で、MemTotal は 1885252 kB なので 1841.1 MiB です。
mount-s3 は 1.24.0 を使い、比較用に 1.23.0 も入れています。操作は SSM 経由の root 実行なので、ログの出力先などが /root 配下になっています。

マウントして上限値を確認する

まず旧バージョンとのオプション差分を押さえておきます。
1.23.0 の --help には part size 系のオプションだけがあり、メモリという単語自体が出てきません。

$ grep -n -i -E 'memory|part-size' help-1.23.0.txt
126:      --part-size <SIZE>
131:      --read-part-size <SIZE>
134:      --write-part-size <SIZE>

1.24.0 で --memory-target が現れます。ドキュメントへの参照行の移動など他の差分もあったので、該当部分だけ抜粋します。

$ diff help-1.23.0.txt help-1.24.0.txt
（抜粋）
>       --memory-target <MiB>
>           Target for Mountpoint's total memory usage, in MiB.
>
>           Mountpoint manages the memory used to buffer reads and writes to stay within this target but it is
>           not a guaranteed limit. Lowering it may reduce throughput and increase latency. The target caps how
>           many files can be open for writing at the same time. Once that cap is reached, opening a file for
>           writing fails with ENOMEM.
>
>           Defaults to 95% of total (or cgroup-limited) memory.

では実際にマウントしてみます。まずはオプションを何も付けない場合です。

$ mount-s3 $BUCKET /mnt/s3 --log-directory /root/logs-default
bucket mp-memtarget-blog-123456789012 is mounted at /mnt/s3

起動ログに write_handle_limiter の行が増えています。

2026-08-27T22:57:46.089298Z  INFO ThreadId(01) mountpoint_s3::run: mount-s3 1.24.0
2026-08-27T22:57:46.155377Z  INFO ThreadId(01) mountpoint_s3::cli: target network throughput 5 Gbps
2026-08-27T22:57:46.226328Z  INFO ThreadId(01) mountpoint_s3_fs::memory::write_handle_limiter: max files concurrently open for write: 190 (memory target 1749 MiB, write part size 8 MiB)
2026-08-27T22:57:46.226868Z  INFO ThreadId(01) mountpoint_s3::run: successfully mounted bucket mp-memtarget-blog-123456789012 at /mnt/s3

MemTotal 1841.1 MiB の 95% は 1749.0 MiB なので、ログの memory target 1749 MiB と一致します。
指定しなければこの 95% がターゲットになり、--memory-target を付けるとその値になります。

もう一つの max files concurrently open for write: 190 が、今回のバージョンで入った書き込みオープン数の上限です。
ドキュメントに計算式が載っています。

cap = (memory_target − overhead − read_part_size) / write_part_size

https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#maximum-number-of-files-open-for-writing

overhead は Mountpoint 自身のメタデータなどに使う分で max(128 MiB, memory_target / 8)、part size は読み書きを分割する単位でデフォルト 8 MiB です。
今回のターゲット 1749 MiB なら (1749 − 218.6 − 8) / 8 の切り捨てで 190 になり、ログと一致しました。
この行は指定の有無に関係なく出るので、アップグレード後は自分の環境の上限を起動ログで確認できます。

次に --memory-target を明示指定して、上限がどう変わるか試します。

4096 の計算式だけ引く値が 512 MiB になっているのは、max(128 MiB, memory_target / 8) の後者が大きくなるためです。

512 MiB を指定したときのログです。

2026-08-27T22:58:14.425021Z  INFO ThreadId(01) mountpoint_s3_fs::memory::write_handle_limiter: max files concurrently open for write: 47 (memory target 512 MiB, write part size 8 MiB)

最小値未満はバリデーションで弾かれます。

$ mount-s3 $BUCKET /mnt/s3 --memory-target 256
error: invalid value '256' for '--memory-target <MiB>': 256 is not in 512..18446744073709551615
For more information, try '--help'.
（exit code: 2）

一方で、物理メモリ 1841 MiB のインスタンスに 4096 MiB を指定してもエラーにも警告にもならず、そのまま採用されました。
明示指定した値については物理メモリとの突き合わせが働かないようなので、指定値が実メモリに収まっているかは自分で確認しておく前提になります。

上限に達すると open() が ENOMEM で失敗する

上限の実体はメモリ（データバッファ）ですが、その結果として書き込みで同時に開けるファイル数に上限がかかります。
書き込み中のファイルは 1 つにつき 1 パート分のバッファを押さえ続けるため、さきほどの cap 式のとおり「予算 ÷ パートサイズ」が同時に開ける数の上限になります。
上限に達すると、次の open() はバッファを確保できず ENOMEM（メモリを確保できないことを表す errno 12）で失敗します。

これはリリースノートでも破壊的変更として挙げられています。
--memory-target を指定しなくても上限は設定されるので、アップグレードするだけで挙動が変わります。
通常のホストでは上限も大きめになります。この検証環境でも 190 でした。
ただ、多数のファイルを同時に書き込むワークロードやメモリを絞ったコンテナでは、書き込みが ENOMEM で弾かれることがあります。
実際に --memory-target 512（上限 47）で 48 個目のファイルを開こうとしたところ ENOMEM になりました。
開いているハンドルを閉じれば枠は空くので、詰まる場合はアプリ側で同時オープン数を絞るか、--memory-target を上げる調整になります。

さいごに

本日は Mountpoint for Amazon S3 にメモリ使用量のターゲットを指定する --memory-target が追加されたので確認してみました。
指定した値は起動ログにそのまま出て、書き込みオープン数の上限も一緒に確認できました。
メモリを大量に使うアプリケーションと同居させる場面で、Mountpoint 側の使用量を抑えられるのは扱いやすそうです。

あわせて気にしておきたいのが、同じバージョンで入った書き込みオープン数の上限です。
デフォルトで有効なので、多数のファイルを同時に書き込むワークロードでは ENOMEM に遭遇する可能性があります。
アップグレードの前後で、起動ログの max files concurrently open for write を一度見ておきましょう。