NAKAMURA Minoru の日記 (2003年8月)

今月は不正アクセス多すぎ

今月は Blaster から始まって Nachi、Sobig.F と様々なウィルスが出現して、 ログが通常の 10 倍以上に脹れあがっている。
Blaster の影響とみられる Port 135 のアクセスを集計を 15日 の集計に加えてみたが 月末を迎えても未だ沈静化が見られない (18 日は自サイトのネットワークが不調なため例外的に少ない)。

Nachi が叩いてると思われる Port 80 の奇妙なアクセスも 8/19日 以来の高い水準を保っている。 不幸中の幸いは、 Blaster ・ Nachi に駆逐されたのか Nimda 系のウィルスの活動が縮小していること。

恒例の国別統計は、 今月のデータを使っても Blaster / Nachi の分析にしかならなそうなので、 止めておく。

[Java] 続・Jakarta JMeter を使ってみる

8/3 以降 JMeter を いろいろ調査中しているが、 その間にバージョンアップして v1.9.1 に。
v1.8 と比べると分散処理機能がかなり機能アップしていて、 リモート実行のレスポンスが改善されたり、 リモートサーバーを複数台 同時に処理できるようになったりしている。

とはいえ、まだまだ動作が変。

1. リモートサーバーが複数のネットワークに属していると リモート実行機能がうまく動作しない場合がある

例えば、 eth0 (192.168.0.1) と eth1 (10.0.0.1) の 2 つの ネットワークインターフェイスを持つホスト(remoteとする) に、 10.0.0.2 のホスト(clientとする) から リモート実行を掛ける場合が、 remote の 自分自身のホスト名(hostname) から引けるアドレスが 10.0.0.1 であれば問題ないのだが、 192.168.0.1 だと client 側にリモートサービスを提供することが できない。
JMeter のリモート実行機能は、 複数の NIC がささったマシンを想定せずに 設計されているように思われる。
現状、 hostname を切り替えて対処しているが修正が必要。

2. リモート実行機能のレスポンスが悪い

商用の Web テストツールと比べるのは酷だが、 JMeter のリモート実行機能はまだ未完成。
v1.9 系から複数のリモートサーバーを 同時に実行したり停止したりできるようにはなったのだが、 複数のリモートサーバーと並列に通信するわけではなく、 内部的には逐次処理をしているようだ。 そのため、 こちらの 16 台ほどリモートサーバーを 全部起動 / 停止させるまでにはずいぶん時間が掛かる。

また、 クライアントが使用可能な リモートサーバーのリストは、 設定ファイルに静的に書くことになり 動的に増減できない。
リストを増やせないのはまだいいのだが、 リモートサーバーは クライアント起動前に立ち上がっていないと、 そのクライアントから使用することはできないようだ。 設定ミスがあったり JavaVM が途中で 落ちたりした場合に問題になる。

また、 v1.9 系の一斉リモート実行・停止は 不通となったリモートサーバーに対しても行われるのだが、 正常に動作しないサーバーへの操作は リトライが何度も掛かるようで 非常に時間が掛かる。 リストを途中で減らすことができないので、 こけたサーバーが出た時点で 一斉リモート実行・停止機能は御役御免になってしまう。

3. スクリプトに難がある。

細かい点だが、 jakarta-jmeter-1.9.1.zip に同梱されている サーバーモード用のシェルスクリプトにはやや難があり、 Linux の bash では意図されたようには動作しなかった。

$JMETER_HOME/bin/jmeter-server

#!/bin/sh set OLDCLASSPATH=$CLASSPATH export OLDCLASSPATH set CLASSPATH=`dirname $0`/../lib/ext/ApacheJMeter_core.jar:`dirname $0`/../lib/jorphan.jar:`dirname $0`/../lib/logkit-1.2.jar export CLASSPATH rmiregistry & set CLASSPATH=$OLDCLASSPATH export CLASSPATH `dirname $0`/jmeter -s "$@"

おそらく、 以下のようなコードを意図したと思われる (緑文字の部分は追加)。

#!/bin/sh OLDCLASSPATH=$CLASSPATH export OLDCLASSPATH CLASSPATH=`dirname $0`/../lib/ext/ApacheJMeter_core.jar:`dirname $0`/../lib/jorphan.jar:`dirname $0`/../lib/logkit-1.2.jar export CLASSPATH rmiregistry & RMIREGISTRY_PID=$! CLASSPATH=$OLDCLASSPATH export CLASSPATH `dirname $0`/jmeter -s "$@" kill $RMIREGISTRY_PID

ついでに、 /var/run/jmeter-server.pid などを導入して 開始・停止をきっちり起動スクリプト化した。

