Skip to main content

ログ取得ツール

Category: GNU/Linux

splice

Linuxにsplice/tee/vmspliceというシステムコールができていたことに最近気がついた。入ったのは最近というわけではなくて、2.6.17とかの頃ですね。

実際これらは良いものなのかどうか。パイプを介してどんなファイルディスクリプタにもデータを飛ばせるのでsendfileよりは使いでがあるように思う。

これらを使うとしたら、、、

  • sendfileの代わり
  • readやwriteの高速化
  • (ファイルやディスクの)コピーの高速化

くらいか。

sendfileの代わりとしてはまあ、インタフェースがちょっと変わるくらいですね。ただソケットに直接投げられないので、そのぶん面倒になり、sendfileよりも高速になるとはあまり思えないな。

readやwriteについては、コピーを使わずにバッファキャッシュがそのままユーザに見えるというイメージかな。速度的には普通、メモリの速度はI/Oと比べると圧倒的に速いので、あまり高速になるとは思えないな。やはり高速ネットワーク向けか、SSD系のデバイスがもっと高速になれば使われるかもしれない。広く(?)使われてきたO_DIRECTの代替になってくる可能性はある。

Fedoraのyum-prestoやるやる詐欺(?)終了

確かFedora 8あたりから毎回毎回presto(yumのdeltarpm対応)をやるやると言っておきながら(←誰が?)、prestoプラグインはインストールできるものの、updatesリポジトリを正しく構築してくれていなかったがために差分rpmを使えずにhttps://fedorahosted.org/presto/のあたりで提供されるリポジトリを使わざるを得なかった。ユーザは正当性がどう担保されているのか不安に思いながら使っていた(たぶんdeltarpmから普通のrpmにした後で電子署名を確認してたんで改竄については大丈夫だったと思う)。

しかし、今回Fedora 11でついに標準のリポジトリがprestoに対応した。ミラーサイトにも行き渡っている。ついに、2年越しで約束(?)が果たされたかなと。非常にめでたい話だが、ここまで来るのがちょっと長すぎか。

しかも、やはり欠陥が。デフォルトでyum-prestoパッケージがインストールされていないため、差分更新を使うユーザの絶対数は少ないままだ。いきなりopenjdkやevolution、KDEといった大物のアップデートなんかも出ているので、最初にやるのは

yum infoが遅すぎる

ローカルのDBにある情報を表示するだけのyum infoコマンド。やることは単純なのに、遅すぎる。

例えば、以下のようなスクリプトならだいぶ高速に表示できるけど、どうかな。

#! /bin/sh

format_x(){
  nm=$(basename $(dirname $1))
  awk -F\| 'BEGIN{RS="bobobobobobobobo";}{
  print "Name    :", $3;
  print "Arch    :", $4;
  print "Version :", $5;
  print "Release :", $6;
  print "Size    :", $21"(pkg)", $22"(ins)", $23"(arc)";
  print "License :", $13;
  print "Repo    :", "'$nm'";
  print "Summary :", $8;
  print "Description:";
  print $9, "\n";
}'
}

for name; do
  for i in /var/cache/yum/*/primary.xml.gz.sqlite /var/cache/yum/*/primary.sqlite ; do
    [ -f "$i" ] || continue
    sqlite3 $i "select * from packages where name LIKE '$name'" | format_x $i
  done
done

自分のところではyuminfo.shという名前で呼び出せるようにしてあります。

Apacheからlighttpdに乗り換えたらCPU使用率が…

Apache+PHPからlighttpd+fastcgi+php-cgiに乗り換えてみた。別に問題があったわけではないが、気分的な問題。

しかしCentOS5でrpmforgeから

## yum install lighttpd lighttpd-fastcgi

で、普通に設定すると以下のようになる(デフォルトの設定ファイルのコメントを外すとこうなる)。

fastcgi.server  = ( ".php" =>
                        ( "localhost" =>
                          (
                            "socket" => "/var/run/lighttpd/php-fastcgi.socket",
                            "bin-path" => "/usr/bin/php-cgi"
                          )
                        )
                      )

