日本の湿気った空気には、水冷が良い

日本の夏は蒸し暑い。これは日本人ならば誰でも知っていると思う。

日中最高気温は35度以上になり、40度だって当たり前。
なのに湿度が60%を下回る事はない。恒温動物にとって地獄のような環境である。

さて、一方その頃(え?)。

飽和水蒸気量という単語をご存知だろうか? Wikipediaへのリンクをくっつけてあるが、ようするに 1m³の空間中に存在できる水蒸気の質量をgで現したもの、だそうだ。当然、これは100%のときの質量であって、たとえば湿度が60%の場合、存在している湿度の量はその60%になる。

で、大事なのはその曲線の形状だ。Wikipediaの画像をちょいと無断拝借:



数字はどうでもいい。大事なのは形状だ。
わかるだろうか?気温10度から20度へ10度上昇した場合と、20度から30度へ10度上昇した場合とでは、後者の方が増大量が大きい。

問題はこうだ。
データセンターのようなマシンルームでは、室温20～25度、湿度0～30%になるように押さえつけなくてはいけない。内部に格納されている全てのマシンが空冷だからだ。外気温が35度、湿度50%の状態からこの状態へ空気を冷やすにはどれだけの熱量をくみ出せばいいのだろうか?当たり前だが単純に20度に冷やすだけでは湿度は100%になってしまうので、20度のときに湿度30%になるぐらいまで水を減らす必要が出る。

水が同じ温度の水蒸気になるためには気化熱が必要だ。Wikipedia の蒸発熱のページによると、40.8 kJ/mol のエネルギーが必要だ。これは0度から100度まで温度を上げる際に必要な熱量の5倍に当たると言う。逆に言うと水蒸気を水に戻すときにはこれだけのエネルギーを「気温降下とは別に」くみ出さなくてはいけない。

一方で、マシンの冷却に湿度は関係ない。湿度はマシンが錆びたり、黴たりするのを防ぐために下げるのであって『気温は下がらないけれども、湿度を下げれば…』とはならないのだ。マシンは汗をかかないから。

---

そこでこういう発想が出てくる。

仮に、気温を20度まで下げる代わりに30度までしか下げない事を考えよう。で、チップなど主な冷却対象に液冷装置をつける。液体の温度は30度にすることで結露を防ぐ。代わりに、液体を強制循環させてどんどん熱をくみ出す。CPUなどの表面温度は40度以上なのは空冷であっても変わらないので、30度の液体を強制循環させた場合でも十分な冷却効果は得られるはずだ。

30度までしか気温を下げないので、除湿しなくてはいけない量が圧倒的に少なくて済む。これによってデータセンターの冷却設備の能力を、マシンを冷却する事に集中させる事ができる。

---