不満点はあるが、 v1.9.1 の手応えでは ソースコードを修正すれば 負荷発生器としてはかなり 使えるものになりそうなので がんば ＞ 自分

Amazon からいろいろ届く

ここ数日で Amazon.co.jp で注文していたものが届く。

• DVD: Bowling for Columbine。
  
• O'REILLY の GOOGLE HACKS。
  
• 吉田戦車の 「象の怒り」。
  
• 「ハトのおよめさん」 3巻。
  

Bowling for Columbine は マイケル・ムーアのノンフィクション映画の DVD のデラックス版。
DVD サイズで真中に銃弾のような穴の空いた小冊子 「MMMM (Michael Moore Media Missionary)」が付いてくる。
アカデミー賞受賞時のスピーチが 映像特典になっているのではないかと期待したが 入っていなかった。

GOOGLE HACKS の方もぼちぼちと読む。
結構知らない・使っていない機能があることに気づく。

ブレードサーバーもどきがついに稼働

8月のはじめから取り組んでいた ブレードサーバーもどき が 32 台の Red Hat Linux 7.2 のディスクレスクラスタとして 動作するようになった。 DHCP サーバーから設定をもらった各ノードは、 tftp から vmlinuz をダウンロードして NFS 越しに / (ルート) をマウント。 /var と /tmp を ramdsik 上にとりながらも swap ファイルなしで健気に動作している。

とはいえ、 Cerelon 600 MHz という そこら辺に転がっているホームパソコンに dhcp / tftp / NFS サーバーをやらすという 荒技をかましている(これも RH Linux 7.2J)。 そのため起動は不安定窮まりなく、 32 台のうち 4〜5 台は NFS マウントに失敗したりして 起動に失敗する。
＃ 起動に失敗した場合には自動的にリブートが掛かる。

遅いのは構わないのだが不安定なのは困る。 NFS サーバーのパラメータを調整してチューニング等を行いたいのだが、 Linux の NFS サーバーは Solaris とはえらく勝手が違う。 さて、どうしたものか？

摂氏28度

水曜以来の蒸し暑い日が今日も続く。
元住吉の駅前はお祭りで御輿も出ている。 この暑い中 ご苦労樣。

銀ダコでタコ焼きを買い食べながら見物して、 寮に帰る。

[Linux] Red Hat Linux 9 でスレッドライブラリを変更

Red Hat Linux 9 のスレッドライブラリは標準で NPTL になっているが、 環境変数 LD_ASSUME_KERNEL を 定義することで調整が可能。
ダイナミックリンクされたスレッドライブラリを入れ替えることができる。

詳しくは リリースノートを参照。

Web ロードテストツールの比較

Web アプリケーションサーバーの耐久試験や性能測定をやるために Web ロードテスターが必要なのだが、 フリーでちゃんとした設定のできるソフトを探している。

管理人の要求としては、

• HTTP ベースで一通りのシナリオが組めること
• 複数台のクライアントを統合可能な分散実行が可能なこと
• Linux で動作すること

商用の製品は要望を満たしてくれるのだが、 目玉が飛び出るほどに高いので まともに買うわけにはいかない。

オープンソースの JMeter を修正して使うことを考えているが、 本当に実用になるかどうかは謎。

新横浜に来たらラー博に寄るのは当然として、、、

新横浜駅を降りてすぐのビルのテナントに文教堂書店が入っている。
文教堂は全国的な本屋のチェーンだが、この店舗の品揃えは一風変わっている。

ひとつは 2階のコンピューター関連書籍の妙な充実ぶり。
コンピュータ向けといっても、 新横浜に日立・富士通の SE / ソフト部隊がいるせいか、 初心者向けより SE / 開発者向けの本が多いぐらい。 最近の時流に沿ってか Linux 関連本も多く、Win 関連本のタイトルの 1/3 ぐらいは並んでいる。 ここ以外の一般書店で、パタヘネが平積みされているのを見たのは 秋葉原の書泉ブックタワー / LAOX ザ・コンピュータBOOK 館ぐらいだ。

もうひとつは変な漫画が多いこと。
高橋葉介、星野 之宣、諸星大二郎、山田章博、花輪和一の 比較的古い漫画が置いてある。 って、そんなに変でもないか。。。
あとゴルゴ13 が常備されているようで、 管理人もここでゴルゴ13 の第1巻をゲットした。

P.S.

ラー博によって純蓮と海龍のラーメンを食べて帰る。

HTTP サーバーへの謎のアタック？

W32.Blaster.Worm の余波か様々なウィルスが出現しているが、 管理人が管理しているホストには 8月18日の12時23分を皮切りに奇妙なアクセスの跡が残るようになった。 以下のように "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" の エージェントを返す GET リクエストが 19日だけで 300回以上に登っている。

