404 Blog Not Found

申し訳ないけど、ぬか喜びのような気が。

dirdumpを実行すると、以下のような結果が得られた。

./dirdump data  0.26s user 6.43s system 18% cpu 36.962 total
./dirdump data --nosort 0.40s user 9.28s system 1% cpu 14:08.45 total

　36秒と850秒という、圧倒的な速度差（23.6倍！）が得られた。

このdirdump、FreeBSDでもそのまま動いたのだけど、4096bytes/file * 65556 files で動かしてみた結果が、こう。ファイルの生成に使ったscriptはentryの最後に。

% /usr/bin/time -l ./a.out data
        1.23 real         0.09 user         1.14 sys
      2220  maximum resident set size
         4  average shared memory size
       732  average unshared data size
       128  average unshared stack size
       467  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         0  block output operations
         0  messages sent
         0  messages received
         0  signals received
         1  voluntary context switches
       115  involuntary context switches
% /usr/bin/time -l ./a.out data --nosort
        1.24 real         0.12 user         1.11 sys
      2220  maximum resident set size
         4  average shared memory size
       732  average unshared data size
       128  average unshared stack size
       467  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         0  block output operations
         0  messages sent
         0  messages received
         0  signals received
         1  voluntary context switches
       139  involuntary context switches

こんなことをしてさえ、これしかかからない。

/usr/bin/time -l /bin/sh -c 'find data -type f | xargs cat | wc'
 6140990 268435456
        4.25 real         3.91 user         1.96 sys
     13344  maximum resident set size
         9  average shared memory size
       241  average unshared data size
       126  average unshared stack size
      6264  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         0  block output operations
         0  messages sent
         0  messages received
         0  signals received
      4386  voluntary context switches
      1091  involuntary context switches

ファイルシステムは、FreeBSD標準のUFS2、ディスクはこう。

ATA channel 1:
    Master:  ad2  SATA revision 1.x

確かOSも違えばFSも違えばHDDも違う、違うづくしではあるけれど、いくらなんでもこれは差がつき過ぎではないか。

で、思い当たるのは、ディスクキャッシュのサイズ。FreeBSDの例では、全てがDisk Cacheに乗っているように見受けられる。実際iostatで観察してみても、ディスクアクセスはほとんど発生していなかった。確かに当該マシンのメモリーは2GB。ファイルの内容込みで4KB * 65,536 = 256MBなら余裕でキャッシュできる。

で、実際に 先代 MacBook Pro 2.5GHz/4GB RAM、Hitachi HTS542525K9SA00 上で VMWare 2.05, Ubuntu 9.04, ext3/relatime (仮想ディスク、事前領域割当なし), 512MB RAM な仮想Linuxホストで試してみたのが、以下である。

% time ./a.out data

real	0m12.141s
user	0m0.024s
sys	0m10.205s
% time ./a.out data --nosort

real	0m8.284s
user	0m0.044s
sys	0m7.516s
% time ./a.out data

real	0m7.075s
user	0m0.048s
sys	0m6.888s
% time ./a.out data --nosort

real	0m7.041s
user	0m0.032s
sys	0m6.768s

見てのとおり、最初の実行時を除き、有為さは見られない。最初の実行のみやや遅いのは、ディスクキャッシュがまだ埋まっていないからだと推察できる。

というわけで私の結論。

• 元発言は、Disk Cacheにだまされている
• ユーザーランド上のディスク利用最適化は、OSの前では幻のようなもの
• UTF2 on FreeBSDはこういうケースで高速
• 下手にあがくよりRAMを積み増せ
• (未検証だが経験則的に)ユーザーランドであがくなら、FSではなくDBMにデータを押し込む手の方がよさげ

Dan the Man with Too Many Filesystems to Fiddle

#!/usr/local/bin/perl
use strict;
use warnings;
srand;
my ($dir, $count) = @ARGV;
die "$0 dir count" unless $dir and $count;
open my $rfh, '<', "/dev/urandom" or die "/dev/urandom:$!";

for (1..$count){
    my $fn = sprintf("%04x%04x", rand(0x10000), rand(0x10000));
    my $path = "$dir/$fn";
    -f $path and next;
    open my $wfh, '>', $path or die "$path:$!";
    read $rfh, my $content, 4096;
    print $wfh $content;
    printf "%d:$path\r", $_;
}
print "\n";