NAKAMURA Minoru の日記 (2013年5月)

[Movie] オブリビオン

会社が終わった後にラゾーナ川崎の109シネマズで「オブリビオン」(公式)を観てきた。 IMAX は 3D だけじゃないことを知った。

序盤はわりと退屈なのだが、主人公が秘密に気づく中盤以降は面白い。 サリーの映像の正体と最後に冷凍カプセルから○○が出てきたところは膝を打った。

日本はこうして日本住血吸虫症を克服した＠国立科学博物館

上野の国立科学博物館の企画展「日本はこうして日本住血吸虫症を克服した」(公式)を観てきた。 企画展なので常設展示で見ることが出来る。

日本住血吸虫症についてはWikipeidaの項に詳しいが、ミヤイリガイを中間宿主とする日本住血虫によって引き起こされる病気で、この解決のために多数の研究者の努力があった。 それに関係する展示物が6畳間が2部屋ぐらいにぎゅうぎゅう詰めで展示されている。

これがミヤイリ貝で予想以上に小さい

山梨県で配布された冊子。 峡陽文庫で読める

桂田富士郎博士の書いた日本住血吸虫発見の論文や、宮入慶之助博士と鈴木稔博士のミヤイリガイが中間宿主であるとする論文が展示されている。 両方ともドイツ語だ。 書籍関係は撮影禁止になっていたのでここには上げない。

小展示だけど非常に興味深いのでおススメ。

秋葉原で見かけた宣伝カー

秋葉原的だ。

東証の日経平均株価が乱高下

このところ順調に値上がっていた東証の日経株価平均が 1,143 円安になった。 歴代11位の下げ幅とのこと。 東証の日経株価平均に対する先物取引に対してサーキットブレーカーが発動して一時取引停止となった。

中国の5月の製造業購買担当者景気指数(PMI)の悪化が引き金になったといわれるが、High Frequency Trade(HFT)が原因のフラッシュ・クラッシュだという説も流れている。 もし本当だとすると、日本で最初のフラッシュ・クラッシュになる。 アルゴリズムの誤作動と思われる挙動は昨年の7月にも起きている。

海外ではフラッシュ・クラッシュは2010年5月6日のダウ・ジョーンズ工業株平均や2012年8月3日のNYSEなどで発生している。 ヨーロッパでフラッシュ・クラッシュが起きた事例は知らないが、ヨーロッパはすでにHFTへの規制を開始している。

参考

• ニューズウィーク | ダウ「瞬落」、真犯人は超速取引
• WIRED.jp | ウォール・ストリート、暴走するアルゴリズム
• WIRED.jp | アルゴリズムの暴走から?いかに“市場”を守れるか
• 教育は参考資料 | 証券会社の自動注文プログラムのバグでニューヨーク証券取引所が大荒れ

3.3 で改善された GlusterFS のリバランスが 3.4 beta で悪化しているんですけど？

2012年2月23日の日記で GlusterFS 3.3 では Elastic Hash Algorithm が改良されて、brick を追加してもリバランスが発生しなくなったこと確認した。

しかし次のリリースである 3.4 のベータ版(3.4.0-0.4.beta1)で確かめてみると、リバランス性能は大幅に悪化しているようだ。 10 個の brick のボリュームに 10,000 ファイルを作成し、その後に 1 brick を追加して 11 brick にしてリバランスすると、なぜか 9,371 ファイルが移動して元の brick に残ったのが 629 ファイルしかなかった。 これは 3.3 beta2 はおろか 3.2.5 よりも悪い結果だ。

また 3.3 の Generally Available 版(3.3.1-1) で同一のリバランスをすると、いつまでもリバランスが終わらず glusterd デーモンや glusterfsd デーモンが CPU 実行時間を食いつぶし続けている。 リバランスを止めずに brick 直下をのぞくとある程度の時間が経つととファイルの移動が止まり、結局 66 ファイルしか移動しない。 これは 99.3% も元の brick に残るという結果だが、追加した brick に移ったファイルが 24 個しかないので完全なリバランスではない。 また glusterd/glusterfsd デーモンのせいで CPU 負荷が高いためか、マウントした glusterfs ファイルシステムでの作業が非常に遅くなる。

ただしこの実験は 1 台のサーバに 10 個のディレクトリを作って、個々を brick に化かしている。 brick が別々のサーバに割り当てたらまた別の結果が得られる可能性はある。

