Home

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

Pentium シリーズと Core シリーズの BogoMips の違い

最近、Pentium4 3.2GHz のマシンと Core2 Duo T7200 2GHz のマシンを触ることがあって、ふと BogoMips がどれぐらい違うのか見てみたら、Pentium4 の方が値が大きいことに気がついた。
Core2 Duo T7200 2GHz の方は

# cat /proc/cpuinfo(processor:0の抜粋)
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
cpu MHz         : 1991.926
cache size      : 4096 KB
cpu cores       : 2
bogomips        : 3983.08

で、Pentium4 3.2GHz の方は

# cat /proc/cpuinfo(processor:0の抜粋)
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 3.20GHz
cpu MHz         : 3215.445
cache size      : 512 KB
cpu cores       : 1
bogomips        : 6432.89

と、数字の上では Pentium4 の方が速いことになってしまっている。
まさかと思って、両方のマシンに載せる予定だった Postfix(2.5.6)をコンパイルするときにかかった時間を比べてみたら、Pentium4 は 58 秒で、Core2 は 40 秒だった。
やっぱりね。
あ、そうか〜。
このエントリを書いてる途中で気づいたんだけど、Pentium4 って cpu cores は 1 なんだね。
Hyper-Threading で CPU を擬似的に 2 つに見せてるだけだもんな。
つまり、Pentium4 は 1 つ分の BogoMips だけを見ないといけなかったのだ。
Core2 みたいに「ちゃんとしたコア」を複数持ってる CPU は cpu cores が 2 以上になるから、これを掛けた値を見ればいいんだろうね。
結局自分の勘違いだった・・・。

CentOS の run-parts について

pflogsumm の設定をしていたときのこと。
昨日の分のログを解析させるために、daily でローテーションしている maillog.2 と maillog.1 を連結して pflogsumm に渡すスクリプトを /etc/cron.daily に置いた。
で、ここでひとつ疑問が。
pflogsumm と logrotate が同じタイミングで実行されたらマズくない?
どっちが先に実行されるかによって結果が違ってくるからね。
そこで、run-parts について調べてみると、このコマンドは元々は Debian で作られたものらしく、そっちは色々とオプションもあって、man ページも用意されていた。
ところが、CentOS(5.3)の方は簡単なシェルスクリプトで、オプションどころか man ページもない。
まぁ、単にディレクトリの中のプログラムをひとつひとつ実行していくだけだからシンプルに越したことはないんだけど、気になるのはプログラムを実行する順番だ。
Debian の方はファイル名の順に実行されることが man ページに書いてある。
一方、CentOS の方はスクリプトの中で

