クラウドサーバーのメモリ帯域幅検証：容量が達標なのになぜ速度が落ちるのか

容量が足りていても帯域幅が足りているとは限らない。三次元の証拠固めでしか見えてこない。

更新 2026-10-07 · CloudWorth

メモリ帯域幅STREAMNUMAオーバーセール検出FinOpsCloudWorthSteal TimeVPSオーバーセールVPS検証

容量達標は帯域幅達標ではない。STREAM に Steal Time と NUMA ピニングを組み合わせてクロスチェックし、さらに割増率と照合して増強か返金かを決める。

まず容量を測り、次に帯域を測る

クラウドサーバーを買うとき、ほぼ全員が最初に目を向けるのはメモリ容量だ：8GB、16GB、32GB。容量は注文ページに記載され、目に見えて、照合もできる。だからこそ「メモリは問題ない」とデフォルトでみなされる。しかし容量は倉庫の面積にすぎず、帯域こそがフォークリフトの速度だ——8GB のインスタンスであっても、容量がすべてグリーンでありながら、メモリのスループットが同世代の公称値の半分しかないということは十分にあり得る。

これが容量は基準を満たしているのに速度が落ちるという古典的なシナリオだ：AI 推論、ベクトル検索、Redis の大きな value、JVM のヒープ内コピーといった負荷は、GB に対する敏感さよりも GB/s に対する敏感さのほうがはるかに高く、容量が足りていても先に帯域の天井にぶつかる。

まず二つのステップを切り分ける：

1. 容量側：free -h で total/available を見て、注文スペックと照合し、隠れた balloon ドライバによる回収が起きていないか確認する。KVM なら dmesg | grep -i balloon で調べられる。
2. 帯域側：容量が一致していても帯域が一致しているとは限らない。専用のメモリスループットテストが必要で、それは次の節で扱う。

順序は必ず容量が先、帯域が後でなければならない。容量が基準に達していなければ、それは偽装表記であり、そのまま返金手続きに進む。容量が達していて帯域が落ちている場合こそ、より隠れたオーバーセール / 帯域制限の問題であり、以下の証拠収集チェーンが必要になる。

経験則としての判断基準：同じ容量なのに価格が明らかにワンランク安いインスタンスを買ったなら、まず帯域が疑わしい項目だとデフォルトで考え、安く買えたとデフォルトで考えるべきではない。こうした安さは往々にして CPU のオーバーコミット、NUMA のノードをまたぐ配置、メモリ周波数のダウングレードに由来し、最終的にはコストパフォーマンスの割高率という形で跳ね返ってくる——容量は買えたが、スループットは買えなかったのだ。

インスタンススペック、リージョン、イメージ、課金タイプ、注文時刻といった生データの記録を済ませてから、実測に入る。記録そのものが、その後のサポートチケットやダウングレード判断の証拠になる。チケットに「メモリがとても遅い」とだけ書いても、有効な対応はほぼ得られない。

STREAM と sysbench の実測

メモリ帯域幅の計測には相補的なツールが2つあります。STREAM が測るのは持続可能なベクトルスループット（Copy/Scale/Add/Triad）で、sysbench memory が測るのは「小さなブロックの読み書き」により近いシナリオです。sysbench vs STREAM memory bandwidth test for cloud servers の議論には意味がありません。両方とも実行すべきです。というのも、両者の歪みの方向が異なるからです。STREAM は小規模インスタンスの L3 キャッシュに過度に有利で、sysbench は命令オーバーヘッドに過度に敏感です。クロスして見なければ、単一の数値に騙されてしまいます。

STREAM の使い方（root なしでもホームディレクトリにコンパイル可能）：

sudo apt install -y gcc gfortran make
# 下载 stream.c 后：
gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE=200000000 stream.c -o stream
OMP_NUM_THREADS=$(nproc) ./stream

配列サイズはメモリの 1/4～1/2 に設定します。小さすぎるとすべてキャッシュに収まり、「見かけ上高い帯域幅」が出てしまいます。そうでなければ、測定しているのは DRAM ではなく L3 です。

