Home

技術系のメモと日々の雑感

readahead_early についての覚え書き

この前、CentOS 5 で不要なサービスを削っているときに、ふと readahead_early のことが気になったので調べてみた。
プログラムの起動速度を上げるために、ページキャッシュ上に先読みしておくものといった程度の認識しかなかったんでね。
まず、/etc/rc.d/init.d/readahead_early を覗いてみると、スクリプトの最初の方でメモリが 384MB 以上積んであるかチェックしていた。
そうだったのか・・・。
自分の周りではいまだに 256MB しか積んでないマシンが多いので、有効にしててもほとんど意味がなかったわけだ。
もちろん、チェックしてる部分をコメントアウトしてやれば通すこともできるけど、デフォルトで /etc/readahead.d/default.early に書かれてるファイルを読むのにはこれぐらい積んでないと意味がないってことなんだろうな。
軽くショックを受けつつ /etc/rc3.d を見ると、S04readahead_early で設定されていて、ブートの最初の方で走るようになっているので、マシンの起動時間を短縮するのにも利用されていると思っていたのは正しいようだ。
となると、これが有効な場合と無効な場合でどれぐらい差が出るのか知りたくなるよね。
なのでついでに調べてみた。
使ったのはメモリが 2GB の Core 2 Duo マシンで、GRUB のメニューで Enter を押してからログインプロンプトが表示されるまでの時間を計ってみたのだが、有効にしても無効にしても26秒ぐらいでほとんど変わらなかった。
ちょっと期待外れ。
このマシンでは最低限のサービスしか立ち上げてないので、色々と動かしているマシンだったら結果が違うのかもしれないけど。
ついでに、free の結果も書いておくと、無効のときが

             total     used     free   shared  buffers   cached
Mem:       2075312    52860  2022452        0     6976    28332
-/+ buffers/cache:    17552  2057760
Swap:       522104        0   522104

で、有効にしたら

             total     used     free   shared  buffers   cached
Mem:       2075312   170976  1904336        0    19840   133328
-/+ buffers/cache:    17808  2057504
Swap:       522104        0   522104

といったところ。
cached の値が 100MB ぐらい増える程度なので、まったく気にする必要はないね。
あともうひとつ、readahead_early はデーモンじゃないので、有効にしていてもブート時に1回走るだけってことも覚えておこう。
これで次から readahead_early を使うか決めるときに迷わずに済みそうだ。
ん?
readahead_later を忘れてるって?
/etc/readahead.d/default.later を見ると、ほとんど X に関するものばかりだから、滅多に X を使わない私には必要ないんだよね。
メモリをたっぷり積んだマシンで X をゴリゴリ使ってる人は有効にしておいた方が幸せになれるんじゃないかな。

時々役に立つ iptab

iptables を叩くときに ipt[Tab] で補完しようとして気づくというのが定番らしいけど、自分もこのパターンで iptab に出会ってしまった。
CentOS だと perl-Net-IP パッケージをインストールしていると使えるコマンドだ。
実行すると

+----------------------------------------------+
| addrs   bits   pref   class  mask            |
+----------------------------------------------+
|     1      0    /32          255.255.255.255 |
|     2      1    /31          255.255.255.254 |
|     4      2    /30          255.255.255.252 |
|     8      3    /29          255.255.255.248 |
|    16      4    /28          255.255.255.240 |
|    32      5    /27          255.255.255.224 |
|    64      6    /26          255.255.255.192 |
|   128      7    /25          255.255.255.128 |
|   256      8    /24      1C  255.255.255.0   |
※以下略

という風に表示してくれるので、サブネットマスクやプレフィックスを調べるのにとても便利。
ただ、iptables の設定をしているときはやっぱり邪魔だね。
かといってパッケージごと削除してしまうのもアレだし。
で、こういうときに私がよくやるのはコマンドの頭にアンダーバーを付けるという手だ。
いわゆる自分ルールってやつだ。
この方法だと、万が一コマンド名を忘れてもアンダーバーでタブ補完すれば済むからね。
今回も _iptab にリネームして平和になったとさ。
めでたしめでたし。
まぁ、あまり人に勧められる方法じゃないけど・・・。

Domain-U 起動せず(続き)

この前のエントリの後日談。
Domain-0 のマシンを再インストールした後、バックアップしておいた Domain-U のイメージから起動しようとしたら

WARNING:root:Unknown directive acpi

こっちのメッセージはそのままで、さらに

Error: Device 0 (vif) could not be connected. Could not find bridge device xenbr0

というエラーまで出て起動してくれなかった。
もしやこれは泥沼パターンか・・・?
と、テンションが下がりつつ、再インストール前のを流用していた Domain-U の設定ファイルの

vif = [ 'mac=XX:XX:XX:XX:XX:XX, bridge=xenbr0', ]

の行の xenbr0 を xenbr1 に変更したら無事立ち上がってくれた。
助かった・・・。
実はこのマシン、eth0 側は故障していて使ってないのだ。
あれ?
だったら再インストールする前から xenbr1 に設定されててもいいはずなんだけどな。
まぁ、いいか。
例によって結果オーライということで。
で、さらに後日談だけど、Domain-U の中で作業していたら、grub.conf の kernel 行に書かないといけない acpi=off が変なところに書かれているのに気づいて、これを消したら最初のワーニングも出なくなった。
ようやく完全復活。
やっぱり複数のトラブルが重なると原因を調べるのが難しくなるねぇ。