AAA.BBB.CCC.DDD - - [18/Aug/2003:16:10:47 +0900] "GET / HTTP/1.1" 200 d "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)"

このワーム(?) は ICMP を ping して生きていると判断されたサイトの TCP/80 ポートに HTTP でコネクションし、 IIS サーバーかどうかを判定しているようだ。 古い傷跡の空いているサーバーが多いようで、 かなり広い範囲に拡大している。

追記：8/21

これは Nachi ビールスのようだ。

[Linux][Tips] Linux の設定メモ

現在、Vine Linux 2.6、Red Hat Linux 7.2、Red Hat Linux 9 を使用中。
その設定メモを残しておく。

Apache サーバーのリソースを制限する

Apache サーバーで、 CGI プログラム(または SSI プログラム)が無制限に リソースを消費しないようにリミットを設けることができる。 設定できるのは以下の項目。

Directive	制限項目
RLimitCPU	CGI プログラムあたりの使用可能な CPU 時間を秒数で制限。
RLimitMEM	CGI プログラムが使用可能なメモリをバイトサイズで制限。
RLimitNPROC	CGI プログラム等の子プロセスをいくつまで fork できるかを指定する。 ユーザーあたりのプロセス数で指定。

この directive は httpd.conf の任意の階層に指定できる。 指定方法は1オペレータと、2オペレータのどちらか。

directive  soft-resource  [max-resource]

soft-resource と max-resource は 数値か max というキーワードを指定可能。 max を指定した場合には、OS の許すリソースの最大値が設定される。
CGI プロセスのリソースが soft-resource を越えた場合、 Apache から SIGKILL シグナルが送られ強制停止させられる。
max-resource は指定できる soft-resource の上限を決めるパラメータ。 RLimitCPU / RLimitMEM / RLimitNPROC は >Directory< の階層構造中でオーバーライドすることが可能だが、 基本的には制限を厳しくする(値を小さくする)方向にしか指定できない。 ただし、root の権限で実行中は上限を緩める(値を大きくする)指定も可能。

PC での NTP サーバーの設定

PC-UNIX の多くは ntpd デーモンが立ち上がるまで 自分のマシンのハードウェアクロックをローカルタイムの 基準として使用する。 しかし、 ntpd デーモンは調整前のローカルタイムと基準タイムとの間に 1,000 秒以上のズレがあるときは、 以下のようなメッセージを syslog に出して 調整を放棄する。

13 Aug 09:31:05 ntpd[22087]: time correction of -1120 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.

この制限事項を取り除いて 常に NTP サーバーに時刻を合わせたい場合には、 /etc/ntp.conf に 以下のように設定する。

/etc/ntp.conf

tinker panic 0

シリアルコンソール

Linux で RS-232C ポートに端末をつないで コンソールとして使えるように設定する。
RS-232C の COM1 に 9600bps / 8bit / ノンパリティで接続する場合、 以下のようになる。

まず、 lilo や grub のようなブートローダーの設定ファイルに赤字と青字の部分を加え、 変更が有効となるように更新する。 赤字はブートローダがシリアルコンソールから表示・設定できるようにするもので、 青字はカーネル起動後のブートメッセージがシリアルコンソールに表示可能にするもの。
最初の console=tty0 は通常のコンソールから、 次の console=ttyS0... はシリアルコンソールの 両方から入出力を行うことを指定している。

/etc/lilo.conf

prompt timeout=50 default=linux-2.4.20 boot=/dev/hda map=/boot/map install=/boot/boot.b message=/boot/message linear serial=0.9600n8 image=/boot/vmlinuz-2.4.20-0vl10     label=linux-2.4.20     initrd=/boot/initrd-2.4.20-0vl10.img     append="console=tty0 console=ttyS0,9600"     read-only     root=/dev/hda2

/boot/grub/grub.conf

default=0 timeout=10 serial --unit=0 --speed=9600 -word=8 --parity=no --stop=1 terminal --timeout=10 serial console splashimage=(hd0,0)/grub/splash.xpm.gz title linux-2.4.20     root (hd0,0)     kernel /vmlinuz-2.4.20 ro root=/dev/hda3     console=tty0 console=ttyS0,9600n8r     initrd /initrd-2.4.20.img

次に、 起動後の Linux がシリアルコンソールからログイン可能になるように /etc/inittab を設定する。

/etc/inittab

s0:12345:respawn:/sbin/mingetty -L 9600 ttyS0

最初のカラムの s0 はシンボル名なので、 重複しなければ inittab ファイル内で自由に名前をつけてもよい。 次のカラムの 12345 はこの設定を有効にしたい Run Level を列挙する。
それと シリアルコンソールからログインを行うためには、 /etc/securetty 内に ttyS0 と記述した行があることを確認し、 なければ追加する。

