「OS Girls 2」を読んだ

技術書典7において販売されていた本の読書感想文です。BOOTHで電子版を販売中です。

hikalium.booth.pm

「OS GIrls」の続編です。前作の読書感想文はこちら。

satoru-takeuchi.hatenablog.com

わりと真面目な感想文は前回書いているし今回も同様の感想なので省略。今回はその他の感想を主に書きます。

前回同様、相変わらずかっ飛ばしていて、いい意味での突っ込みみどころがたくさんあります。ネタをそのまま書いてしまうと全然面白くなくなるで私の突っ込み部分だけを書いておきます。

  • 「この事象からOSの話につなげるのか…」
  • 「これは早口で自分の言いたいことをまくしたてるタイプのオタク」
  • 「まさか、まさか、この流れ…初級者の前でこの技術に言及するつもりでは………でししたね、ですよね、この子ならそういうこと言っちゃうよね」

続編に期待です。気長に待ってます。

「OpenCVデバッグ探偵記」を読んだ

技術書典7で著者の@tomoaki_teshimaさんに献本いただいた本です。

本書はOpenCVを題材にバグを見つけてからデバッグ、そのあとOpenCVのupstreamに還元するための技術について解説してくれています。このデバッグをする流れを筆者は探偵による調査に見立てています*1。経験豊富なソフトウェア技術者であり、かつ、OpenCVというOSSに幾多の貢献をしてきた筆者による迫力満点なトラブルシューティングは見どころ一杯です。題材は特定のソフトウェアですが、あらゆるトラブルシューティングに通じる内容です。ひたすら解析が続くだけではなく、ときおり箸休めのための余談が入ったり、コラムが入ったりというのもうれしいところです。

本書はこちらから電子版を購入できるようです。わたしが以前書いた以下のOSSトラブルシュート記事を面白いと思うかたであれば本書もきっと気に入るでしょう。

qiita.com

ここで本書を読むのに必要な前提知識について述べておきます。主にC++やアセンブリ言語のソースをもとにした解説なので、これらの言語を知っているのが好ましいと思います。しかし、解説が丁寧なので流し読みするくらいであればなくても大丈夫だと思います。

脱線ですが、なぜ献本いただいたかというと、著者がわたしの過去の活動Ryzen SEGV Battleを気に入ってくれたからだそうです。書籍でも触れてくれています。ご興味のあるかたはごらんください。書籍化もされています。

最後になりますが、もう一度。とてもいい本でした、献本ありがとうございました。

*1:わたしを含め、このたとえは非常に的を射ているのでけっこう使う人が多いです

30分で論文流し読みシリーズ5「Replication Under Scalable Hashing: A Family of Algorithms for Scalable Decentralized Data Distribution」

Replication Under Scalable Hashing: A Family of Algorithms for Scalable Decentralized Data Distribution

↓の参考として挙げられているもの satoru-takeuchi.hatenablog.com

  • 実際の所要時間: 1時間半
  • 課題
    • 分散ストレージにおいてオブジェクトの配置情報を中央集権型でなくするには、かつては実際のデータ配置前にすべての配置位置を決めて、その後のディスク増減コストは大量のデータ移動が必要な高コストなものだった
  • 解決方法概要
    • RUSHというアルゴリズムセットを開発した*1
    • RUSHはディスクの追加削除も低コストでできる
  • 解決方法詳細
  • 効果
    • 図5~8あたりを参照
  • 感想
    • CRUSHの論文にRUSHには問題があるようなことが書かれていたが、たしかにこれだけだとけっこうつらそう。以下理由
      • あるオブジェクトのレプリカを同じラックに配置するようなtopology awareな配置ができない
      • ちょこちょこストレージを足していくとサブクラスタの数が増えて色々な処理が低速化しそう

*1:正確にはRushPは以前の論文に既に書かれている

30分で論文流し読みシリーズ4「CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data」

CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data

  • 実際の所要時間 1時間半
  • 課題
    • オブジェクトストレージにおいて、どのストレージデバイスにどのようにデータをを配置するかには様々な方法がある
    • 既存のものは巨大なメタデータ(およびそれを置くメタデータサーバ)が必要だったりストレージデバイスの故障や追加/削除によって大量のデータの移動が必要だったりと一長一短
    • RUSHという計算によってオブジェクトの配置場所を決めるいいかんじのアルゴリズムがあるが、あんまり効率がよくない
  • 解決方法概要
    • CRUSHと言うアルゴリズムを開発した
      • データを各ストレージデバイス疑似ランダムに配置できる
      • レプリカやイレージャコーディングも可能
      • ストレージデバイスの故障や追加/削除によるデータの再配置が少なくて済む
      • デバイスごとにweightも変えられる。たとえば大容量のストレージデバイスのweightを上げて小容量のものはweightを下げる、など
      • トポロジーを意識したデータ配置ができる。この構成のことをcrush mapと呼ぶ
      • crush mapに対して、あるオブジェクトのレプリカを同じノードに置かないとかいうルールが作れる。これをplacement ruleと呼ぶ
  • 解決方法詳細
    • 論文の中のAlgorithm 1、figure 1~4あたりを見てね!
    • 細かいところではinternal nodeに相当するbucketの種類が複数ある(uniform buckets, list buckets, tree buckets, straw buckets)
    • それぞれオブジェクトをストレージデバイスにmapする速度、デバイス追加/削除時の処理の効率が違う(table 2参照)
  • 効果
    • 様々な性能をbucketの種類ごとに、場合によってはそれに加えてRUSHのものと比較してある(figure 5~8)

