詳解システムパフォーマンス 8章ファイルシステム メモ

今回も章末の練習問題をみながら、みんなで議論をしていた。

アプリケーションの I/O パフォーマンスを解析するときには、ファイルシステムのパフォーマ ンスの方がディスクパフォーマンスよりも大きな問題になる。ファイルシステムは、アプリケー ションがディスクレベル(またはリモートシステムレベル)のレイテンシの影響を被らないように するために、キャッシング、バッファリング、非同期 I/O を使っている。それにもかかわらず、 パフォーマンス分析やツールセットは、伝統的にディスクパフォーマンスに重点を置いてきた。

Brendan Gregg,西脇靖紘,長尾高弘「詳解システム・パフォーマンス」, オライリージャパン p.337

この章では、アプリケーションからディスクまでのスタックのうち、ファイルシステムの層でなにが起きているかを大まかなモデルにしたがって説明してくれている。この章まで読むと、例えば read(2) vs mmap(2) の迷信 に書かれた内容がだいたい理解できるようになる。

議論していた内容は、主に以下のような内容。

メモ

チューニングの節で、前回の 詳解システムパフォーマンス 7章「メモリ」メモ - ゆううきメモ でも書いたposix_fadvise(2)の話があり、以下のようにcatコマンドをstraceすると、catのファイルアクセスパターンはシーケンシャルであることから、POSIX_FADV_SEQUENTIALにより先読みページ数をデフォルトの2倍にすることで最適化されているといった話をした。

|| [y_uuki@yuuki~]$ sudo strace cat /var/log/messages 2>&1 | grep -5 fadvise brk(0) = 0xc14000 brk(0xc35000) = 0xc35000 fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 open("/var/log/messages", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0640, st_size=10088, ...}) = 0 fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc24d24b000 read(3, "Oct 29 06:25:11 yuuki rsysl"..., 131072) = 10088 ||<

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

詳解システムパフォーマンス 7章「メモリ」メモ

しばらく輪読を休んでたけど、再開した。第7章「メモリ」。 章末の練習問題を見ながら、みんなで議論していた。

  • メモリのページとはなにか
    • OSとCPUがメモリを管理する単位
  • 仮想メモリとは何か
    • 無限のメモリの抽象
    • メインメモリとスワップ領域を抽象化している
    • 他に抽象化している組み合わせはあるか? 分散OSの分野で、分散システム上の各ノードのメモリを一つの仮想メモリとして扱うみたいな研究はあるかも?
  • Linuxの用語では、ページングとスワッピングの違いは何か
  • スワップバイススワップファイルの違い?
    • mkswapでスワップ領域をブロックデバイスかファイルか選べる
    • ファイルのほうがダンプしやすそう。オーバヘッドも大きそう。
  • スワップ領域のサイズはいくつに設定する?
    • Chapter 7. Swap Space
    • 定期的にメモリをダンプして再開
    • live migration プロセスの状態を保存して移動 コンテナだとこういうの CRIU
  • デマンドページングの目的は何か
    • 仮想 => 物理のマッピング作成の遅延評価
    • これがないとCoWができない
  • メモリの使用率と飽和を説明しなさい
    • 使用率: ファイルシステムキャッシュは再利用できる
    • 飽和: 図7-6 メモリの解放 で上から順に戦略が使われる
    • リーピングとか実践で使ったことない
  • MMUとTLBの目的は何か
    • MMU: 仮想アドレスから物理アドレスへの変換
    • L1だけ仮想アドレス参照なのはなぜか?
      • L2以降はあとでつけたしたから?
      • L1には命令キャッシュが入ってるから?
      • 単に仮想アドレスで参照すれば速いため?
    • TLBは仮想アドレスから物理アドレスへの変換のキャッシュ
    • スレッドあたりのエントリ数が決められている => HyperThreading コンテキストスイッチ発生してもキャッシュが消えないメリットある?
  • ページアウトデーモンの役割は何か
    • ページキャッシュの掃除 フリーリストにいれる。kswapd
    • フリーリストはどこ?=> カーネル内。 図7-13
  • OOMキラーの役割は何か
  • 無名ページングとはなにか。ファイルシステムページングよりもこの種のページングを分析するほうが重要なのはなぜか
    • プロセスのプライベートデータのページング。ヒープ領域やスタック領域など。
    • ファイルシステムキャッシュはOSが追い出せる。プロセスのプライベートデータを解放できるのはアプリケーションのみ。
  • フリーメモリが不足したときに、メモリを広げるためにカーネルが取る手段を説明しなさい
    • ページキャッシュ追い出し => スワッピング => リーピング => OOMキラー
    • MyISAMは全部ページキャッシュ バッファプールとかない
    • 最近のLucenemmapでインデックスファイルをのせる。昔はJVMヒープ
  • スラブベースのアロケーションのパフォーマンス上の利点