P.S.

Sun から Java2 SDK の 1.3.1_09 が公開された。
これは 1.3.1 系のバグフィックスバージョンの最新版。

追記：2006/3/22

mingetty は agetty を使った方が高速にアクセスできる。

s0:12345:respawn:/sbin/agetty 38400 ttyS0 vt100

夏の全国大会

気温が下がってよい塩梅なので、 東京ビッグサイトで開かれている某イベントに行ってみる。
普段は新橋駅からゆりかもめに乗るのだが、 今回は豊洲駅から都営バスに乗りビッグサイト前に。
小雨がぱらつく天気だが、 蜘蛛の子を散らすようにうねうねと人の波ができている。

事前の情報収集を欠いていたので、 友人を冷やかして 2、3 サークルを回った後 速やかに撤退する。

今日の教訓

都営バスで全国大会に行くときは「東京ビッグサイト」ではなく「国際展示場正門駅前」で降りること。

[Bench] Opteron 246 の SPEC CPU2000 が登録

www.spec.org のページに AMD Opteron 246 (2.0GHz) のスコアが登録された。
AMD 自身が Rioworks のマザボードを用いて評価したものと、 IBM が eServer e325 を評価したものとがある。

AMD の評価は Microsoft Windows Server 2003、 Intel C/C++ 7.0、Intel Fotran 7.0、Compaq Visual Fortran 6.6 を使った IA-32 ベースのもの。 int2k が 1,317、 fp2k が 1,293。 IA-32 系では int2k、fp2k とも Pentium4 のスコアを凌いでいる。

一方、IBM eServer e325 の評価は AMD64 としての評価。 SuSE Linux 8.0 上で SuSE gcc33 と PGI Fortran 5.0-1 を用いて fp2k のみ評価している。 スコアは 1,180 で AMD の測定より1割程度落ちている。 これが SPEC FP2000 を LP64 化した際に生じるペナルティなのか コンパイラの性能差によるものなのか分からないが、 AMD にもそろそろ専用コンパイラを開発して欲しいところだが。。。

W32.Blaster.Worm は大繁殖

NT 系 の RPC サービスを提供する Port 135 を狙った W32.Blaster.Worm が大繁殖をしているようで、 管理人のサイトにも大量のアクセスが来ている。
ルーターのログを解析すると 8/12 から Port 135 に対するアタックが急増し、 未だ3桁台の後半を維持している。 逆に、 Port 445 (Windows2000 のダイレクト SMB サービス) に対するアタックは ここ数日半減している。 Port 445 を攻撃するウィルスに掛かったマシンに W32.Blaster.Worm が 2 重感染して、 攻撃力が低下したのかも。。。

8/1 から 8/15 日までのアタックを、 ソース IP ごとに国別集計してみると以下のようになる。

W32.Blaster.Worm は、 感染先ホストの IP の上位ビットをベースに下位ビットランダムに生成して 攻撃先としてるようだ。 そのため近隣のサイトからのアクセスが多く、日本が最上位にきたようだ。
ただ (地域 NIC が異なるため) IP アドレスの上位が重ならないアメリカからのアタックが (普段通り) 多くて、 重なる可能性の高い中国からのアタックが普段よりも少ないのはなぜなのだろう？

[Tips] Postfix の設定の覚書

Postfix + fetchmail 環境で、 プライマリーメールサーバーとは別のホストで メールを送受信する場合の設定の覚え書き。 @my-domain.hoge.jp のメールを受信する mail.my-domain.hoge.jp があるが、 このメールサーバーとは別の server1.my-domain.hoge.jp で 自分のメールだけを送受信したいとする。
server1 で Postfix を運用している場合、 fallback_transport を指定すること。

server1 には 自分のアカウント以外ないので @my-domain.hoge.jp ドメインに属する 別人のメール other@my-domain.hoge.jp を投げると ロストしてしまう。 fallback_transport を指定すると、 自分のホストにアカウントがない場合、 fallback_transport の指定先にフォワードしてくれるようになる。

知人の歓送会へ

某社を退職する ikuta 氏の歓送会へ。 入社3年目の退職である。

転職先はインドのバンガロールに本社がある IT 企業で、 その日本支社で SE をやるそうだ。 ただ、インドで1年間の研修があるようだ。

とにかく氏の未来に幸多からんことを祈る。

[Tips] DHCP の設定の覚書

