雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|

2003-05-08 全ページtDiary化

HTML 書くのが面倒なので、全てのページをtDiaryで管理できないものかと方法を模索.ノウハウを本家にフィードバック.


2009-05-08

[FreeBSD][Ruby] gem tips

前回のエントリに書いたように、RubyGemの管理をportsベースからgemコマンドベースに切り替えて使っていたんですが、webgenをアップデートしようとしたら、

# gem install webgen
Bulk updating Gem source index for: http://gems.rubyforge.org
Building native extensions.  This could take a while...
ERROR:  Error installing webgen:
        ERROR: Failed to build gem native extension.

/usr/local/bin/ruby18 extconf.rb install webgen
checking for fcgiapp.h... no
checking for fastcgi/fcgiapp.h... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

とか言われてしまった。FastCGIがインストールされていないのが原因らしい。最初はfcgiイラネ、とか思って無しでやる方法をグーグル先生にお尋ねしてみたものの、挫折。

あきらめてFastCGIをインストールしてからもう一度試すも、同じエラー。こらは自前コンパイルではおなじみのパスの問題というのはすぐに分かったので、gemのオプションを探す。

以下のようにすれば良いらしい。

 # gem install webgen -- --with-opt-dir="/usr/local"

ああ、思い出してきた。${PREFIX}/<アプリ名>/{bin|lib|include}スタイルではなく、/usr/local/{bin|lib|include|etc}スタイルを維持しているFreeBSDが好きなんだった。 Windows 98/NTとかでC:\Program Files\<アプリ名>の下に一時ファイルを作る(ので管理者権限じゃないと動かなくなる)行儀の悪い仕様のプログラムに泣かされたり、Solarisが/opt以下にアプリを入れるようになって戸惑ったりしたのが懐かしい。Mozzilaのプロファイル周りでもなんか痛い目にあったような気が…。


2010-05-08

[FreeBSD] 7.3-RELEASEでのソフトウェアRAIDの書き込み速度比較

7.3でataraid, gmirror/gstripeおよびZFSによるRAIDの書き込み性能を比べてみました。

OS
FreeBSD 7.3 amd64
CPU
Core2 Duo E6700(2.66GHz)
M/B
Intel DG33TL
Mem
DDR2-800 6GB(一部2GB)
HDD
Hitachi HTS545050B9A300 x 4

上記環境でddによる/dev/zeroからの1GB連続書き込み

# dd if=/dev/zero of=/mnt/xxx/t.img bs=1024000 count=1024

を10回試行したときの最大/最小値を比較。ad, ar, gm/gsではパーティションは切らずに、

 # newfs /dev/ad8
 # mount /dev/ad8 /mnt/xxx

のようにディスク全体をnewfsして直接マウントした。

[border]

device\type2台stripe3台stripe4台striperaid01raidz1raidz2
ad(HDD単体)[tright]71.1 / 67.9MB/sec
ar82.1 / 74.8101.4 / 93.4120.4 / 110.182.3 / 75.8××
gm/gs104.9 / 96.8136.1 / 128.4159.3 / 145.6106.6 / 97.8××
zfs(6G)307.7 / 189.9380.2 / 217.0402.9 / 289.3295.8 / 187.8223.5 / 132.5151.7 / 94.9
zfs(2G)--219.1 / 118.7128.7 / 121.4102.7 / 95.767.9 / 59.7
  • 表には載せていないがarおよびgm/gsはメモリ搭載量でスコアに変化なし
  • ZFSはメモリ搭載量にパフォーマンスが影響を受ける(2Gの2/3台stripeは取り忘れ)
  • 余談だが、arのdelete, createでリブートの必要が無くなり、ハンドリングがだいぶ改善されている

というわけで、スコアだけ見ればZFSが圧勝で、4台のraid6でも他のデバイスでの同じ台数のstripeに匹敵するほどでした。これはちょっと意外。ただしZFSは以下の点が気になります。

  • スコアのムラが大きく、また一定しない
  • スコア自体がHDD単体時の71*4=284MB/secを超えているのが、どういう理屈によるものなのか心配^J(設定はcompression=off, compressratio=1.00x)

追試(5/10)

上の実験、/dev/zeroではパリティの計算が一瞬で終わってしまいちゃんとした比較にならないかもしれないと思い、追試してみました。サンプルとしてパッと思いつくのは/dev/randomですが、読み出しがボトルネックになるので、tmpfsを使ってメモリ上にサンプルを準備します。

/etc/fstabを編集して最大1.5GB分の領域を確保

 tmpfs /tmp tmpfs rw,mode=1777,size=1610612736 0 0

1GBのファイルを準備

 # dd if=/dev/random of=/tmp/t.img bs=1024000 count=1024

この/tmp/t.imgを使って書き込み速度を計測してみました。メモリ容量が速度に影響するのは上の実験で分かっているので、比較のために/dev/zeroの速度も測りました。

[border]

file\raidraidz1raidz2
/dev/zero173.0 / 137.0 110.1 / 63.8
random260.1 / 187.2109.3 / 96.2
zero261.6 / 151.0108.2 / 102.6

ご覧の通り、/dev/zeroのraidz1は不思議な速度低下をしたので、/dev/zeroから生成した/tmp/t.imgを使った実験も行って表の一番下の行に記載しました。tmpfs使った以外は上の実験と条件変わらないはずなので、ちょっと謎です。

さておき、結果的にはファイルの内容が0-fillでもランダムな値でも速度的には変わらないようでした。前回の実験と値がけっこう変わってますが、これはtmpfsを使った影響とみればいいのかな?