for i in $1/*[^~,] ; do
    ...
done

と書かれていて、bash のパス名展開に任せていた。
念のため bash の man ページを見たら、パス名展開は 「パターンにマッチするファイル名をアルファベット順にソートしたリストに置換する」 とのこと。
なるほど。
これで大丈夫なんだね。
意識してなかったけど、スクリプトを pflogsumm.cron という名前で作ったからうまくいったわけだ。
ひとつ勉強になった。

CentOS 5.3 のネットワークインストールでエラー

他のエントリでもちょっとだけ触れた話。
CentOS-5.3-i386-netinstall.iso を使ってネットワークインストールすると、Root Password 画面で OK した直後に次のようなエラーが表示されて止まってしまう。

XX:XX:XX CRITICAL: Traceback (most resent call first):
  File "/usr/lib/python2.4/subprocess.py", line 975, in _execute_child
    raise child_exception
  File "/usr/lib/python2.4/subprocess.py", line 542, in __init__
    errread, errwrite)
  File "/usr/lib/anaconda/iutil.py", line 488, in inVmware
    proc = subprocess.Popen(lspci, stdout = subprocess.PIPE)
  File "/usr/lib/anaconda/yuminstall.py", line 860, in doGroupSetup
    if iutil.inXen() or iutil.inVmware() or ¥
  File "/usr/lib/anaconda/yuminstall.py", line 942, in doRepoSetup
    self.doGroupSetup()
  File "/usr/lib/anaconda/backend.py", line 172, in doRepoSetup
    anaconda.backend.doRepoSetup(anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 201, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 124, in gotoNext
    self.moveStep()
  File "/usr/lib/anaconda/text.py", line 721, in run
    anaconda.dispath.gotoNext()
  File "/usr/bin/anaconda", line 1006, in ?
    anaconda.intf.run(anaconda)
OSError: [Errno 2] No such file or directory
XX:XX:XX INFO    : in run, screen = <snack.SnackScreen instance at 0xb7e3552c>

あ、何かの役に立つかもしれないのでエラーが出たときの画面のイメージも貼っておこう。
ここで OK を選んでもリセットされるので先に進めない。
あと、Save はクラッシュダンプのセーブで、Remote はクラッシュダンプを別のマシンに転送するためのものだった。
で、以前はあきらめて 5.2 をインストールしたんだけど、メッセージをメモしたついでに調べてみたら本家のフォーラムに情報があった。
Netinstall problem with 5.3 i386
メモリが 256MB だとエラーになるらしく、512MB まで増やしたらインストールが成功したとのこと。
そうだったのか〜。
家にあるほとんどのマシンは 256MB しか積んでないし、今回試した環境も VMware で 256MB しか割り当ててなかったよ。

yum-priorities でパッケージの衝突を回避

この前書いた通り、RPMforge を使うときは yum --enablerepo してるけど、公式パッケージとぶつかることがあるという注意書きを見てしまったので、やっぱり yum-priorities も入れておくことにした。

# yum install yum-priorities
# perl -i -pe 's/^enabled.*/enabled = 0¥npriority=99/' /etc/yum.repos.d/rpmforge.repo
# perl -i -pe '$flg=1 if(/¥[centosplus¥]/);
  print "priority=1¥n" if(/^gpgcheck=1/ && $flg==0);
  print "priority=10¥n" if(/^gpgcheck=1/ && $flg==1);' /etc/yum.repos.d/CentOS-Base.repo

RPMforge のリポジトリの優先度は最低の 99 にしておく。
enabled を 0 にしているのは個人的な好みだから、これを 1 にして yum-priorities にお任せしてしまうのもアリかと。
最後の妙なコマンドは、centosplus と contrib だけ priority=10 にして、それ以外に priority=1 を設定するためのもの。
見やすいように3行に分けてるけど、一応ワンライナーだ。
ファイルを毎回手で編集するのは面倒だと思って1つのコマンドで済ませようとしたら無理矢理になってしまった・・・。
まぁ、動くからいいか。

RPMforge と DAG の関係

すでに RPMforge は使っているんだけど、前からずっと気になっていることがひとつ。
DAG RPM との関係だ。
同じものと考えていいのかがはっきりしない。
区別してない人もいるし、まぁ、気にしなくても別に支障はないんだけどね。
スッキリしたかったので説明している文章を探してみたら、公式ページの FAQ

We merged our SPEC files in a common subversion repository to avoid duplicate work and work more closely together.

と書いてあった。
「重複する作業を避けて、より緊密に協力するために、共通の Subversion のリポジトリ内にある SPEC ファイルをマージした」といったところかな。
なるほど。
元は別のプロジェクトだったんだね。
ちなみに、wiki.centos.org の RPMforge のページには次のような注意書きが。

Beware that some packages are newer than the official CentOS version and you should not blindly install those packages.
Before you replace a CentOS package you should make sure that will not break anything important.

「パッケージによっては CentOS の公式のものより新しいことがあるので安易にインストールすべきではない。パッケージを入れ替える前に環境が壊れないことを確認すること。」

で、結果として yum-priorities の使用が勧められているわけか。
個人的には、必要になったときだけ yum --enablerepo=rpmforge するのが好みなのでこっちにしてるけど。
そういえば、CentOS 5.X の環境を作る度に毎回 RPMforge もインストールしているので、ここにもコマンドを書いておこう。

# rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
# rpm -ivh http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
# perl -i -pe 's/^enabled.*/enabled = 0/' /etc/yum.repos.d/rpmforge.repo

あ、3行だけだった・・・。