おのたく日記 YouTubeも始めました→
2021-01-16(Sat) [HDD][ZFS]HDD 4TB→8TB SRM換装結果 [長年日記]
■ 1月11日の日記で換装して、1月12日の日記で一日目までの様子を書いた、Seagate Barracuda ST8000DM004の交換だけど、4日間掛かってやっとRAIDのrebuildが終わった。
# zpool status -v
pool: tank
state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(5) for details.
scan: resilvered 2.43T in 4 days 02:42:08 with 0 errors on Fri Jan 15 20:06:22 2021
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdc1 ONLINE 0 0 0
sdb1 ONLINE 0 0 0
cache
sda3 ONLINE 0 0 0
errors: No known data errors
前回は2日くらいで終わったのに、「永久に終わらないのではないか?」という恐怖を抱えながら、書き込みをしているDockerコンテナのサービスを止めながら。特に、ログで書き込みの多いGitLabサービスを止めて。なんとか、4日と3時間弱(99時間)掛かって終わった。
よくよく調べてみると、容量が4TBとかは、みんな瓦書きだと思っていたけど。前のHDDは瓦書きでなく、最近はSMRであることをメーカーも公表していて、今回が初めての瓦書き(SMR)だった。
で、時間が掛かっていたけど、どんな性能だったのかを、まとめとく
※おうちさーばは、熱が出ないようにATOM系のCPUだし、ZFSも2.0だけど全機能をまだenableにしていず、カリカリにチューニングしてあるわけではないので、ご参考。
■ 全体をスループットで説明
右端の一番最初の谷は、前のHDDでscrubを実行して、ZFSの確認をしていた時の、整合性を取るための読み込み。130MB/sくらい出ている。
次の100MB/sくらいでている書き込みの山が、zfs replaceを始めて書き込みが開始された時、30分間くらい続いている。32GBくらいは、HDD上の一時キャッシュ領域が効いていた。
rebuildは、シーケンシャル書き込みだから性能は落ちないのかとも思いきや、ここまで、その後は、8MB/sくらいが続く。ついには0に近くなってしまったので、書き込みをしているであろうDockerコンテナのサービスを止めた。
サービスを止めて、少し性能が戻り、6時間後に30分くらい100MB/sを出すけど、また10MB/sくらいに戻る。このときになぜ100MB/s出たのかは不明。
そこで85%程度終わりゴールが見えてきたので、Dockerコンテナのサービスを再起動した。ただ、様子を見ていると、GitLabは書き込みが多いようなので止めた。
で、なんとか完了。
■ Utilization
SMR HDDは、受け取ったデータを再構成して瓦のように重ねていくので、CPU利用率のようなUtilizationが上がる。
replaceを開始してから90%代。Dockerコンテナを止めるとreplaceの書き込みがはげしくなるからか100%近くなっていた。
replace終了後の通常運用でも20%程度で、結構、普段でも性能を消費していることが分かる。
ちなみに、従来のHDDだとscrubのような連続読み込みのようなときに90%とかになっていたけど、普段は10%未満。
■ レイテンシー
Logのグラフだからわかりにくいけど、青のIO wait timeいままでは5ms以下だったけど、SMRのHDDでのreplaceでは、ときどきだけど1s程度のプチフリがあり、運が悪いと最高5sとか掛かっている。5sは一日一回くらいだけどプチフリ程度ではない。
通常運転に入っても、10msとやっぱり遅い。Write WaitよりRead Waitの方が遅いのは何故?
|