# gluster volume create gv0 \
      dhcp11:/export/brick00/ \
      dhcp11:/export/brick01/ \
      dhcp11:/export/brick02/ \
      dhcp11:/export/brick03/ \
      dhcp11:/export/brick04/ \
      dhcp11:/export/brick05/ \
      dhcp11:/export/brick06/ \
      dhcp11:/export/brick07/ \
      dhcp11:/export/brick08/ \
      dhcp11:/export/brick09/

日比谷オクトーバーフェスト

日比谷オクトーバーフェストが開催。 例年よりも人が少ないような。

今日も見た度肝を抜く宣伝カー

5月12日には代々木公園に居たロボットレストランの宣伝カーが、今日は日比谷公園前に居たよ。 相変わらず周りの人を引き付けるインパクト。

タイフェスティバル 2013 代々木

毎年この時期になるとやっているタイフェスティバルに行ってみた。 昨年は5月12日に行っている。

ドリアンのアイスクリーム。

今日の代々木公園で開催されたタイフェスで展示・販売されていたバンコクのモデラーさんの作品。

木製のカエル。 口にくわえているバチで背中の部分を擦るとカエルの鳴き声のような音がする。1個買った。

タイのタクシー。

今日見た度肝を抜く宣伝カー

代々木公園から出てゆくところで見かけた凄い宣伝カー。 新宿歌舞伎町にあるロボットレストランの宣伝らしい。 レッドブルの宣伝カーよりも凄い。

フランシス・ベーコン＠国立近代美術館

竹橋の国立近代美術館で開催中のフランシス・ベーコン展を見てくる。

フランシス・ベーコンの作品を主に国内外の美術館や収集家からバラバラに借り受けての展示である。 一人の作家の作品を専門に集めている美術館の主催する特別展というわけではないので、気合が入っている。

皇居東御苑

竹橋からすぐのところにある皇居東御苑を観てくる。 GW 中ということもあり人は結構多い。 前回は平川門から入ったが、今回は北桔橋門から入ってみる(地図)。

北桔橋門	北桔橋門見たお堀	反対側
天守台	天守台の石垣	天守台の頂上からの眺め	天守台の頂上付近
江戸城本丸御殿
石室
富士見櫓
展望台
大番所
大手門

[Food] エチオピア＠神保町

久しぶりのエチオピア(公式、食べログ)。 横浜の Carrifé by ETHIOPIA には時々行くが、神保町の店に入るのは2004年10月24日以来なので9年前だ。

前回 Carrifé で食べた野菜豆カレーが美味しかったので(2012年12月16日)、野菜カレーを食べてみる。 だが同じような素材を使いながらシャキシャキ感が足らない。

[Movie] L.A. ギャングストーリー

川崎チネチッタでL.A. ギャングストーリーを観る。 原題は "Gangster Squad"。 実在のギャングのミッキー・コーエンを逮捕するまでの物語だが、事実とはかなり異なる(コーエンは脱税で捕まった)。

チネチッタで沖縄物産展

チネチッタで沖縄物産展をやっている。 ちょっと獅子舞顔のシーザー。

グレートジャーニー 人類の旅＠国立科学博物館

上野の国立科学博物館に企画展の「江戸人展」を観に来たのだが、一緒にやっている特別展「グレートジャーニー 人類の旅」をついでに観て行く。 特別展の券を買うと常設展にも入れるからね。

展示内容の紹介。

乾燥させたリャマの胎児	アルパカ	ヘラジカ
北極圏に住む人の衣装		探検家・関野吉晴が作った縄文号

アフリカ、タンザニア・ラエトリ遺跡にある最古の二足歩行の足跡の化石にあわせて、アファール猿人復元の試み。

江戸人展＠国立科学博物館

つづいて「江戸人展」へ。 企画展なので常設展示の中にある。

国立科学博物館は江戸時代の遺跡から発掘された人骨を6,000個体以上保存しており、その中から江戸に住んだ人々の骨を紹介する。

入り口

ごあいさつ

骨は社会身分の階層によって、特徴的があるそうな。 食べ物屋や労働の違いが原因らしい。 頭骨は概して小さい。

骨を見ると成長や病気を確認することができる。 また江戸期でも乱闘や処刑場の試し切りによって刀傷を負った人骨も見つかる。

頭骨が武士・町人など階級別に並べてある

刀剣で傷をつけられた遺骨

処刑場の頭骨 試し切りにされたようだ

