Surface Pro 11 の SSD は256MB書き込みだけ妙に遅かった

Surface Pro 11 の内蔵 SSD、SDDPTQD-1T00-1124-WD は、64MB 書き込みで348MB/s、256MB 書き込みで197MB/s だった。

サイズを大きくしたのに書き込みだけ遅くなった。読み込みは64MB で682MB/s、256MB で1073MB/s まで上がるので、大きい連続アクセスのほうが速い、という素朴な見方には合う。ところが書き込みは逆に落ちてしまった。測った瞬間はスクリプトのバグを疑ったが、runs_ms を見ると256MB 書き込みだけが3回とも1秒台に乗っていた。読みと書きで顔が分かれた結果だ。

計測対象は Microsoft Surface Pro, 11th Edition。Snapdragon X 12-core X1E80100 @ 3.40GHz、メモリ32GB、Windows 11 Pro 10.0.26200 ARM64 の環境で動かしている。測定を回したのは2026-06-06 の20時17分で、この回だけを使った。外付けではなく内蔵 SSD に対して測っている。

fsync まで待つ重めの書き方

今回の数字は、カタログスペックの数GB/s を見るための測定とは別物だ。書き込みは buffering=0 で開き、書いたあとに os.fsync() を呼んで毎回フラッシュしている。OS やドライブ側のキャッシュに気持ちよく積ませる測り方ではなく、かなり実務寄りに待たせる形にした。197MB/s という数字だけがひとり歩きしないように、この条件は先に断っておく。

スクリプトの骨格はこういうものだった。

with open(path, "wb", buffering=0) as f:
    f.write(data)
    os.fsync(f.fileno())

with open(path, "rb", buffering=0) as f:
    f.read()

64MB と256MB はそれぞれ3回ずつ。小さいファイルは512バイトのファイルを2000個作り、同じ流れで消している。反復は少ない。3回だけでは安定したベンチマークとは呼びにくいので、ここでは「手元でこう見えたログ」として読むのが安全だろう。再現性を見るなら回数を増やす必要がある。

連続読み書きと小ファイルを並べる

中央値だけを眺めると整って見えるので、全反復値も残しておく。単位は runs_ms と median_ms がミリ秒、MB/s は JSON に入っていた算出値だ。

ケース	操作	runs_ms 全回	median_ms	算出 MB/s
64MB	write	260.43 / 152.37 / 183.87	183.87	348
64MB	read	93.86 / 67.71 / 106.63	93.86	682
256MB	write	1452.99 / 1250.54 / 1300.30	1300.30	197
256MB	read	223.91 / 238.50 / 245.65	238.50	1073

ケース	内容	runs_ms 全回	median_ms	files/s	1ファイルあたり
small_files	512バイトを2000個作成削除	1673.41 / 1259.13 / 1206.87	1259.13	1588	約0.63ms

64MB の書き込みは中央値183.87ms、256MB の書き込みは1300.30ms。データ量は4倍なのに、時間は約7.1倍に伸びている。ここから出る MB/s が348から197へ落ちるのは自然な計算だ。逆に読み込みは93.86ms から238.50ms で、データ量4倍に対して時間は約2.5倍に収まった。だから682MB/s から1073MB/s へ伸びる。

256MB write だけ鈍い

一番おいしい異常値は、256MB の書き込みだけ鈍いことだ。64MB では3回のうち最速が152.37ms、最遅が260.43ms で、最遅は最速の約1.7倍。256MB 書き込みは1250.54ms から1452.99ms なので、比は約1.2倍に縮む。ばらつきというより、遅い帯域に入ったまま安定しているように見える。

理由は断定しない。buffering=0 と os.fsync() で毎回待っているので、256MB の連続書き込みでキャッシュや内部の書き込み処理が飽和した可能性はある、という範囲に留める。SMART や温度やコントローラ内部の状態までは見ていないので、「キャッシュ切れ」と言い切ると測っていない数字まで書いたことになってしまう。

読み込み側の動きは対照的だった。256MB の read は223.91ms、238.50ms、245.65ms でかなりまとまっている。最速と最遅の比は約1.1倍。連続読み込みでは、サイズを大きくしたほうがドライブにも OS にも都合がよかったのかもしれない。ここも推測に留める。

小さいファイルは別の競技

512バイトのファイルを2000個作って消すテストは、中央値1259.13ms で1588 files/s だった。1ファイルあたりに直すと約0.63ms。数字だけ見ると速く感じるが、扱っているデータ量は512バイトずつなので、64MB や256MB の連続読み書きとは競技が違う。

node_modules や .git が遅く感じる理由は、この0.63ms の積み上がりに近い。ファイル本文は小さくても、作成、ディレクトリエントリ更新、削除、同期待ちが1個ずつ発生する。2000個なら1.26秒前後で済むが、数が増えれば待ち時間が目立つ。大きな1本のファイルを読む682MB/s や1073MB/s とは、同じ SSD でも体感がつながりにくい。

この差は個人的には納得感があった。ARM64 だから遅い、NVMe だから速い、という単純な話ではなく、アクセスの形が変わると Surface Pro 11 の内蔵 SSD でも見える顔が変わる。それが今回の面白いところだ。

SSD が遅い、とはまだ言わない

今回いちばん危なかった勘違いは、256MB 書き込みの197MB/s を見て「SSD が遅い」と言いそうになったことだ。実際には、フラッシュを強制する測り方で出た数字であり、普段のコピーやアプリ起動をそのまま表す値とは別扱いにする。条件を混ぜると記事全体が間違える。測っている待ち時間の種類が違うからだ。

反復回数も3回だけ。最大最小の比を見ると、64MB read は約1.6倍、64MB write は約1.7倍、small_files は約1.4倍まで動いている。256MB read は約1.1倍、256MB write は約1.2倍で比較的落ち着いたが、これだけで傾向を固定するには足りない。

次に測るなら、64MB と256MB の間を増やしてみたい。128MB を挟めば、書き込みがどこで落ち始めるのか少し見えるはずだ。fsync あり・なしを分ける測定も必要だろう。今回はあえて重い条件を残した。node_modules や .git で感じる待ち時間に近づけたかったからだ。

開発作業の物差しにする

この結果を見て、巨大な連続ファイルのコピー速度だけで SSD を判断するのはやめた。Surface Pro 11 の内蔵 SSD は、読み込みの連続アクセスでは256MB で1073MB/s まで出る。一方、フラッシュつき書き込みでは256MB が197MB/s まで落ちた。どちらも同じドライブの姿だ。

開発作業で効くのは、小さいファイルのほうかもしれない。パッケージ展開、Git のチェックアウト、キャッシュの作成削除。そういう処理は512バイトや数KB の世界を大量に触る。今回の2000個で1259.13ms という数字は、その待ち時間を思い出すための物差しになる。

結論を急ぐなら、読み込みは大きいほうが伸び、フラッシュつき書き込みは大きいほうが落ち、小ファイルは1個約0.63ms で連続 MB/s とは別腹だ。もう少し回数を増やさないと断定はできないが、「NVMe なら全部速い」という雑な期待は外れた。2026年6月6日時点のこの1回だけでも、それは確認できた。