2013-04-17

サーバ用途でコンシューマ SSD へ調子に乗って書き込みすぎると壊れるという話

Crucial M500 の write endurance が 75TB しか無いというのが話題になっていて、同じく 75TB である m4 をわざと虐待していたホストはどうなったのか気になって調べて見たところ、面白い結果が観測されたという話。

石橋を叩いて壊し障害時の挙動を見るべく「自社全サービスのアクセスログを受け止める syslog サーバ」という、どう見ても書き込み中心で SSD にやさしくないホストをあえて動かしていた。具体的には下記のようなノリのホストである。 iostat の一行目なので uptime 数百日における平均値であることに注意。

[root@touge ~]# iostat -k -x -d sda | sed -n '3,4p'
Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda              27.36   414.31 47.72 82.46  2902.21  3431.04    97.30     0.39    2.96   0.62   8.04
[root@touge ~]#

平均で 3431KB/s 出ている。上記は HV 上での値なので、 VM の block device layer における write merge 前では write 900IOPS ぐらい。
SMART Attribute を確認して見たところ、 14ヵ月でだいぶ磨り減ったことが観測された。*1 202 Perc_Rated_Life_Used は保証期間に関する値で、書き込みまくって VALUE が 0 になるとメーカ保証の範囲外となる。 Perc は Percentage の略で、 RAW VALUE は「何パーセント使ったか」であろう。

[root@touge smartmontools-6.1]# ./smartctl -i /dev/sda | egrep '(Model|Firm|Capa)'
Model Family:     Crucial/Micron RealSSD m4/C400
Device Model:     M4-CT512M4SSD2
Firmware Version: 0309
User Capacity:    512,110,190,592 bytes [512 GB]
[root@touge smartmontools-6.1]# ./smartctl -A /dev/sda | egrep '^(ID|  5|  9|173|195|202)'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   100   100   001    Old_age   Always       -       13748
173 Wear_Leveling_Count     0x0033   033   033   010    Pre-fail  Always       -       2018
195 Hardware_ECC_Recovered  0x003a   100   100   001    Old_age   Always       -       106
202 Perc_Rated_Life_Used    0x0018   034   034   001    Old_age   Offline      -       66
[root@touge smartmontools-6.1]#

m4 の保証値である 75 TB を 3431KB/s で焼きつづければ単純計算で 271日なので、そら当たり前だろうという話ではあり、設計段階から分かっててわざとやった結果である。むしろ 3.4MB/s で 426日ほど*2焼きつづけたのにまだ 1/3 残ってることが驚きである。 2.35倍ぐらい持っている。
173 Wear_Leveling_Count の RAW VALUE も興味深い。 25nm 世代 NAND の書き換え回数が 3000回なので、これがページの平均書き換え回数だと色々しっくりくる。
14ヵ月で 1/3 まで減っているので、単純計算すると上記の使い方でこいつは 2年弱しか持たない。実環境の最悪値かつ保証が切れるだけだが「容量が手狭になるまで持てばいい！」で済ますには微妙なラインである。

結論

最近の*3コンシューマ向け SSD は書き込みまくる用途だと壊れうる。
常日頃から「SSD は壊れない」とか言っていますが、これは「お前が言ってる書き込み量はバーストの値*4でライフサイクル平均でそんな書いてる訳じゃないだろ」ないしは「DB 用途でヘビーに使っていても実は書き込みは*5そんなに多くない」という側面が強く*6、裏を返せばライフサイクル平均で書き込み量が重くのしかかる用途だと寿命を気にする必要がある。
気にする必要がある、なので、たとえば「同じぐらいの平均書き込み量で 10台ストライプするから 4000日=11年ぐらい保証の範囲で使えるので大丈夫だろう」なり、「書き込み 3倍あって同じく単体で使う予定だから 4ヵ月でいつ壊れてもおかしくない」という話ではある。
コンシューマ向け SSD も登場から年月が経ち、各ベンダーとも読みが正確になってきたのかマージンが削られる傾向にある。*7 エンタープライズ向け SSD を選択肢に入れるなど、きちんと書き込み量のキャパシティプランニングを行う必要がある時期に達しつつあるのではないだろうか。

備考

以下は、生の smartctl 出力と備考。

*1:SMART Database が最新じゃないと unknown ばかりで読みづらいので最新版の smartmontools を使っている。

*2:Power On Hours と合わないが電源入れてから直ぐに使ってる訳ではない

*3:具体的には 25nm 世代以降のものを指している

*4:サーバ捨てるまでの4年間を考えれば日単位もバーストである

*5:Web アプリケーションは九割方参照である則

*6:メーカが安全側へ盛大に倒してるのでマージンを美味しくしゃぶりましょうという意図ももちろんある

*7:d:id:halfrack:20130417:1366197019

