2019-08-21 firefox などの巨大なものをビルドしてると、 システム全体が不当に遅くなる。Linux の IO スケジューリングアホすぎでは? ということで、いろいろ試した。 --- プロックデバイスの IO のスケジューリングは、 /sys/block/*/queue/scheduler で設定できるらしい。 スケジューリングって実行中に変更できるのか・・・。 というか、複数用意されてるんですね。 最適なものがデフォルトで選択されているものと思ってまともに考えていなかった。 選択されていたのは mq-deadline と言うやつで、他に none が見えた。 この2択ならdeadlineが最適っぽいが、名前からしてまともではなさそう。 パラメータを見てみると、読み出しのdeadlineが500, 書き込みは5000らしい。 遅そう。(根拠なし) bfq というのが早いと聞いて、「野良ビルド必要かな?」とか言いながら カーネルのドキュメントを参照してみた。 Documentation/block/bfq-iosched.rst によれば "a tree of source files is being compiled" 等がバックグラウンドで動いている PCに有効らしい。ほしかったのはまさにこれである。 なんでデフォルトでこれじゃないの? 今どきのPCのCPU性能(不必要に高い)とハードディスクの性能(ゴミ)を考えれば、 計算負荷の増加を犠牲にIOスケジューリングを賢くするのは当然の選択である。 なんでデフォルトでこれじゃないの? と、疑問は置いておいて、すごく使いたくなったので有効化方法を検索。 bfqというモジュールがあることに気づいてロードしてみたら、 /sys/block/*/queue/scheduler の選択肢に bfq が現れてくれた。 カーネルモジュールって素敵! 野良ビルドは不要だった。 颯爽と `echo bfq | sudo tee scheduler`。 あとで udev も設定することにしよう。 --- さてこれで IO のスケジューラがまともになったはず。 勇んで firefox をビルド! しかし、いつもどおり遅くなる。いや、むしろいつもよりひどい。 よく考えたら、今はバックグラウンドで io の優先度を Idle に設定した プロセスが数十GBのファイルをちまちまダウンロード中である。 最近、優先度が Idle のプロセスがあると IO が劣悪になる説を 個人的に提唱していたので、これの終了まで待ってみた。 Idle が終了したらかなり軽くなった。 BFQ に変更する前との差はちゃんとある気がする。(偽薬効果) --- さて、それでもちょっと不満感がある。 最近これも気になっていた、vim を使っているとたまに 変にカクつく問題の解消を試みる。 こういうカクつき方はたいてい IO のせいである。 メモリ不足でもなければほぼ確実に、fsyncが悪さをしていると踏んで vim のソース内で fsync を検索。と、fsync オプションを発見。 なぜ最初にマニュアルを参照しないのか。 マニュアルによると、fsync オプションはオンにするとファイルの保存時に fsync しなくなる。 しかし、データのロスの危険が高くなる。(当然である) 手癖で `:w` を打つせいでリモート編集がはかどらないとき等に、 `:set nofsync` とするとストレスなく編集できるようになるわけだ。 しかし常用するのはちょっと怖い。`:w` したときに少し止まる程度は 許容範囲である。 目当てのオプションは `swapsync` という名前をしていた。 このオプションは、スワップファイルを fsync するかを決定する。 空文字列を設定すると sync しなくなり、何か書くと sync する。 スワップファイルは特に何も言わなくても勝手に書き出されるため、 編集中に何の前触れもなくカクつくのはこいつのせいであるとわかる。 マニュアルによれば、 > UNIX では fsync を呼ばずとも、システムがたまに勝手にファイルを書くから、 > 無効にしてもあまり害はない (意訳) とのこと。UNIX 以外のシステムでも大抵はそうだと思うんだけど。。。 このオプションの初期値は "fsync" であり、勝手に fsync されるため データがディスクに書き出されるまで処理が止まるのである。 と、言うことで、`/etc/vim/vimrc` に `set fsync=` を追記した。 これでかなり快適になった。(気がする) ところでこのオプション、 マニュアルには * 空文字列だと何もしない * "sync" を設定すると sync する * それ以外を設定すると fsync する と書いてあるように読めるが、ソースを読んだ感じだと * 空文字列だと何もしない * "fsync" を設定すると fsync する * それ以外を設定すると sync する が正しそうに見える。 空文字列か "sync", "fsync" 以外に設定しなければ無害だが、 そして結局どのみちほとんど無害だが、気をつけよう。 --- 今日は IO のパフォーマンスのために以上のいろいろをやった。 環境は良くなった気がする。だぶん。 それでもやっぱり fsync のタイミングで変にカクつくような挙動が 少し残っている。なんだか X が止まっているときもある気がする。 本当に fsync が悪いのかは謎だが、私は fsync のせいだと考えている。 最近は SSD が普及したためか、HDD の低速な IO を考慮しない アプリケーションが増えているような印象がある。 あるいはカーネルの IO スケジューラがアホになったか、 個人的に最近 (1年くらい) 使い始めた LVM がべらぼうに遅いか。 そんな印象がある。 私は、モバイルデバイスには SSD の利用は良いと思うが、 デスクトップにまで SSD を使いたいとはあまり思えず、 「SSD は HDD より安くなったら買う」と言い続けてきた。 SSD は確かに高速だし、HDD はひどくレスポンスが悪いが、 しかし、HDD も補助記憶装置としては十分な性能があると思っている。 HDD 上の動画を再生していてロードが間に合わないなどということは 殆ど無いし、どんなサーバが相手でも、ファイルのダウンロード速度の ボトルネックが HDD になったことは我が家では(残念ながら)無い。 そしてこれより高速なディスクアクセスは、 十分量のメインメモリと優秀な IO スケジューラが有れば不要なはずである。 スループットが確保できればあとはメモリによるキャッシュでどうにかなるはずだ。 ドライブのアイドル時間を不必要に長くするために、 わざわざ高価な SSD を買いたくないのである。 しかし最近心が揺れている。 低速な IO を考慮しないアプリケーションが増えている (推定) ために、 不必要に高性能な補助記憶装置が必要なものになりつつあるためである。 2019-09-05 昨日ニコニコで見た動画によれば、SSDは基本的人権らしい。 なるほど。たしかにHDDユーザへの開発者からの嫌がらせはそういうわけか。 私は人間ではなかった。 ところでこの動画、言ってることがかなり怪しい。