RedHat Linux 7.2 上で DHCP サーバーを設定する際に つまった点を書き留めておく。
RedHat Linux 7.2 にパッケージとして同梱されているのは INTERNET SOFTWARE CONSORTIUM の dhcp サーバーである。
この DHCP サーバーの設定は基本的には /etc/dhcpd.conf に書くが、 この設定ファイルだけでは 数のネットワークに跨るゲートウェイで あるネットワークには DHCP サービスを提供し、 別のネットワークには DHCP サービスを提供しないという 設定が書けない。

具体的には、 2枚の NIC を挿して 192.168.0.0/255.255.255.0 と 10.0.0.0/255.0.0.0 の 2 つのネットワークに跨るサーバーがあったとする。

eth0: 192.168.0.1/255.255.255.0
eth1: 10.0.0.1/255.0.0.0

192.168.0.0/255.255.255.0 では DHCP を行い、 10.0.0.0/255.255.255.0 では行わないとすると、 こんな感じで書けそうに思える。

しかし、 この設定では eth1 の設定がないとエラーとなる。
ログは以下のように表示される。

Aug 12 16:44:02 server-name dhcpd: Listening on Socket/eth0/192.168.0.0
Aug 12 16:44:02 server-name dhcpd: Sending on   Socket/eth0/192.168.0.0
Aug 11 16:09:35 server-name dhcpd: No subnet declaration for eth1 (10.0.0.1).

しかし、 10.0.0.0/255.255.255.0 の設定を書いてしまうと dhcpd が 10.0.0.1 で listen するようになるので これも問題である。

解決方法は dhcpd の起動オプションで、 listen したいネットワークインターフェイスを指定すること。 ここが無指定だと 全てのネットワークインターフェイスの 67 番ポートで listen しようとして、 エラーなってしまうもよう。
これ以外に解決方法がないもよう。

/usr/sbin/dhcpd eth0

白山「ゆどうふ五右ヱ門」

男５人で豆腐を食べに行く。
場所は文京区本駒込にある「ゆどうふ五右ヱ門」。

騒々しい白山上の通りから門をくぐると、 別世界のような静かさ。 確かに「千と千尋の神隠し」ような雰囲気である。

入り口

7,500 円のコースで、以下のような皿。

1. 笋羹 - 前菜(湯葉、チューシュー) 2. 胡麻豆腐 3. 三色田楽 - 豆腐田楽 4. ??? - 豆乳で作ったうどん(?) 5. 箸洗い - 日本酒とワインを割った物の中に果物(???)

6. 抹茶口梅 - 梅肉をボール状にして抹茶をまぶせて揚げた揚げ物 7. 冷やし豆腐 - 冷奴の盛り合せ 8. 吹き寄せ揚げ - てんぷら (豆腐は含まれず) 9. お食事 - 御飯と赤出し 10.デザート (メロン)

湯豆腐がでなかったの残念。

台風到来

関東圏まで届く台風がやってきた。
昼過ぎに起き出した時には、 雨は小降りだが強風域のまっただ中。 道行く人は傘をさせずにいる。
ごはんを食べに行くのも億劫なので、 寝直して一日を過ごすことにしょう。

VMware を初めて使う

長らく Windows NT 4.0 WS でがんばってきたクライアント環境を Windows 2000 に移行することに決定。 ただ、Windows 2000 では動作しないソフトが結構あるのが辛いところ。 同時に、NPTL と JavaVM の相性を検証するために Red Hat Linux 9.0 をインストールする必要があるがマシンが足らないという状態だ。

そこで遅ればせながら VMware の試用版をダウンロードして、VMware 上で Windows NT 4.0 を動かしてみる。 ホスト OS が Windows 2000、ゲスト OS として Windows NT 4.0 / RedHat Linux 9.0 だ。 インストールは順調に終わり GUI の動作等は機敏だ。 しかし、ゲスト OS のディスクの読み書きが始まるとかなりの速度低下がみられる。 VMware のせいもあるが CPU (Celeron 300@450MHz) / HDD (ATA-33) というのも化石の部類に入っているのかもしれない。

P.S.

VMWare を入れてから うたにの道具屋さん の swap2k がきちんと動作しなくなった。
原因は不明。

追記：8/14

VMware の仮想ネットワークドライバーと Contivity VPN Client は相性がよくない。
双方、TCP ドライバーにフックを掛けるようで後からインストールした VMware の仮想ネットワークドライバーが作動しない。

ブレードサーバーもどきのネットブートに成功

ブレードサーバー擬を PXE 経由でネットブートさせることに成功。
32 枚あるブレード擬のうち 1 枚をサーバーにして、 残りの 31 枚を Wake-On-LAN で起動したところ無事 Linux として動くようになった。 サーバー役のブレード擬は dhcp / tftp / nfs サーバーを仕込んだ起動イメージを Compact Flush に焼いて装着している。 Wake-On-LAN 用のマジックパケットの送信には、 José Pedro Oliveira 氏の Wakeonlan を使用。

