GCEやColaboratoryのストレージに連続で書きこむと徐々に遅くなってくる件

表題の通り、GCE (Google Compute Engine)のストレージは連続で書いていると遅くなってきます。最初は制限がないけど徐々に制限がかかってくるという表現の方が正確かもしれません。これはGCPに限らず他のクラウド事業者でも同様だと思います¹。

この現象は、次のようなコマンドをシェル上で打ち込めば確認できます。

$ for i in $(seq 1 100); do dd if=/dev/zero of=./dd.$i.tmp bs=1M count=30;　done
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.0514848 s, 611 MB/s
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.0977361 s, 322 MB/s
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.191857 s, 164 MB/s

（略）

31457280 bytes (31 MB) copied, 0.842787 s, 37.3 MB/s
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.838682 s, 37.5 MB/s
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.913719 s, 34.4 MB/s

最初は600MB/sとかで書きこめているのに、3GBほど連続で書き込んでいると最終的には40MB/s程度まで落ちてきます。

こうした環境ではiSCSI的なネットワークストレージを採用していて、かつ内部LANのどこかで²QoSが掛かっているせいでこんな挙動になるんでしょう。

GCEだけでなくColaboratoryのローカルストレージも同様で、デカいファイルを操作しようと思うと案外遅くて難儀します。

こうした環境で書き込み性能を稼ぎたいような場合は /dev/shm (tmpfs) でファイル操作を行うのも選択肢の1つでしょう。

また、GCE環境で予算が十分ある場合³はストレージサイズを上げるべきでしょう。AWSやGCPではストレージサイズを上げるとIOPSが上がります。Colaboratoryの場合はお金が払えないので困りますね。

---

1. 「最初だけ速い」というのはわざとやっているわけではなく、仕組み上そうなっているんじゃないか、という意味です ↩

2. それともストレージ側の機能で実現してるんですかね…？ ↩

3. お仕事で必要なら予算はつくはず ↩