死後にお歯黒を塗った跡

今日見つけた面白いオブジェクト

御徒町で見かけた飲み屋。

御徒町から秋葉原に行く途中にある「ヤサイ・ワイン」というお店の前にあったオブジェクト。 でっかいワインビンの中にコルクが山ほど入っている。

Ceph の CRUSH マップが階層化されている場合のオブジェクトの再配置

Ceph の CRUSH アルゴリズムでは、HDD (Ceph では OSD) の存在する構造を階層的に表現することができる。 RADOS の概略のページでは、1階層だけの CRUSH アルゴリズムの説明はしたが、これを複数階層にした場合にどうなるかをメモを残す。

例として 8 台の OSD があり、これが 2 台のホストにつながっているという構成を考える。 起点となる default pool type バケットがり、ここに 2 台の host type バケットがつながっている。 各 host type バケットが 4 台の OSD を持っている。 オブジェクトを OSD に割り当てる場合、まず default pool type バケットから 1 ホストを選択し、host type バケットからさらに 1 OSD を選択する。

# devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3
device 4 osd.4
device 5 osd.5
device 6 osd.6
device 7 osd.7

# types
type 0 osd
type 1 host
type 2 pool

# buckets
host host1 {
     id -1
     alg straw
     item osd.0 weight 1.000
     item osd.1 weight 1.000
     item osd.2 weight 1.000
     item osd.3 weight 1.000
}

host host2 {
     id -2
     alg straw
     item osd.4 weight 1.000
     item osd.5 weight 1.000
     item osd.6 weight 1.000
     item osd.7 weight 1.000
}

pool default {
     id -4
     alg straw
     item host1 weight 4.000
     item host2 weight 4.000
}

# rules
rule data {
     ruleset 0
     type replicated
     min_size 1
     max_size 10
     step take default
     step chooseleaf firstn 0 type host
     step emit
}

この構成の host2 側に 1 台 OSD を足してみる。 同時に pool バケットの重み付けを host1 : host2 = 4 : 5 に変更する。

# devices
device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3
device 4 osd.4
device 5 osd.5
device 6 osd.6
device 7 osd.7
device 8 osd.8

# types
type 0 osd
type 1 host
type 2 pool

# buckets
host host1 {
     id -1
     alg straw
     item osd.0 weight 1.000
     item osd.1 weight 1.000
     item osd.2 weight 1.000
     item osd.3 weight 1.000
}

host host2 {
     id -2
     alg straw
     item osd.4 weight 1.000
     item osd.5 weight 1.000
     item osd.6 weight 1.000
     item osd.7 weight 1.000
     item osd.8 weight 1.000
}

pool default {
     id -4
     alg straw
     item host1 weight 4.000
     item host2 weight 5.000 # 4.000 
}

# rules
rule data {
     ruleset 0
     type replicated
     min_size 1
     max_size 10
     step take default
     step chooseleaf firstn 0 type host
     step emit
}

再配置に伴い内部のオブジェクトの移動が発生する。 下の表は 100,000 個のオブジェクトを1番目の crush map と2番目の crush map に配置した時に、移動がどのように生じるかを示している。 最終的には全ての OSD がほぼ同数のオブジェクトが配置され、均等化が出来ていることが分かる。

ただし単階層の straw bucket は無駄な再配置が一切起きない理想的な配置が出来ていたが、2階層にすることによってまず host1 と host2 の間でオブジェクトの配置が決まり、その後に host1 と host2 のそれぞれで OSD への配置が決まる。 このため新規に追加した OSD8 に他の OSD からのオブジェクトが移動してくるのみならず、host1 内の OSD0 〜 OSD3 のオブジェクトが host2 内の既存の OSD4 〜 OSD7 に移動するという現象が起きてしまっている。 表中に緑色の文字で記した箇所が、無駄な再配置によるオブジェクトの流入である。 このような無駄な再配置は osd4 〜 osd7 の IN が合計 4,433 個だけ起きている。 osd0 〜 osd3 の OUT の合計が 5,541 個であるが、host1 から新規の osd8 へ移動した理想的な再配置分は 1,108 個だけとなる。

それでも osd0 〜 osd3 内のオブジェクトが別の osd0 〜 osd3 内に移動したり、osd4 〜 osd7 内のオブジェクトが別の osd4 〜 osd7 内に再配置されるといった、一つのバケット内での無駄再配置は発生してない。