2013-04-10

■

赤色灯が付いたオービスが目印の山中越にて。
モニタが真っ暗になるぐらい暗くてオートフォーカス出来なかったら無限遠になるだろ、と撮影したら無限遠ではない何かのピントになってしまったの巻。
露光時間が秒単位になる場合は1枚撮る度に再生モードにしてピントを確認しながら MF 撮影する必要があると学びました。
$f:id:halfrack:20130408030004j:image$
送電容量が大きいのかごつい送電線である。撮影時は雨上がりの夜で湿度が高いためか、ジージーという放電音が聞こえていた。

2013-04-03

■

CPU もディスクも貧弱なホストで portmaster+packages にて binary only FreeBSD をしたい。という話。

portsnap.conf の REFUSE に全カテゴリ指定
portmaster.rc は以下

PM_PACKAGES=only
PM_ALWAYS_FETCH=pm_always_fetch
PM_INDEX=pm_index
PM_INDEX_ONLY=pm_index_only
PACKAGESITE="http://ftp10.us.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/"
MASTER_SITE_INDEX="http://ftp10.us.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/"
INDEXFILE="INDEX"

portsnap update で INDEX とか UPDATING の類だけ更新して、 portmaster はデフォルトで -PP 相当になるようにする、という感じ。これで上手く動くかな？
ports tree を持てばもっと楽ちんなことは確実だが、容量ちいさくて置いとけないんです…。
こういうのは freebsd-users-jp で相談したら良さそうな気もする。

2013-04-01

Comet 的な HTTP トラフィックのベンチマークを weighttp でやってみる

HTTP コネクションは張ったままだけど大して通信しないという、いわゆる Comet のような負荷をベンチマークするのは意外と難しい。
以下の patch を当てた weighttp でベンチマークすると良い感じだった。 weighttp はいわゆるベンチマークツールだが、軽量かつイベントドリブンなのでコネクション数について良くスケールする。

** worker.c.orig       2013-04-01 16:59:12.000000000 +0900
--- worker.c    2013-04-01 17:06:02.000000000 +0900
***************
*** 17,22 ****
--- 17,23 ----
        worker = W_MALLOC(Worker, 1);
        worker->id = id;
        worker->loop = ev_loop_new(0);
+       ev_set_io_collect_interval(worker->loop, 3);
        ev_ref(worker->loop);
        worker->config = config;
        worker->num_clients = num_clients;

上記パッチを当てると、トラフィックは 3秒に 1回ぐらいしか流れなくなりぬるくなる。コネクション数以外の部分では当たらなくなるので好都合。
こいつを使ってクライアント 10台ぐらいで nginx をイジメると簡単に C10K を突破する。ソースポートの数とか色々当たってくるので、(頑張ればもっと張れるのは知っているが)クライアント 1台あたり数千〜数万コネクションに抑えた方が面倒は無い。

参考

weighttp 自体は以下を見て知ったので、詳細は直接見た方が早い。 ulimit まわりの話もあります。
http://www.iij.ad.jp/company/development/tech/activities/weighttp/

追記

便利
https://github.com/y-uuki/weighttp/commit/631d1c7522410a6d009b9affcbc378cff9ce813a

2013-03-23

■

大抵の場合 NEX-5R のオートモードに負けるので辛い気持ちになるのだが、絞り優先でオートより綺麗に写るというパターンを初経験。三脚を使った夜景撮影だが、例によってカメラを遊ぶ目的なので構図とか適当である。(なんか写り込んでるし...)
上は ISO100 WB:蛍光灯の絞り優先、下は三脚夜景モード。 ISO3200 なのと WB:AUTO なのがアカン感じ。
$f:id:halfrack:20130324021533j:image$
$f:id:halfrack:20130324021642j:image$
ISO400 WB:蛍光灯 DRO:OFF で、対象が照明に照らされて入れば AF のまま、対象が点光源とかなら MF で撮影、ってのが良さげ。手持ちでも ISO400 で頑張った方が良い。 FullHD ぐらいに縮小して見る場合は ISO800 だと荒さの違いが見える。
(芸術的センス以外の部分は)ソフトウェアが人間に勝つ世界、要するにオートでシャッターボタン押すだけが一番綺麗に撮れるという世界の方が、個人的な理想に近くはある。

2013-03-18

SSD に関する雑感