これで動くことは動くが、CPU使用率が尋常でなくなってしまった。userとsysが半々で、合計するとほぼ100%。毎秒約60プロセスが生成され、そして終了していた。試しにいくつかのphp-cgiプロセスにstraceでattachしてみると、あるプロセスはaccept()待ちという健全な状態だが、他のいくつかのプロセスはwait()とclone()を大量に繰り返していた。php-cgiが増殖しすぎて消され、消されたから増殖して…という動作を繰り返しているかのような挙動。

以下のmuninグラフのApacheとlighttpdの間にあるuserとsysが肥大しているのが、問題の時間帯。赤いniceプロセスはWCG(World Community Grid)のBOINCクライアントによるものです。

XCacheとMySQLのquery cacheの効果

先日19日に入れたXCacheとMySQLのquery cacheですが、キャッシュヒット時とミス時のペナルティとか、そういう値は良く分からないのですが、統計値を見る限りは効果がすごいですね。今のところ不具合もないです。

MySQLのqueryの統計を見ると、下図(muninのグラフです)を見る通り、ほとんどがキャッシュヒットになりました。右端の紫がキャッシュヒットで、有効にした途端にselectのクエリ数が激減し、キャッシュヒットで返せるようになっています。値が増えているのは、理由がよくわからない。アクセスが増えたわけではないです。

localhost-mysql_queries-month

設定はmy.cnfの以下を[mysqld]セクションに記述してmysqldをrestartするだけ。簡単ですね。なんでデフォルトで有効じゃないんだろう…

query_cache_limit=1M
query_cache_min_res_unit=4k
query_cache_size=24M
query_cache_type=1

次、XCache。これも統計を見るとコードはほぼ100%、データも85%程度がキャッシュヒットです。うちではブログくらいにしか使っていないので、このサイズで済んでます。

zshはFedora8でやっと4.3系に

zshを愛用している皆さん、Fedora7のzshは4.2.6なのでUTF-8での日本語を含むコマンド行の編集に不自由していましたが、Fedora8は(まだtest2しか出てませんが)どうやら4.3系になるので特に困ることなく普通に編集できます。 Fedora7で同様の環境を得るには、やはりおなじみとなったこの方法があります。

# yum install libcap-devel ncurses-devel
# yum install --enablerepo=development texi2html
# yumdownloader --enablerepo=development --source zsh
# rpmbuild --rebuild zsh-4.3.4-3.fc8.src.rpm
# rpm -Uvh /path/to/zsh-4.3.4-3.fc8.src.rpm

その他の設定は必要ないようであります。

powertop

powertop(linuxpowertop.org)というのがあると聞いたので、自宅のノートPCで試してみた。 彼が示唆するには、まずAC97(サウンド関連)のドライバのオプションでpower_saveのオプションを有効にせよ、と。有効にした。

# /etc/modprobe.conf
options snd_ac97_codec power_save=1

そしてカーネルのオプションでCONFIG_USB_SUSPEND、CONFIG_TIMER_STATS、CONFIG_NO_HZを有効にせよ、と。CONFIG_USB_SUSPENDは「n」になっていて、サスペンドに失敗するのはこのせいだと思っていたこともあり、がんばってやってみた。がんばったと言ってもNO_HZなんかは新しめのカーネルでしか使えない(Fedora Core6なのです)。 というわけで、こういうことをしてしまった。

# yumdownloader --enablerepo=development kernel
# sudo rpm -ivh kernel-2.6.22-0.12.rc7.git4.fc8.i686.rpm --nodeps

/boot/config-2.6.22-0.12.rc7.git4.fc8を確認するとUSB_SUSPENDもTIMER_STATSもNO_HZも有効だった。Fedora8では省電力を目玉にするつもりかな?? とにかく起動してみるといきなりpanicするので、そのときの示唆にしたがってカーネルの起動オプションに「irqpoll」を加えたら無事に上がる。 powertopはもうgnome-power-managerにしか文句を言わない。タイマ割り込みも確かに半分以下に減っている。HDDが/dev/hdaから/dev/sdaになった。サスペンドも何度かやってみたが問題なさそう。だいぶ快適になった…と言えるかな?? ところで最近のmkinitrdは最初からNFS rootに対応しているみたいですね。そのためのコードが入ってました。