sysbench 側：

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write run

判定の要点は3つです：

• シングルコア vs 全コア：それぞれ taskset -c 0 と全コアで実行し、GB/s を記録します。全コアにしてもほとんど伸びないなら、帯域幅がすでに制限されているということで、コア数が足りないわけではありません。
• 公称値との比較：DDR4 と DDR5 の世代差は約 1.5～2 倍のオーダーです。同じ世代・同じ周波数のクラウドインスタンス間で 2～3 倍の差が出るべきではありません。出た時点で異常です。
• vCPU あたりの帯域幅に換算：総帯域幅 / vCPU 数 はメモリ帯域幅のオーバーセールを判断する最も実用的な指標です。共有型インスタンスの vCPU あたり帯域幅は、専有型の半分しかないことがよくあります。これこそがクラウドサーバーの割増率の真の要因の一つです。

3 回実行して中央値を取り、毎正時の隣人ピークを避けます。この一連の数値を自動で vCPU あたり帯域幅と割増率に換算したい場合は、/app でテンプレートを作成し、STREAM、sysbench、インスタンス価格をまとめて入力して、比較可能なコストパフォーマンスのプロファイルを生成できます。次のセクションでは Steal Time と NUMA を使って「速度低下」を具体的な原因に帰属させます。

Steal Time と NUMA のフォレンジック

前節では「速度が落ちた」ことしか証明できないが、原因の特定にはさらに2つの指標が必要だ：Steal Time と NUMA トポロジー。これはクラウドサーバーのメモリ帯域幅検査で最も見落とされやすい層でもある——容量は足りていて単体実行でも基準を満たしているのに、ボトルネックはスケジューリングとメモリアフィニティに隠れている。公称構成ページには決して書かれない2項目で、実際のベンチマークスコアの差は往々にしてここに現れる。

まず st を確認：

vmstat 1 10        # 盯 st 列（Steal Time）
mpstat -P ALL 1    # 逐核 %steal

st が長期的に 3% を超え、帯域幅の低下と同期しているなら、vCPU 時間が隣のテナントに奪われていることを示す。共有型 KVM では CPU steal とメモリ帯域幅の相関が非常に高く、落ちているのは全経路であり、単に計算能力だけではない。

次に NUMA を確認：

lscpu | grep -i numa
numactl --hardware
numactl --cpunodebind=0 --membind=0 \
  sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run

プロセスをローカルノードにバインドした後、帯域幅が明らかに回復すれば、それはクロスノードペナルティ（よくあるのは 20%～40%）であり、オーバーセルではない。バインド後も依然として一人当たりの帯域幅の上限に張り付いているなら、それが本当の速度制限だ。

st、NUMA トポロジー、バインド前後の帯域幅の3枚のスクリーンショットを持ってサポートチケットを開く方が、「遅くなった」と口頭で言うよりはるかに効果的だ。再利用可能なフォレンジックテンプレートとして定着させたいなら、/app でこれら3つの数値と支払った単価を一緒に並べ、プレミアム率をはっきり計算してから、スペックアップするか、アベイラビリティゾーンを変更するか、返金手続きに進むかを決めよう。

ディスクキャッシュの断崖検証

NUMA バインディング後も帯域は天井に張り付いたままで、最後の証拠がもう一つ足りない。キャッシュの断崖で「メモリが遅い」と「ディスクが遅い」を切り分ける。方法は同じファイルをまずホットリードし、次にコールドリードして、帯域がどのワーキングセットサイズで落ちるかを見る。

# 1) ホットパス：page cache をヒットさせ、測るのはキャッシュ速度
fio --name=hot --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=0 --runtime=30 --time_based

# 2) コールドパス：キャッシュをクリアして実際のメモリ→IO 経路を測る
sync && echo 3 > /proc/sys/vm/drop_caches
fio --name=cold --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=1 --runtime=30 --time_based

判定のポイント：