ただ今のやり方はそれぞれのブレードノードが自前の RAM ディスクを持ちサーバーから OS イメージを転送して動いてる。 NFS root で動作するように変更せねばならない。

追記：8/14

NFS ルートマウントのやり方は YAMAMORI Takenori 氏の「PXE を使ってPCもディスクレスにしよう」 のページが詳しい。

「アーキテクチャ徹底解説 Microsoft Windows2000」を読む

7/26に届いたアーキテクチャ徹底解説 Microsoft Windows2000 の上巻 をぼちぼちまじめに読みはじめた。 面白いと思ったのは、以下のような点。

• ユニプロセッサカーネルとマルチプロセッサカーネルの違いは、 Ntoskrnl と Ntdll.dll と kernel32.dll の 3 つだけ。 Ntoskrnl は条件コンパイルによって別々のものを生成しているが、 Ntdll.dll と kernel32.dll はマルチプロセッサカーネル LOCK/UNLOCK 命令を NOP 命令で潰すパッチを当てただけで生成している。
  
  
• 高速 LPC (Local Procedure Call) と呼ばれる カーネル内部でのみ有効な IPC がある。 この通信を用いる場合、 クライアントスレッドからサーバースレッドは 通常のスレッドスケジューリングを介さずに通信できる。 呼び出されたサーバースレッドは、 呼び出したクライアントスレッドの タイムスライスを引き継いで連続的に動作する模様。
  
  
• NT カーネルのロックは spin lock が基本で、 一部だけ queue spin lock と呼ばれる機構。 queue spin lock はロック毎に FIFO のキューがあり、 ロックを取れなかったプロセッサは自分の ID をキューに登録して 順番待ちをする。 この際の spin lock には、 各プロセッサ毎に存在するローカルなフラグを使う。 ロックを所有していたプロセッサがロックの所有権を開放する際には、 次の呼び出し順位のプロセッサのフラグを変更してロックの開放を通知してやる。
  この方式の優位な点は、 グローバルなフラグを使った単純な spin lock では マルチプロセッサ間でフラグを含んだキャッシュラインを取り合うことに なり性能が低下するが、 queue spin lock では待ちを行うプロセッサは自分の所有するフラグだけを 監視していればよいので、 競合性のキャッシュミスが少なくなること。
  
  
• Windows NT のプロセッサ優先度の「リアルタイム」は、 ただ優先度が最高というだけで、 普通言われる意味での「リアルタイム」とは関係がない。 Windows Embedded は、 Windows NT とカーネルソースを共有しているようで、 リアルタイム性を実現する機構は入っていない模様。
  
  
• Windows Management Instruction (WMI) は、 Web ベースエンタープライズ管理 (WBEM) の標準実装。
  (管理人は WBEM は、Java とか Web アプリの世界だけの話だと思っていた。)
  
  
• 各プロセスが CPU 実行権を得るとクォンタム値をセットされる。 Windows 2000 の場合、 内部クロックが発生すると実行中のプロセスのクォンタム値が 3 減少し、 0 以下になったプロセッサにはコンテキストスイッチが起きる。
  このクォンタム値は、 Win2000 Professional で 6、 Win2000 Server では 36 がセットされる。 IA-32 のシングルプロセッサマシンでは クロックインターバルは普通 10 ミリ秒で、 マルチプロセッサマシンは 15 ミリ秒。 そのためデフォルト設定では、 1 CPU の Win2000 Pro は 20 ミリ秒おきに 2 CPU の Win2000 Server は 150 ミリ秒おきに コンテキストスイッチが入ることになる。
  
  
• Win2000 Pro は、 アクティブウィンドウを持っている フォアグラウンドプロセスを優遇するために、 フォアグラウンドプロセス内のすべてのスレッドの クォンタム値を 6 から最大 18 まで引き上げる機構を持っている。 そのため、 プログラムがアクティブウィンドウにいる場合といない場合では 使用できる CPU 時間が最大 3 倍違う可能性がある。 一方、 Win2000 Srv. ではフォアグラウンドプロセスに対する優遇はない。
  この設定は 「コントロールパネル」の「システム」の「パフォーマンスオプション」の ダイアログで変更でき、 「アプリケーションの応答」の項目を 「アプリケーション」に合わせると Win2000 Pro 流、 「バッググラウンドサービス」に合わせると Win2000 Srv 流になる。
  
  
• デバイスドライバのバグを発見しやすくするため Driver Verifier と呼ばれる機構がある。
  \Winnt\System32\Verifier.exe を起動することによって実行可能。
  Driver verifier には、 special pool と呼ばれる メモリ割り当てにガード領域を付けることで オーバーランを検出する機構などがある。 他に、 Pool tracking、 Force IRQL checking、 Low resources simulation が用意されている。
  