最後に、Mackerelにおける時系列データベースの性能改善 / Performance Improvement of TSDB in Mackerel // Speaker Deck でのディスクスラッシング問題について話をした。 激しい random writeにより、ページイン数が爆発し、メモリを飽和させるので、ページアウト数もまた爆発する。ページキャッシュがなくなるため、read時にキャッシュミスし、read I/Oが増加する現象。 posxix_fadvise(2)のPOSIX_FADV_RANDOMにより、write時のページインの先読みを切ることができる。これにより、ページイン数を減らすことができる。 posxix_fadvise(2)のパッチをあてた前後で、/proc/meminfoのActive(file)とInactive(file)に変化があった。バッチ前は、Inactiveが多く、パッチ後はActiveが増えた。ActiveとInactiveの定義は以下の通り。

Active: Memory that has been used more recently and usually not reclaimed unless absolutely necessary. Inactive: Memory which has been less recently used. It is more eligible to be reclaimed for other purposes

https://www.kernel.org/doc/Documentation/filesystems/proc.txt

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

書籍「Mackerel サーバ監視[実践]入門」執筆成功

執筆成功と言いつつ、自分は元となった連載記事をいくつか書いただけで、書籍化にあたってはプロフィールを書く以外のことは何もしていません。気づいたら、書籍を初執筆していたことになりました。

書籍「Mackerel サーバ監視[実践]入門」を執筆しました | おそらくはそれさえも平凡な日々

僕のおすすめは、9章 付録です。Mackerelのアーキテクチャから、ペパボさんとガイアックスさんの事例といった、内部システムの話とお客様のおもしろい応用事例が載っています。よくみると、はてなのインフラ環境―自作サーバから自作コンテナまでという節で、drootが紹介されていたりします。

書籍にできるレベルまでまとめることで、社内のエンジニアがMackerelのキャッチアップをするのにも非常に良質な資料となっています。

自分が書いた連載記事

Go言語をほぼ毎日書いている話 (序)

はてなの京都オフィスで開催された そうだ Go、京都。 - connpass にて、「Go言語をほぼ毎日書いている話(序)」というふわっとした話をしました。いわゆる Write Code Every Dayという活動ですね。 タイトルに(序)と付けているのは、書き始めてまだ5ヶ月程度だからです。

ちなみにこのGWでは、Rustを毎日書いていて、すでにタイトル詐欺感がありますね。

スライド

スライドを以下に貼っておきます。

speakerdeck.com

同僚の id:niwatako さんの超速記により、ツイートはるだけで内容紹介できて贅沢。

質問

発表後、以下のような質問をいただいた。

感想

  • 同僚の id:t_kyt くんと id:aereal さんと発表したのだけど、示し合わせもせず、それぞれ微妙にリンクした話をしていて、仲間じゃん感があった。
  • plan9userさんのFUSEの話がおもしろかった。FUSEの仕組みを初めて知った。plan9そのもののアーキテクチャとして興味がある。
  • 京都というか地方の勉強会は、出席率も高く、1つ1つの勉強会を大事にしている感がよい。LT登壇も多く、質問もいろいろでて、ツイートも活発なよい勉強会だった。

mkr + peco + tmux + ssh

Mackerel Meetup #10 Tokyo のLT枠で「mkr + peco + tmux + ssh」というタイトルで話をしました。当日の発表スライドを以下に貼っておきます。

speakerdeck.com

話の内容は、tmux + ssh + Mackerel API を組み合わせたとにかくモダンなサーバオペレーション - ゆううきブログ の続きになります。このエントリにあるように普段から

$ tssh $(roles bookmark proxy) # サービス名: bookmark, ロール名: proxy

のようなコマンドを叩いて、指定したロール配下のホストに、tmuxのpaneを使って同時にsshログインしています。

しかし、ロールの数が増えてくると、そもそもロールの名前を正確に覚えていないということがしょっちゅう起きます。 そこで、peco*1 を挟んでやることで、ロール名の候補に対して絞り込みをかけて、ロールを決定したのちに上記コマンドを実行するということができます。

bindkey '^w' peco-mkr-roles
function peco-mkr-roles() {
  local selected_role=$(mkr services | jq -rM '[.[] | .name as $name | .roles // [] | map("\($name) \(.)")] | flatten | .[]' | peco)
  if [ -n "${selected_role}" ]; then
     local BUFFER="tssh \`roles "${selected_role}"\`"
     // zle accept-line // 好みでコメントアウトを外す
  fi
  zle clear-screen
}
zle -N peco-mkr-roles

このようにMackerelを用いて、単に監視をするだけでなく、APIを介してさまざまなツールを組み合わせ、プログラマブルにインフラストラクチャを制御することができます。

参考リンク

追記

github.com

マージされたので、mkrを更新すると上記のfunctionが動きます。

*1:pecoは雑な表現をすると、インクリメンタルにgrepできるツールです。