さて。これでどれぐらい無駄なエネルギーを削減できるか。
うーん。面倒なので誰か代わりに計算してください(おぃ

大雑把に言っても、夏場、エアコンはもうジャブジャブと水を「生産」しています。水1molは18gしかありません。これは18ccと同じです。一合は180ccなので計量カップ一杯は10molです。
1molの水がジャブッと出るたびに40.8kJが必要なので、180ccの水が出てくるのには408kJの熱をくみ出す必要があります。

水を1mol、0度から100度にするには7.53 kJ必要です。別の言い方をすると10度下げるには0.753kJくみ出すだけでいい。乾燥空気の場合は(http://q.hatena.ne.jp/1180249482によると)0.288[kcal/m3 ℃]=1.2kJちょいですから12kJくみ出せば10度下がります。このことから考えると、ワンカップの水が冷却器から出てくるたびに、34m³の空気を冷やすのと同じ能力が消費された、と見ることが出来ます。液冷にする事で、この能力の大半を、本来のマシンを冷やす事に振り向け直す事ができるのです。

---

夏場、冷房装置からどれだけの水が出ているのか見てください。
家庭用のエアコンは真夏の日中に空気を20度に冷やしたりしません。なのにそれだけでるのです。

マシンルームのデザインに液冷対応を考慮するのは十分価値のある事だと思いませんか?

Process Monitorの出力をいじる

WindowsにはProcess Monitorというツールがある。多分アンカーの指している場所がダウンロードサイトの中で最も簡単に手に入れられるページだと思う(日本語で説明が書いてあるから)。

対応OSは 2000, XP, 2003, そして Vista だそうだ。

Process Monitor (procmon.exe)は、NT kernelへのシステムコール…というかリクエストキューに積まれたリクエストを記録し続ける。記録されるのは全てのプロセスのリクエストだ。unixのstraceなどと違って「このプロセスの」とか「あのプロセスだけ」という制約は無い。そのおかげでシステム全体の状態が判るが、これはセキュリティ上は結構危険な状態でもある。

procmon.exeは記録したシステムコールを表示するときにも使える。いくつかのフィルター条件を設定して望みのものだけを選び出すことが出来る。ある特定のプロセスが発行したもの、特定のスレッドが発行したもの、あるファイル(あるいはレジストリパス)に対するIO、あるシステムコールだけを選ぶ…などができる。実はシステムコールを発行した(キューに積んだ)時刻だけではなく、これが完了するまでにかかった時間も記録している。
「システムコールが終わるまでに0.1sec以上かかった」
とか
「システムコールに対する応答が無かった」
などという条件も設定できるのだ(NTのシステムコールは「キューにリクエストを積んで」「応答を待つ」形式なので、本質的に全て非同期コールだ)。

障害解析やパフォーマンス解析においてこれほど強力なツールはまず、ない。

が、世の中どんなに頑張っても
「それは俺の設定したい条件じゃない」
と言うことはあるわけで。そうなるとPerlのようなスクリプト言語の出番になる。

---

Perlに読めるようにするためには、procmon.exeが記録した内容を何らかのテキストの形で出力してもらわなくてはいけない。それ自体は簡単だ。

% procmon.exe /OpenLog 'filename.PML' /SaveAs 'filename.CSV'

PMLは procmonが出力するバイナリフォーマットのログ、filename.csvは「csvフォーマットでファイルを出力しろ」と言う意味だ。ちなみにこの場合、csvファイルはutf-8で出してくれる。なんとUCS2やUTF-16じゃないのだ。ありがたい。

しかし、この出力には2つ問題がある。

1つ目はファイルの先頭にBOM … Byte Order Mark …がついている点だ。確かにこれがあれば確実にUTF-8だと判るのだが、私の知る限り perl が標準入力から読み込むファイルの操作に関して、BOMを適切に処理できる、と言う話は聞かない。だから、BOM…この場合はファイル先頭の3byteなのだが…を削らなくてはいけない。

2つ目はCSVそのものにある。いや、もちろん、CSVだって悪いわけじゃない。もし1つのValueの中にカンマで分割された文字列が入っているのでなければ。

perfmon.exe の記録のいくつかのフィールドが、それ自体カンマで区切った複数フィールドから成り立っているのだ。例えば Detail というフィールドなんかがそうだ。たとえば:

"User Time: 0.0781250, Kernel Time: 0.0312500, Private Bytes: 1,806,336, Working Set: 5,439,488"

とか(これは Process Profiling をやっているときの記録だな)、

"Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx, OpenResult: Opened"

(これはファイルに対する IRP_MJ_CREATE のDetailだな)、このように1つのエントリ自体が複数のカンマで区切られたフィールドになっている。判ると思うが、各エレメントは " で囲まれている。

すると、単純にカンマをセパレータにして split をするとエライ目に合うわけだ。そこで、CSVをTSV… Tab Separated Values …形式にする。" で囲まれた領域に TAB は含まれていないので split をしかけるときにセパレータを /\t/ と定義すれば、あっさりと正しく split できるようになる。ファイルをこの形式にしておく事で、この後何度も統計処理や絞込みのために行う splitting rule を簡素化できるわけだ。

TSVにするフィルター自体はすごく簡単に作れる。これがコードだ:

tail --bytes=+4 input.CSV |\
 sed -r -e 's/\r$//g' \
        -e 's/\",\"/\"\t\"/g'\
  > output.TSV

最初の tail --bytes=+4 は input.CSVの先頭3バイトを取り外す。これでBOMが無くなる。

GNU sed に与えた -r オプションは「拡張正規表現」を使えるようにする、というものだ。実際の正規表現はその次の2つの -e で始まるものになる。

's/\r$//g' は行末の 0x0d を取り外しているだけだ。ようするに改行コードを unix 形式になおしている。

's/\",\"/\"\t\"/g'は 『","』 となっている場合の , を TAB に入れ替える。ここには、procmon は「"," というフィールドデータを吐かない」という前提を使っている。少なくとも今の所、見たことは無い。多分大丈夫だろう。

---

ちなみに。TSVに直した後も、各エレメントは " で囲まれたままだ。で、 " で囲まれたエレメントを処理するときには「まだ」面倒な問題が残っている。

" で囲まれた中で " を表現するには『""』のように"を2回連続しなくてはいけない。

で、「そのプログラムはどのように起動したのか」を説明する「Command Line」フィールドに絶対パスが例の『Program Files』を含む場合、このようになってしまうのだ：

"""C:\Program Files\IBM\Director\websrv\dirwbs.exe"""

一番外側の " は「フィールド」を囲む " だが、その内側の "" は実際には1つの " を " で囲まれたフィールド内で表現するためのものだ。

この点だけは注意した方がよい。