• コールドリード帯域がワーキングセット 256M から 4G に増えるにつれてなだらかに低下するのは、正常なメモリ階層とプリフェッチの挙動；
• 断崖状に落ちる（たとえば 2G 前後でいきなり半減）場合、しかも変曲点がインスタンス公称の L3/キャッシュ期待値よりはるかに小さいなら、通常はディスクが先に耐えられないのではなく、メモリ帯域が絞られていることを示す；
• ついでに vmstat 1 の bi/bo と si/so も見る。IO が高くないのにスループットが急落するなら、原因はほぼメモリ側にある。

これも「実際のベンチマーク vs 公称構成」で最も失敗しやすいところだ。8GB インスタンスの公称 DDR4/DDR5 と容量は間違っていないが、AI 推論の KV cache やベクトル検索がワーキングセットをキャッシュから押し出すと、まず帯域が落ち、遅延がすぐに揺らぐ。断崖点、NUMA バインディング前後の帯域、%steal の 3 つの数値と実際に支払っている単価を並べて割増率を計算し、増強するか、アベイラビリティゾーンを変えるか、返金に進むかを決めるほうが、再起動を繰り返すよりはるかに有効だ。既成の証拠収集テンプレートが必要なら、/app でそのまま使える。

ひと言でいえば、容量が基準を満たすのは入場券にすぎない。クラウドサーバーのメモリ帯域検出で見るべきは、速度低下の変曲点がどこにあり、変曲点の後もどんな価格で支払い続けるのかだ。

ベンチマーク照合と割増判断

これまでの記事ですでに3組のハードデータを取得済みです：STREAM の Copy/Triad、NUMA ピニング前後の帯域差、そして %steal カーブ。あとは最後の一手として、これらを請求書と突き合わせるだけです。やり方は簡単で、同じインスタンスの「公称 vs 実測」を2列で書きます：

# 実測帯域（GB/s）
sysbench memory --memory-block-size=1M --memory-total-size=10G run | grep transferred
# 単価（元/GB メモリ/月）= 月額料金 / 公称容量
# コストパフォーマンス = 実測帯域 / 単価

判定ラインはざっくりで構いませんが、必ず数値化してください：

• 実測帯域が同世代 DDR4/DDR5 の公表値の 70% 以上 に達し、%steal が平常時 2% 未満：正常な共有なので、そのまま使い続ける；
• 帯域が公称期待値の 50%～70% しかなく、NUMA ピニングで 15%+ 取り戻せる：スケジューリングの問題であり、アベイラビリティゾーンを変えるか vCPU アフィニティを指定するほうが、スペックアップより安く済むことが多い；
• 帯域が 50% 未満で、%steal が長期にわたり 5% 以上、さらに Cache の崖が早く現れる：これは典型的な VPS オーバーセリング のシグナルであり、detect cloud server overselling の決定的な証拠です。

コストパフォーマンスを算出してから行動を考えましょう。8GB インスタンスの月額が 120 元で、実測帯域が同価格帯の AMD EPYC インスタンスの6割しかないと仮定すると、あなたの割増率は実に 40% です——この状況で 16GB にスペックアップしても、「1GB あたりがより高くなる」ことを拡大するだけであることが多く、機種変更や返金対応のほうが得策です。アップグレード前にまず割増率を計算し、返金前にまず証拠を残す：3回分のベンチマーク生出力、vmstat の %steal、numactl --hardware のスクリーンショットをまとめて提出し、チケットには形容詞を書かずデータだけを書けば、覆る確率は格段に高まります。更新前にも同じ測定を行い、更新時にこっそりスペックを下げられるのを防ぎましょう。完全な証拠収集表とチケットテンプレートは /guides/memory-bandwidth-checklist にあり、そのまま使えます。

結論を覚えておきましょう：容量が基準を満たしていても帯域が基準を満たすとは限りません。STREAM と Steal Time、NUMA ピニングを組み合わせてクロス検証し、割増率と照らし合わせてスペックアップか返金かを決めましょう。