感想 - Ceph(データ配置にCRUSHを使っている)の内部を知るには読んどかないとまずい - 魔法のようである。うまくやるものだ - RUSHの論文も読んでおかないとうまく解釈できないと思う

Cephとの比較 - Cephにおいては、いまではbucketは上記4つとはまた違うstraw2というのがデフォルトで使われている。もはや他のものをあえて使う必要はないだろう - placement ruleはCephにおいてはcrush ruleと呼ばれることが多い - オブジェクトは直接ストレージデバイス(正確にはOSD)にマップされるのではなく、Placement Groupというものにマップされる。同じplacement groupに属する全オブジェクトは、placement groupに対応するOSDにレプリカを配置する。たぶん組み合わせ数が死ぬほど増えるのを防ぐためにこうなってる

30分で論文流し読みシリーズ3: 「vScale: Automatic and Efficient Processor Scaling for SMP Virtual Machines」

vScale: Automatic and Efficient Processor Scaling for SMP Virtual Machines

  • 実際の所要時間 一時間半

  • 課題

    • vCPU数 > pCPU数のときにvCPUがスケジュールされないことによってロック待ちやI/O完了待ちが長くなってアプリの性能がすごく落ちることがある
    • VMの負荷に応じて動的にvCPU数を動作させるvCPU Baloonというものがあるが、LinuxのCPU online/offline機能を使うと数百ミリ秒オーダーで時間を食うので頻繁に使うのはつらい
  • 対象環境
    • hostがXen、guestがLinux。以下単にHypervisorをXen,guest OSをLinuxと表記する
  • 解決方法概要
    • VMの負荷に応じてvCPU数増減に相当する処理をLinuxに追加する。同、負荷に応じてVMに与えるCPU時間を増減させる処理をXenに追加する。
  • 効果
    • バックグラウンドで別の処理を動かしてvCPU数が2*pCPU数程度のマシン上でスレッド間同期処理が多かったりI/O頻度が高かったりする処理を動かすと性能が数十%上がった

  • 解決方法詳細

    • linuxに手を入れて、カーネルから見えるCPUにfreezeという状態を作る。これはofflineに似ているが、vCPUのスケジュール対象にせず、かつ、外部割り込みも上がってこないようにするだけで、onlineとofflineの間のような状態。これはカスタムカーネルこれは数マイクロ秒単位で終わる
    • 各VMにおいて、個々のvCPUが実際に使ったCPU時間を定期的に記録する。この値をもとにlinuxとXenの両方において次のようなvCPU online/offlineを模した処理をする
      • 実際に使ったCPU時間が少なければ、vCPUを所定の数だけfreezeする。それに加えてこの情報をXenに渡してVMに与えられるCPU時間のshareを小さくする*1
      • 上記値が多ければ、freeze状態のvCPUを所定の数だけunfreezeする。それに加えてこの情報をXenに渡して、VMに与えられるCPU時間のshareを大きくする
    • なぜlinux上のvCPUのfreeze/unfreezeだけでなくXenにおけるVMごとのshare値を変えているかというとから見ると、Xenからはlinuxのfreeze/unfreeze状態を直接観測できないから

  • 感想

    • KVM(あるいは今現在のXen)だとどうなるんだろう。手を入れなきゃいけないところが少なくなりそう。たとえばKVMだとlibvirtを使えばCPU shareはVM単位で与えられる
    • 図5においてlinux v3.14.15のunhotplug latency低すぎでは。何これ
    • バックグラウンドで動いているVMのデータも欲しい。もしかすると、あるVMをひいきして他のVMが割を食う仕組みになっているのかもしれない
    • CPU affinityが設定されている場合の対処方法がもやっとしててよくわからなかった

*1:変更を加えたバージョンのXenではshareはvCPUごとにあるが、vScaleにおいてはshareをguestごとの値に変更したらしい

プリンタ買いました

10年ぶりくらいにプリンタ買いました。紙で印刷することなんてそんなにないし、あってもコンビニでネットプリント使えばトータルコストでは安いと思ったので、あえて持たないようにしてました。

ところが実際は印刷が必要になる機会は頻度は確かにそれほど高くないものの、そのたびにコンビニ行く移動コストが高いこと、及び、大して行きたくもないのにコンビニに行くのが嫌になってきたことより購入に踏み切りました。金銭的な面では多分こちらのほうが高コストですが、それ以外の部分(上記の移動コストとストレス)を考えるとこっちのほうがよさそうです。今後に期待。

ところで最近のプリンタはすごいですね。一万五千円くらいのものを買ったのですが、操作は液晶タッチパネルだしスマホ連携はできるし、パソコンなくてもOKだし…と、ちょっと興奮してしまいました。

SNSとの接点を減らした その3

↓の続き

satoru-takeuchi.hatenablog.com

次は書き込み内容を改善してみようかと。ダジャレをメインにしてたまに真面目な技術の話とかをして、意識高めな警句のようなものとか皮肉とか愚痴っぽいのは減らしていこうかなと。後半部分はつい書いてしまった後に「偉そうなこととかつまんねえこと書いたな」と思つってしまって精神衛生上よくなかったのです。さらにこれによって書き込み量も減るのではないかと期待しています。

これもまあまあできるようになりました。ただし、ふとやってしまうことがあるので、道半ばです。

これ以外にもマイナスの感情を全面に押し出したtweet、とくに攻撃的なもの、が流れてきたときに自分が不快な気分になったりその感情に引きずられたりしやすいことがわかりました。これを避けるために、その発言、あるいは同じ人からのものが何度も続くようであればその人を積極的にミュートするようになりました。これはけっこう効いたらしく、感情が動くことが減りました。「自分ってけっこう繊細だったんだ」と感心してしまいました。