IO の直列化
2006-02-21


最近 ports で入れた、ソフトウェアが古くなってきたので徐々に入れ換えている。まあ、オプション等が互換がなくなって、動かないとびっくりすることがあるから徐々にやるわけだ。オプションの互換程度だったらいいのだが、ライブラリのバージョンが変わると動かなくなるものもあるので、慎重にやる必要がある。

glib のバージョンが上がって、後方互換が保てない。Linux emulation で使っている古いソフトウェアが動かなくなってしまうので、慎重にやらないと全く動かなくなってしまう。 普段は dynamic ライブラリの方が都合がいいのだが、この時ばかりは、static リンクされた物が欲しくなるが、どうしようもない。

前置きが長くなったが、それが理由で何本かの ports ツリーを保持している。たまに大きい物をコンパイルするときに、ディスクが足りなくなることがある。そこで、rm -rf /usr/ports-ccyymmdd などとやるわけだ。そして、/usr/obj にも何か残っているときはそちらも消す。まあ、それだけだったら簡単だ。 と、言いたいところだがそうはいかない。rm など、IO 系のプロセスが複数同時に走ると、とても遅くなるのだ。マルチプロセス OS だから、しっかりコンテキストスイッチをしてくれるのだが、どうしてもその動作が影響してしまう。CPU の場合は、そう気にする程のものではないのだが、IO は元が遅いのでその影響が大きい。 そこで、IO 系のプロセスは同時に起動するのを止めればいいのである。方法としては、コマンドライン一行に全てを並べてもいいし、batch などで順次登録していけばいい。


% cd /usr; rm -rf ports-20051012 &
% cd /usr/obj; batch
rm -rf *
^D
%cd /usr/src; batch
rm -rf *
^D
等とやる。コマンドラインに並べると、全てを一度に並べなければいけないが、少し経ってからもっと消せるものを見つけるのはよくあることである。そこで、batch を使うと、前の rm が終ってから次のものが起動されることになる。 一つ気をつけなければならないのは、batch は CPU の利用率を見るので、コンパイルなどで CPU を使っているときは、rm が起動しなくなってしまうので、IO が idle になったら、CPU プロセスを一旦停止させる必要があることも。 tcsh 上の time の結果。

%top
Mem: 135M Active, 43M Inact, 96M Wired, 5584K Cache, 58M Buf, 198M Free

%time sh -c 'tar xf ports-20051011.tar.bz2 ; tar xf ports-20051227.tar.bz2 ;
rm -rf ports-20051011; rm -rf ports-20051227'
54.799u 36.884s 12:19.11 12.4%  51+5610k 63243+1430io 8pf+0

%time sh -c '(tar xf ports-20051011.tar.bz2 & tar xf ports-20051227.tar.bz2) ;
(rm -rf ports-20051011 & rm -rf ports-20051227)'
30.292u 19.041s 15:17.95 5.3%   52+5607k 31944+606io 1pf+0

%time sh -c 'tar xf ports-20051011.tar.bz2 ; tar xf ports-20051227.tar.bz2 ;
rm -rf ports-20051011; rm -rf ports-20051227'
54.709u 37.313s 12:15.19 12.5%  51+5595k 63201+850io 4pf+0w

%time sh -c 'tar xf ports-20051011.tar.bz2 ; tar xf ports-20051227.tar.bz2 ;
rm -rf ports-20051227; rm -rf ports-20051011'
55.221u 36.368s 12:08.63 12.5%  51+5574k 61356+825io 1pf+0w
メモリはかなりたくさんあるので、キャッシュは結構効いている。top で表示されるものを、抜き出した。tar & rm は合計四回、この順番で取った。違いはコマンドラインをよく見ること。1 つめと 2 つめを比べると、並列処理をさせると、25% 増量(当社比)になることが分かる。これは、全然嬉しくない増量。体感的にはもっと、遅くなると思ってたが、思っていたよりは遅くなっていない。それでもかなり大きな差が出ている。 実時間は長くなっているが、プロセス自体の実行時間はユーザ、システムともに短くなっていたので、キャッシュの影響かと思い、3 つめと 4 つめを試した。4 つめは、rm の順番を変えてある。どちらも、1 つめの結果と変わらないので、原因は違うところにあるようだ。 これ以上突き詰めても、結局待ち時間が短くなるわけではないので、これ以上の深追い止めることにする。
[FreeBSD]
[speeeeed]

コメント(全0件)
コメントをする


記事を書く
powered by ASAHIネット