XEmacsのxft化

Xのフォントをいい加減に管理していたせいか、XEmacsのフォントが狂ってしまった。使い慣れたXEmacsは捨てられないし、Xのフォントの管理も面倒になってしまった。fontconfigにしてほしいと思って調べてみたら、対応しているようだ。 少なくともFC6では以下のようにすればxft対応のXEmacsができる。

# yumdownloader --enablerepo=extras-source --source xemacs
# rpmbuild --rebuild xemacs-21.5.28-2.fc6.src.rpm --with xft --with mule \
    --define "dist .xft"
# rpm -Uvh (rpmdir)/RPMS/i686/xemacs{,-common}-21.5.28-2.xft.i686.rpm

必要なdevelパッケージがrpmbuild時に示されるのでそれらもこの機会にインストールする。 これで快適になった。フォントはデフォルトだとMonospace-12(?)になるみたい。メニューバーは化けてしまった。LANG=Cにするとメニューバーは化けなくなる(英語になるので)が、デフォルトのフォントがプロポーショナルになってしまう(このフォントはテキストエディタとしては厳しいかな)。 FC6のMonospaceもあまり好きではない(私の名字の字のバランスがすごくやばい)のだが、set-face-fontで変更できるみたいな感じ。 メニューは化けまくり なるほど。

Fedora7test2のインストーラCDのrescueモードでresize2fsを使ってshrink

インストール後に空き容量を作りたい場合に便利。snapshotボリュームを作るとか、後から複数のOSを入れるとか、いろんな用途に使えます。ブート後に/を縮めようとすると蹴られるのでrescueからやる必要がある。 まずメニューからrescueを選択、englishのまま、networkはオフ、ディスクのマウントはskipするように選択していく。read-onlyでマウントすると外せなくなるみたいで、ダメでした。Fedora7test2のDVDでやってますがFC6とか他のCDでもできると思います。LVMとresize2fsが入ってれば問題ないはず。 コマンドラインから、最初にlvmを有効にしてデバイスを作る。これ重要。

# lvm lvchange -a y /dev/VolGroup00

fsckをかけ、ext2のshrink、LVMのshrink。ここでは15GBに縮めてみます。

# e2fsck -f /dev/VolGroup00/LogVol00
# resize2fs /dev/VolGroup00/LogVol00 15G
# lvm lvreduce -L 15G /dev/VolGroup00/LogVol00
# resize2fs /dev//VolGroup00/LogVol00

あとはリブートすれば/の容量が減って空き領域が作られてます。空いたところにボリュームを作れます。snapshotを作ってそちらをrootにしておけば(grub.confの変更+snapshot側の/etc/fstabの修正)、いろいろやって後で変更を捨てて戻すのも思いのまま。sandboxみたいに使えますよ。もちろんLVMのsnapshotは原理上copy on writeが発生するので動作は遅くなりますし、Fedora7test2のカーネルだと妙なこと(recursive lockが検出される)になりますけど(笑)。

odttfはほとんどttf

ひとつ前の続き。 xpsに入っているバイナリファイルの内、odttfはほとんどttfでした。jhdでダンプするとすぐに特徴的なttfのテーブルが見えまして、少し書き換えるとttfとして使えます。ただしそのxpsに必要な文字だけしか入っていません(当然ですが)。ヘッダの長さが44バイトに変わっていて44バイトの中身はよくわかりませんが、ttfに変換するスクリプトをgitのリポジトリに入れておきました。

# cg-clone /xps.git/
# cd xps
# python odttf.py xxxx.odttf ...

のようにしてみると、odttfがttfに変換されます。次はこれを利用してttfを作り、XPSの表示に生かすことになるわけですが、それはまたいずれ。