下巻もぼちぼち読むか。。。

[Bench] 新しい SPECjbb2000 スコアが登録される

毎度の www.spec.org に 3.06GHz Intel Xeon と 1.0GHz Pentium-M のスコアが登録された。
3.06GHz Xeon は 1MB L3 キャッシュのついたバージョンが CINT2000 1,243、CFP2000 1,152。 512KB の L2 キャッシュのみのバージョンは CINT2000 1,067、CFP2000 1,044。 同系のプロセッサでは、Pentium4 w/HT 3.2 GHz の方が僅差で負けている。
Pentium4 / Xeon / Xeon MP でキャッシュサイズの違いがあったが、キャッシュバリエーションが増えすぎて三者の違いは愛昧になりつつある(値段だけは極端に違うが。。。)。

Pentium-M の方は、HP がブレードサーバー ProLiant BL10e G2 のもの。
SPEC CPU2000 スコアには登場しないだろうと思っていた Pentium-M のスコアであり興味深いデータだ。 結果は CINT2000 687、CFP2000 552。 1.0 GHz の Pentium-M が Pentium3 1.4GHz 並み性能を出しているので IPC(Instruction Per Cycle) が高さが実証される。 しかし、スコアの絶対値としては上位陣とかなり差がついた結果だ。

P.S.

自分のサイトSPECcpu2000 にみるプロセッサの性能自分のページも更新。

[Java] Jakarta JMeter を使ってみる

J2EE の性能評価に使えないかと、Jakarta プロジェクトの JMeter を試している(使用しているのは jakarta-jmeter-1.8.1.tgz)。 当初、他の C/C++ で書かれた負荷シミュレータと比べて、CPU 使用率ばかり高くて性能をあげにくいプログラムだと思っていたが調整次第では結構いけそう。

リモート実行機能

JMeter には、複数台のマシンで JMeter を立ち上げておいてクライアントマシンからリモートで利用するような使いかたができる。

サーバー(つまりリモート操作される側)

サーバー側で JMeter を実行するには、 まず JMeter で必要とされるクラスライブラリファイルの位置を CLASSAPTH に入れ、 rmiregistry を実行する。
その後、JMeter をサーバーモードで実行してクライアントからの依頼を待つ。

Linux でサーバーを立ち上げる場合には、 以下のようになると思われる。

> export CLASSPATH=$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/jorphan.jar:$JMETER_HOME/\lib/logkit-1.0.1.jar:$CLASSPATH
> $JAVA_HOME/bin/rmiregistry &
$METER_HOME%/bin/jmeter-server &

クライアント(リモート操作する側)

クライアント側では、 JMeter の bin ディレクトリの下にある jmeter.properties ファイルに、 remote_hosts を指定する行を加える。
リモート操作を行いたいサーバーの IP アドレスを カンマで区切って列挙する。

remote_hosts=10.0.0.1, 10.0.0.2

その後、 普通に JMeter を立ち上げると メニューの「実行」 - 「開始(リモート)」の先にある 選択肢が remote_hosts で指定したものになっている。 ローカルサーバーで実行する「実行」 - 「開始」の代わりに、 「実行」 - 「開始(リモート)」 - (リモート先) を 指定するとリモート実行が開始される。
見た目はローカルで実行しているのと変わらないが、 実行はリモートホストで行われている。

ただし JMeter のリモートホスト機能は、VNC や Remote Desktop 的な、クライアントとサーバーが一対一な関係を想定しているようだ。
クライアントとサーバーが一対多を実現するには改造が必要か？

JavaVM のオプションの調整

JMeter の処理性能を上げるには、jakarta-jmeter-1.8.1/bin/ ディレクトリの下にある jmeter シェルスクリプト/jmeter.batバッチファイルの中の java の設定を修正するのが肝心。

元のファイルには、以下のように java のオプションが設定されている。

java -Xincgc -jar ApacheJMeter.jar %JMETER_CMD_LINE_ARGS%

-Xincgc オプションは、動作中に GC が多発してもよいが 1回の GC が JavaVM を停止する時間が最小となるようにがんばる GC アルゴリズム。 JMeter はリクエストのレスポンスタイムを計測しているため、長めの GC が起きると計測が正しくならないため指定されていると思われる。
ただ、1回のリクエストのレスポンスタイムの正確差よりも、とにかく大量にリクエストを発効してくれることを優先するなら別のオプションを調整した方がよい。 SUN の JRE/JDK の 1.3.1/1.4.1 系 JavaVM を用いてるなら、以下のような感じか？