SSD は block erase やら wear leveling で作業領域としての DRAM に大きく頼らざるを得ない。
電源断により DRAM の dirty な領域が消失することを考慮しながらメタデータの破損を防ごうとすると、 DRAM -> NAND の書き込み順序に強い制約が生じ、高速化に支障を来す。(ファイルシステムにおけるそれと同じように)
DRAM with BBU を仮定すると、ファームウェアが書き込みの順序をイジる自由度が大幅に増す。
HDD と違い、 NAND は短時間ならキャパシタの電力で書き込みを行うことが出来るので、 SSD 内部での DRAM with BBU が容易であり広く普及するだろう。
- コンデンサは二次電池と違い、はめ殺しに出来る程度に寿命が長い。
- 定期的な交換を必要とせずメンテナンスが楽なので、コンシューマ向けにも普及するだろう。
安価な SSD であっても、コントローラは数十チャンネルの NAND インターフェイスを持ち、それぞれを並列に動作させることが出来る。

多チャンネルの NAND インターフェイスと、 BBU で保護された DRAM があれば、並行な I/O 要求や block erase, ware leveling を強力に最適化したファームウェアを書けるので、 SSD は大幅に高速化する。

ケミカルコンデンサも電気二重層コンデンサも経年劣化で容量が減るので、バックアップされてるはずだったが実は容量が足りなくて消えた！という事故が今後 10年ぐらいで起きるだろう。
- しかし RAID カードの BBU で同様の事が起きるリスクと大して変わらないと思っている。
- 将来的に SSD にも「定期的にバックアップキャパシタの容量をチェックする」みたいな機能が入るだろう。
コンシューマ向けのくだりで定期的な交換は不要と言っているが、全体の製品寿命に対しては十分な寿命があり問題ない、と考えている。(マザーボード上のキャパシタ同様)

電源断についてあーだこーだ書いたが、私が欲しいのは「電源断でも壊れない堅牢なストレージ」ではなく、「電源断を恐れずに高度に性能を追求したストレージ」である。
- もちろん電源断でも壊れない方が良いです。
電源断まで厳密に保証したミッションクリティカルなストレージを選んで使うより、ノード冗長を取る方が低コストである。
- ノード冗長の副次的な作用としてオペミスに強くなるというのも、個人的に重視している。
- 他にも色々ありますが、大体こういう思想です。 http://nippondanji.blogspot.jp/2009/03/ssd.html

商用 UNIX でカチカチに固めた環境じゃないし、一度電源断したホストの DB を使いつづけたりしないでしょ。
Linux なんてファイルシステム・ブロックデバイスレベルでテキトーなので、 kernel panic したら一巻の終わり。

つらつら書きましたが、上のようなことを考えながら日々 SSD を使っています。
私は SSD を作る人ではないし、最新の Linux kernel について深い知見があるわけではないので、 Linux kernel hacker からすれば最近の kernel なら問題ないという意見が出てくるでしょうし、 NAND ストレージベンダーからすればツッコミどころ満載かと思いますが、あくまでこういう考えの奴も居るということで。

2013-03-17

NEX-5R で遊ぶ

お手軽コンデジよりあきらかにムズい。デジカメの性能を試そうなので構図が酷いのはご愛嬌。
まずオートフォーカス時々効かなくて、手ブレよりピンボケ写真を量産したので、 DMF か MF で合わせた方が良い。
$f:id:halfrack:20130316223913j:image$
気合があればシャッタースピード 1.3秒でもブレないので ISO400 ぐらいは使える。むしろピント合わない。
$f:id:halfrack:20130316224144j:image$
上の ISO400 と比較すると ISO3200 やっぱノイジー。空とか。
$f:id:halfrack:20130316224517j:image$
高感度撮影するなら連射合成したほうがノイズは少ない。
$f:id:halfrack:20130316224719j:image$
しかし、下の ISO400 と連射合成で、遠景部分を見てると、彩度が落ちるのか、やっぱり連射合成しないほうが好みな写り方をする。フォトライフの画像縮小がちょっと微妙なので拡大して見た方が良い。
$f:id:halfrack:20130316224041j:image$
$f:id:halfrack:20130316224635j:image$
$f:id:halfrack:20130316224951j:image$
$f:id:halfrack:20130316224921j:image$
ちなみに、各写真とも連射合成の場合ホワイトバランスが正しい感じになっているのは、多分カメラが勝手に AWB ではなく適当なホワイトバランスに固定しているから。ナトリウムランプなのでオレンジ色に写るのが正しいので、 AWB から蛍光灯あたりに固定するのが良さげ。
なんというか、一番気に入った子の写真が手持ち夜景モードである辺り、素直にカメラに任せた方が一番綺麗なのではないかという疑惑はある。今度は手持ちじゃない方の夜景モードであるとか、レタッチ前提の撮り方も試してみよう。
$f:id:halfrack:20130316224835j:image$
ホワイトバランスを蛍光灯に、 ISO400 ぐらいで撮影、 DMF でピント合わせる、ぐらいが得られた知見だった。
それなりにちゃんとしたカメラを使うと、 NIKON P300 のお手軽っぷりを再認識出来る…。テキトーに撮ってもソコソコ綺麗に撮れる。