# Sun JDK 1.3.1
java -server -verbose:gc -Xmx128m -Xms128m  -Xbatch -XX:NewSize=40m -XX:+UseTLE -jar ApacheJMeter.jar %JMETER_CMD_LINE_ARGS%

# Sun JDK 1.4.1
java -server -verbose:gc -Xmx128m -Xms128m  -Xbatch -XX:NewRatio=2 -XX:+UseTLAB -jar ApacheJMeter.jar %JMETER_CMD_LINE_ARGS%

オプションは、以下のような意味。

• -server はサーバー系の JIT コンパイラエンジンを使用するオプション。 実行履歴が十分に溜ってからコンパイルを始めるので出足が遅いが、 いったんコンパイラされたコードはデフォルト(-client)よりも高速。
  その代わり十分な予備実行が必要。
  -Xbatch オプションも JIT コンパイルに絡むおまじない。
  
  
• -Xmx/-Xms はメモリオプションで、 java が使えるメモリ量を指定できる。 メモリは多ければ多いほど性能(リクエスト/秒)はよくなるが、 1回の GC 時間は伸びるのでレスポンスタイムの計測に悪影響があるのでほどほどに。
  あと、 JDK 1.3.1 系の JavaVM の場合には -Xmx/-Xms で指定した値の 1/3 ぐらいを -XX:NewSize=size に、 JDK 1.4.1 系の JavaVM の場合には -XX:NewRatio=2 と指定するとメモリ効率がよくなる。
  
  
• -XX:+UseTLE/-XX:+UseTLAB は マルチスレッドプログラムの性能を改善してくれるおまじない。
  
• -verbose:gc は、 GC の状況を標準出力に出すオプション。
  

あと JMeter の設定を誤ってリクエストの発効がエラーになると、JMeter は System.gc() を呼び出して強制的に GC を発生させているようにみえる。 1リクエストに対して 1つの Full GC が起きるため極端に性能が低下するようだ。

梅雨明けとともに。。。

7/22 に直ったはずのクーラーは、再び水漏れを起こすように。
序々に冷房機能が失われてゆき、本格的な夏の訪れと共に完全に轟沈。

とにかく暑くて何もする気が起きない。

追記：8/5

基板ごと入れ替えてもらって、再び冷房が直る。 助かった。

To Do List

先月までにやるべきことが済んでいない。
Task queue はオーバーフローしそうだが、 負荷分散をしてくれるユニットもいないので単身がんばるしかない。
To Do リストを覚え書きとして記しておく。

「ブレードサーバーもどき」をネットワークブート可能にすべし

管理人のところにまわってきた 秘密の「ブレードサーバーもどき」を使えるようにするべし。
Pentium 700MHz / 768MB が 32 ノードというリッチな構成だが、 ソフトがないので現状ただの電熱器。
一応、PXE 経由で RedHat Linux 7.2 をネットワークブート可能なので ネットワークブート可能な構成を作るべし。

Web パフォーマンスツールを調査すべし

Microsoft のWeb Application Stress Tool は、 純粋に負荷を掛けるという目的であればよいツールだが、 Web サーバーの性能を計測しようとすると、 複数のノードを同期してアクセスを行う分散モードがないなどの弱点がある。 また、 何より Windows でしか動かないため、 上記のブレードサーバーもどきで使えない。
Jakarta プロジェクトの JMeter を試してみるが、 CPU パワーあたりの負荷生成機能がいまひとつだ。 時間が取れたら定量的なデータを測定してみたい。
＃ とはいえ、分散機能を備えたフリーの負荷シミュレータは JMeter しかないので、これを使うことになるだろう。
＃ 単体ノードの性能が少々落ちても 32ノード もあるし大丈夫さ。。。

CSIRO の EJB ベンチマークと SPECjAppServer 200X をインストールすべし

J2EE 評価用システムに EJB ベンチマークをインストールし、 性能測定を作業が残っている。
後者はともかく前者は誰かにお任せしたいが、 任せられる人もいないので自分でやるしかない。。。

Oracle 9i をチューニングすべし

インストールしてデータベーステーブルを構築した所で ほったらかしている Oracle 9i をいろいろいじってみるべし。
とはいえ 1GB をはるかに越える PDF ファイルの山を 読み解くのは難儀だ。

某 JavaVM に出たバグを取るべし

とにかく蟲を取るべし。

Linux のスレッドスケジューラーを読むべし、書くべし

Linux kernel 2.6 の O(1) スケジューラーは鬼門なり。 kernel に読んで手を入れるべし。

論文読むべし

PLDI 2003 など新しい論文誌が届いたらしいので読むべし。

新人の教育をすべし

プログラム経験のない新人に Perl + CGI を仕込むべし。

以上を8月中に終わらせるべし。