ユメのチカラ

MySQLのマルチコアスケーラビリティとLinux

スラッシュドットの情報。FreeBSDとLinuxでsysbench(MySQLを利用している)の結果が出ている。結論から言うと8コアのAMD64のマシンでスレッド数を上げていくと8スレッドまではLinuxでの性能が良かったが、それ以上になるとがたっと性能が劣化して、FreeBSDのSMPngの実装が勝つ。

下記を参照してほしい。
http://jeffr-tech.livejournal.com/6268.html

MySQL 5.0.2xではSMPスケーラビリティに問題があることは、われわれの性能評価でもあきらかになっていたが、(例：MySQLに対応した評価ツールDBT-1を利用したハードリソース変更によるパフォーマンスへの影響の考察を参照)、OSのSMPスケーラビリティ問題というよりMySQLの実装上の問題だと考えていた。

linux 2.6.18/2.6.20.1上でMySQL 5.0.27(これはスケーラビリティ上の問題が顕著)と5.0.33(スケーラビリティの問題を若干解決した)を評価したグラフを見ると、あきらかにFreeBSD-ULEの実装と比較して、linuxはスケーラビリティの問題がある。スレッド数がコア数(8)を越えたあたりから性能が急激に劣化する。

Linux Kernel Mailing Listでも早速話題になっていて、(http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/0299.htmlからのスレッドを参照)、Linuxのスケジューラの問題という認識になりつつある。

特に、SMT(IntelのHyperthread)やMC(Multicore)用のスケジューラが悪さをしていそうである。http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1142.html

CONFIG_SCHED_SMTとCONFIG_SCHED_MCをオフにした結果が下記に出ている。
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1133.html

http://www.ussg.iu.edu/hypermail/linux/kernel/0702.3/1133/transactions.png

若干現象が良くなっているが抜本的な解決にはなっていない。

MySQLで発見された現象が正しく理解されれば、遠くない将来に問題は解決されるだろう。

いろいろな人がいろいろな評価をしたり、知恵を出したり、コメントしたり、バザールモデルの醍醐味である。

企業発OSSのコミュニティアライアンス戦略

先日のTOMOYO Linux Nightをカーネル読書会で共催(？)させていただいた縁でいろいろ企業とOSSのかかわり、コミュニティとのアライアンスなど考えるきっかけを頂戴した。ありがたいことである。

昔からLinuxとかフリーソフトウェアが好きでずうっとやっていたFLOSS界の長老(20世紀のころからLinuxをいじっていた人々)と、会社の中でいろいろなしがらみ障壁を乗り越えがんばって来た方々とではFLOSSに対するスタンスや思いというのがかなり違うという実感がある。

OSSが豊かに健全に成長するにはビジネスの力が絶対に必要だという立場にわたしは立つのであるが、もちろんそうでない立場の人もいることは理解している。結果としてオープンソースやフリーソフトウェアが広まればフリーソフトウェアの人達にとっても悪いことはないと思うのだが、今回はそこには触れない。

企業のサポートによって開発されたOSSをどのように普及推進するかというのが今回の命題である。コミュニティはそれをどのように支援できるのか、できないのか、すべきなのか、すべきではないのか、双方にとってメリットのあるアライアンスの形態はどのようなものになるのかならないのか、というのが今回の問題である。

コミュニティと言うのは企業とか個人とかと異なり目に見えない曖昧な実体なのであるが、ここでは定義については踏み込まない。

バザールモデルは定義により、コアとなるソフトウェアを誰かが作って、それは個人であってもいいし企業であってもいい、それを不特定多数の善意のボランティアがよってたかって改良していくというソフトウェア開発モデルである。ここでボランティアというのはその活動によって収入を得ているか否かではなく自発的な意志によってその活動に参加している人のことを差すことにする。

コアとなるソフトウェアが個人によって開発されたものであれば、その開発の継続性はオリジナルの開発者の意志や情熱に依存する。そのソフトウェアの機能に注目し利用者が増えそのソフトウェアに共感した第三者があらわれればパッチを作ってくれるかもしれない。バザールが発生する瞬間である。

企業発のソフトウェアの場合、開発の継続性は企業の支援に依存する。スポンサーがいなくなれば失速する可能性が高い。たとえそのソフトウェアのアイデアが企業に属する個人によって生まれたとしても、それを実装するコストは企業が負担している以上、その個人の情熱だけでは継続するのは難しい。

企業内ハッカーの場合、社内のスポンサーというか金と権限を持っているパトロンが絶対必要になる。企業の研究所の場合、即事業化できなくても(売上がすくたたなくても)、別の名目で開発をおこなうことはできなくはないが、それも将来的に事業に結びつかないと評価されると継続することはできない。

日本にはOSS専業ベンダーというのが、少ないので(われわれもがんばらないといけないのだけど)、OSS専業ベンダーに就職して思う存分コードをハックするというめぐまれた環境にいる人はほとんどいない。

ビジネスとOSSの関わりでいうと企業規模が大きいところでオープンソースを将来の投資としておこなっているというのが大半(？)かなと思う。国内ハードウェアベンダーだとハードを売るためという大義名分がたつので、それでもカーネルやミドルウェア分野で開発めいた事ができるが、SIerだとそれもなかなか難しいというのが実状である。

それを理解した上でコミュニティは企業内ハッカーをどう支援できるのか？そもそもそんなことは可能なのか？

例えば、わたしがどこどこ社の偉い人に直談判してオープンソースを開発しているＸＸさんを支援してくださいなどとお願いにいけばうまくいくのか。1998年のNetscape社の取締役会はEric Raymondを呼んで「バザールモデル」について議論して、ソースコードの公開方法などを決定したそうだから100%不可能とは言えないが、宝くじを買うより確率は低そうな話である。(ちょっと考えにくいが不可能ではないかもしれない)

まあ、日本OSS推進フォーラムのような偉い人の集まりに行って一般論として企業のOSS支援についてなどと語ることは不可能ではない。

Web2.0系のネットベンチャーは皮膚感覚でOSSを利用しているし、コミュニティの重要性も理解しているので、上のような苦労はないが、伝統的な日本の大企業の偉い人を動かすには、それなりのお作法が必要である。

結局のところ企業の利益に貢献しなければOSSの開発も持続できない。利益は売上から経費を引き算して生まれるから、当該OSSを利用してSIやコンサルなりなんなりして稼ぐという方法(売上を増加させる)と、開発コストを下げる方法のあわせ技になる。

OSSのコア開発者がいるという事がある種の宣伝広告になるという立場で、ゼロ円で宣伝ができている、すなわち宣伝コストを低くできたといような方便も時には必要である。そのような方便というか説得するシナリオを沢山もっていって社内のカネと権限を持っている人を動かす。

雑誌記事やウェブなどでのマーケティング活動も重要で、通常の宣伝広告費など潤沢には使えないので、ほぼコスト無でのバイラル型マーケティングが重要になる。

OSSそのものを利用してのSIとかコンサルは直接的な売上に結びつくので分りやすい。開発者やそのOSSでの著名人がいると、安心感、信頼感が増すので営業活動も通常よりもやりやすくなる。社内での知名度なども大きな会社では重要で、社外からの引合で社内営業がそのOSSを再発見するということも少なくない。

コミュニティの人間ができることと言えば、そのOSSを利用してフィードバックをかける事くらいだが、企業に属しているのならば、OSSを社内システムないしはSIに利用し、当該OSS開発企業に有償コンサルやSIを依頼するというのも手である。

OSSは利用が進めば進むほど不具合は発見され修正されるし、機能も洗練されていくので、利用者として開発コミュニティとアライアンスを組む事は利益がある。それを企業のユーザとしてビジネスの一貫として関与することが企業人でありコミュニティの人間としてできる事かもしれない。

そのようなエコシステムをどうやって構築していくのだろうか？

簡単ではないが不可能でもないと思っている。

会社説明会

Linux Academyで会社説明会を開催した。弊社にはLA出身の技術者がいるので、OBによる会社説明会という機会を設けてもらった。20人弱の学生さんを前に簡単に仕事内容などを説明。その後、希望者と焼肉屋で懇親会を行う。学生さんがホットペッパーを片手にいろいろ電話をかけてお店を探してくれる。金曜日なのでなかなか10数人入れる店が見つからないがどうにかこうにか焼肉屋を確保できた（高木さんありがとう。助かりました）。

アルコールの力も手伝ってオープンソースに関して熱く語る。会社説明というよりオープンソースの話をいっぱいしていたような気がする。

職業の選択という難しい問題も結局はその仕事が好きか嫌いかというところに行き着くのではないかと思うのだが、20代で自分が何をしたいのかなどと明確に持っている人はそれほど多くはないと思う。わたしもそうだったような気がする。ひょっとしたら30代でも40代でもいくつになってもやりたいことなんていうのは見つからないのかもしれないけれど、それでも何かに興味を持って面白いと感じたのならそれにチャレンジすることは悪いことではない。

カーネル読書会とかのオフ会の時と違って、一応採用する側の人間のお話なのでめったなことは言えないという立場なのであるが、自分の考えることをいろいろ語ってみた。

ソフトウェアというのは機械が作るのでなく人が作る。工場が作るのではない。製造業と違うのは設備投資によって生産性向上ということはできない。モチベーションを高く保つということが最も重要な要素の一つになる。
人に対する投資は教育であり、モチベーションを高く保てるかどうかが成功の要因になる。

そんなことを新宿の焼肉屋で遅くまで語り合ったのであった。一人でも二人でもオープンソースに興味を持ってくれる人が出たら望外の喜びである。

TOMOYO Linux

横浜Linux Users Group (YLUG)の有志でやっているカーネル読書会でTOMOYO Linuxのお話を聞く。開発者が日本人だと日本語でいろいろ議論ができて非常に楽しい。今回のカーネル読書会はNTTデータさんの会議室をお借りしておこなったのだが、懇親会の会場の予約まで全ておんぶにだっこで原田さんをはじめとするNTTデータの皆様に大変お世話になった。ありがとうございました。
下記に資料があるので参照されたい。
http://sourceforge.jp/docman2/ViewCategory.php?group_id=1973&category_id=532

質疑応答が活発におこなわれたが、会場からは強くアップストリームへのマージについての要望というか激励というか愛に満ちたお言葉、コメントが多数でた。原田さんたじたじである。

確かに企業人としての立場もあるし、会社がソースコード公開を認めてくれたという点は非常に大きいのだが、コミュニティの勝手な思いとしては、TOMOYOがもっともっとカーネルコミュニティにどんどん行ってがんがんアピールしてアップストリームへとりこまれるようにがんばって欲しいと思う。勝手な思いではあるが強く思う。

一方で、企業の中でオープンソース活動をする難しさというのもあって、それは原田さんだけに限らず、日本の大手企業ではおおかれすくなかれ経験している部分なわけで、その問題は一般的な問題として考える事ができる。例えば、自社の知的財産をオープンソースにするメリット、デメリットから始まり、それの事業化戦略、そしてソースコードを公開しただけではバザールモデルにならないので、バザールにする仕組み、仕掛などが広く共有されていないと、なかなか難しい。

昨今のオープンソースブームで、Linux回りのツールをオープンソース化することの敷居は若干下ったように見える。特に大手の企業(特にハードウェアベンダないし大手ＳＩベンダーなど)でもオープンソースを事業にしている部署を作ったりしている。しかしながら企業の中では売上高等の従来の物差しではオープンソースの事業を正当化するのが非常に難しいのも事実である。

ハッカーの価値を理解しつつ経営幹部にオープンソースの生み出す価値を正当に評価してもらうように働きかけるハイブリッドは人材が必要なのであるが、現場のハッカーは、パッチを作って公開するところでエネルギーを使いつくし、社内政治の場に打ってでるというところまで正直頭がまわらないしそういう事にたけてもいない。社内のサポータ、スポンサー、あるいはパトロンみたいな人が必要なのだけどなかなかハッカーとそれらの人達とを橋渡しする人がいない。

カーネル読書会は企業からの参加者も徐々にだけど増えているので、各人が自分の上司をどう説得したとか、社内の抵抗勢力(？)とどう闘ったかとか、そういうノウハウを共有できれば、もっともっとハッカーが社内で生き易くなるのではないだろうかとか妄想は膨らむ。

ビールを飲みつつ、TOMOYO Linuxをアップストリームへマージする努力をすべきだぁ〜などと気炎を上げたのだが、それがNTTデータにとっても利益になるし価値を生むということを分り易く説明することがTOMOYOの人達にも必要だし、われわれ外野も何かお手伝いできることがないかと知恵を絞る事も必要だ。

とりあえづ、6月オタワに行ってカーネルコミュニティにデビューすべきだという事に関しては満場一致で決議されたのであった。(半分冗談だがほとんど本気)

偶然にもLinux SymposiumのCFPの締切が2月15日なので、まだ締切に間にあう。

TOMOYOがアップストリームにマージされたらビジネスとしても随分違う展開をみせることは間違いない。ぜひ、応援したい。がんばってほしい。

OSS性能・信頼性評価プロジェクト

IPA(独立行政法人情報処理推進機構)の支援をうけて実施していたオープンソースソフトウェアの性能・信頼性評価プロジェクト結果をOSS情報データベース「OSS iPedia」で公開した。

本プロジェクトはIPAの統括のもと、下記の9社によって実施した。(五十音順)
SRA OSS, Inc.日本支社、NTTデータ先端技術(株)、住商情報システム(株)、日本ヒューレット･パッカード(株)、(株)野村総合研究所、(株)日立システムアンドサービス、(株)日立製作所、ミラクル・リナックス(株)、ユニアデックス(株)

弊社もPostgreSQLやMySQLの評価で参加した。

今回のプロジェクトの詳細については下記のOSS iPediaのデータを参照したいただきたい。

２００６年度 オープンソースソフトウェア(OSS)の性能・信頼性評価の成果

これまで、PostgreSQL 8.1では8CPUまでは性能が向上することが確認されていたが、最新版8.2では、16CPUまで性能が向上することが示された。最新版MySQL 5.0.32については同様に4CPUまで性能向上することが確認された。

このOSS性能・信頼性評価プロジェクトは2004年から実施していて、今回で一応の成果をみとめて発展的に解散する。

iPediaの読み方。

下記を例に、考察データを読みといていく。
MySQLに対応した評価ツールDBT-1を利用したハードリソース変更によるパフォーマンスへの影響の考察
http://ossipedia.ipa.go.jp/capacity/EV0612260303/

DBT-1というのは旧OSDL(現在のLinux Foundation)が開発したTPC-W風のワークロード(ベンチマーク)で、CPU数を4から8に変化させてMySQL 5.0.24と5.0.32(最新版)で性能を評価した。

5.0.24では8CPUの性能が4CPUの性能より低いことが図1より読みとれる。一方、5.0.32では8CPUでの性能が向上した(図2)。しかしながら、それでもCPU数8個では十分なスケーラビリティが確保できない。

oprofileのデータをみると8CPUの場合、ロック関連で約70%の処理時間を費やしていて、ロック競合によって性能が出ていないことわかる(MySQL 5.0.24の場合)。性能改善がはかられた、MySQL 5.0.32のoprofileのデータを確認するとmutex_spin_waitという処理がトップ5から姿を消し、ロック関連処理のが約23.8%となっていて5.0.24の70%より減っているのが確認できる。それでお約2割がロック競合なので、さらなる性能向上がみこめる。

http://ossipedia.ipa.go.jp/capacity/CS0612210243/ 他に関連する性能データ(MySQLの設定ファイルやoprofileの測定データ)があるので、実際にダウンロードして確認してみてほしい。

実際のoprofileのデータを読みとくことは性能評価の定跡であるが、そのような生データが無償で公開されている意義は非常に大きいと思う。教育的価値も高い。OSSを対象とした性能評価プロジェクトであったため、商用製品の評価と違い、測定結果を自由に公開できるというのは、多くの人にとって価値があると思う。商用製品の場合、ライセンスでベンチマークの公開を禁じている場合が多いのである。

プロジェクトの裏話や想い出については別途記すかもしれない。

Rubyで習作の性能評価

うひょ〜。大変なことになった。手習いで書いた初めてのRubyプログラムが大御所によってたかって添削指導をうけている。

確かに突っ込みどころ満載のゆるゆるのコードなので、弊社のrubistからの突っ込みくらいは想定していたが、まつもとさんや弾さんの登場までは想定外であった。多くの皆様のコメントに感謝したい。

実装についても、ArrayやらHashやらSetやらいろいろあった。そこで、ちょっと性能評価をしてみた。

具体的には time ruby -rprofile でruby自前のプロファイルをとってみた。

Array#includeはコストが高い。実行時間が21秒〜24秒くらいとなっていて、そのうち12秒〜13秒をArray#includeで消費している。

表の見方なのであるが、コストのかかっている処理のトップ3を表示した。左から、全体から比率、累積実行時間(秒)、実行時間(秒)、呼び出し回数、1回あたりの実行時間(ミリ秒)(self)、1回あたりの実行時間(ミリ秒)総和、処理

下の例だと、Array#include?という処理は全体の61.49%を消費し、12.58秒かかっている。1256回呼出され、それぞれ一回あたり10.02ミリ秒(self)、16.03ミリ秒(総和)かかっている。selfと総和というのがよくわからないが。

bonlife.rb

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 61.49    12.58     12.58     1256    10.02    16.03  Array#include?
 36.90    20.13      7.55   735858     0.01     0.01  String#==
  0.93    20.32      0.19        4    47.50  5115.00  Array#each

real	0m21.438s
user	0m20.469s
sys	0m0.575s

kyagi.rb

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 59.83    12.90     12.90     1256    10.27    16.93  Array#include?
 38.82    21.27      8.37   735858     0.01     0.01  String#==
  0.46    21.37      0.10        3    33.33    56.67  IO#each

real	0m23.199s
user	0m21.565s
sys	0m0.618s

masaka.rb

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 60.37    12.11     12.11     1256     9.64    15.88  Array#include?
 39.03    19.94      7.83   735858     0.01     0.01  String#==
  0.35    20.01      0.07      628     0.11     0.16  Kernel.print

real	0m21.265s
user	0m20.073s
sys	0m0.572s

sumim.rb

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 58.37    12.93     12.93     1256    10.29    17.12  Array#include?
 38.69    21.50      8.57   735858     0.01     0.01  String#==
  1.35    21.80      0.30      629     0.48    69.51  Array#each

real	0m23.778s
user	0m22.161s
sys	0m0.604s

sumim1.rb

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 57.38    13.33     13.33     1256    10.61    18.02  Array#include?
 40.03    22.63      9.30   735858     0.01     0.01  String#==
  0.47    22.74      0.11      628     0.18    36.32  Range#each

real	0m24.673s
user	0m23.240s
sys	0m0.635s

Hashの実装はArray#includeよりコストが安い。

dan.rb

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 34.55     0.19      0.19        3    63.33    70.00  IO#each
 21.82     0.31      0.12      628     0.19     0.30  Array#each
 18.18     0.41      0.10        1   100.00   340.00  Hash#each_key

real	0m0.717s
user	0m0.561s
sys	0m0.011s

diffpkg.rb (わたしの実装)

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 34.04     0.16      0.16        3    53.33    83.33  Object#makehash
 23.40     0.27      0.11        1   110.00   220.00  Hash#each
 12.77     0.33      0.06     2553     0.02     0.02  Hash#[]=

real	0m0.632s
user	0m0.482s
sys	0m0.011s

matz.rb

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 30.23     0.13      0.13        1   130.00   240.00  Hash#each
 25.58     0.24      0.11        3    36.67    63.33  IO#each
 13.95     0.30      0.06     2553     0.02     0.02  Hash#[]=

real	0m0.482s
user	0m0.432s
sys	0m0.013s

Setでの実装も比較的コストが安い。

maoe.rb

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 41.18     0.21      0.21        3    70.00   170.00  IO#each
 15.69     0.29      0.08     1925     0.04     0.05  Set#add
 11.76     0.35      0.06      628     0.10     0.10  Kernel.print

real	0m0.709s
user	0m0.521s
sys	0m0.011s

実行のコストでいうと、matz/わたし/maoe/danの一群、anaitoが僅差、ずっと離れてbonlife/masaka/kyagi/sumimという感じである。

それぞれのコード

anaito.rb (メールでもらった)

#!/usr/bin/env ruby
# by Atsushi Naito 


def sort_list(pkg_list, file_list)
  h = Hash.new
  pkg_list.each do |key, value|
    file_list.each do |f|
      if value.include?(f)
        (h[key] ||= []) << "included."
      else
        (h[key] ||= []) << "not included."
      end
    end
  end
  h.sort_by{|key, value| key}
end

begin
  pkg_list = Hash.new
  file_list = Array.new
  ARGV.each {|filename| file_list << filename}

  ARGF.each do |line|
    key = line.chomp
    (pkg_list[key] ||= []) << ARGF.filename unless key.empty?
  end

  pkg_list = sort_list(pkg_list, file_list)
  pkg_list.each do |key, value|
    puts "#{key}\t#{value.join("\t")}"
  end

rescue Interrupt => err
rescue => err
  $stderr.puts err.message
  exit 1
end

bonlife.rb
http://d.hatena.ne.jp/bonlife/20070202/1170416653

dan.rb
http://blog.livedoor.jp/dankogai/archives/50757687.html

diffpkg.rb
http://blog.miraclelinux.com/yume/2007/02/ruby_b40b.html

kyagi.rb
http://blog.miraclelinux.com/yume/2007/02/ruby_b40b.html#comment-884779

maoe.rb
http://d.hatena.ne.jp/maoe/20070204/1170619870

masaka.rb
http://blog.miraclelinux.com/yume/2007/02/ruby_b40b.html#comment-884800

matz.rb
http://www.rubyist.net/~matz/20070202.html#p01

sumim.rb sumim1.rb
http://d.hatena.ne.jp/sumim/20070206/p1

勝手に性能評価(Lingr編)

週末にLingrを利用したチャットイベントがあったそうだ。[JTPA] Lingrイベントの顛末/My Life Between Silicon Valley and Japan

昨日のオンラインサロンは、参加者が集まるにつれてLingrが重くなってしまって残念ながら中止となりました。

実のところLingrの実装がどうなっているかは全く知らないのだが、何百人もわらわら集まってチャットをやろうという心意気が楽しい。素晴しい。やってみてスケールしなかったというのも主催者側は若干凹むかもしれないが、それもいい経験で、むしろそーゆー得難い経験を得られたと考えた方がいい。

Lingrの開発者の江島さんは、梅田さんのブログで再挑戦を表明しているので楽しみにしたい。

さて、今回の経験から江島さんら実装者の皆さんは何を学んだのだろうか？ぜひ情報公開をしてほしいと思うのだが、わたしだったらどうするか勝手に記してみたい。

わたしはネットワーク方面には全く土地勘はないのだけど、システム回りとRDBMSあたりだったら若干の経験があるので、いくつかの教訓めいたことを。

サーバーアーキテクチャの再点検、改善などをあげているが、負荷テストをまづやりたい。そこで、vmstat/iostatをおこない、CPUボトルネックになっているのか、IOボトルネックになっているのか、メモリボトルネックになっているのか、あるいはRDBMSがボトルネックになっているのかをみきわめる。

IOボトルネックなのに、CPUを追加しても意味がないし、CPUボトルネックなのにディスクを追加しても意味がない。何がボトルネックかを定量的に把握するのが一番である。

しかし、vmstatなどではシステム全体の負荷はわかってもどのプロセスに最もコストがかかっているのかという微視的な視点でのプロファイルはわからないので、oprofileを利用してシステムのどこで最もコストがかかっているかプロファイリングする。DBサーバに負荷がかかっているとしたらキュエリの実行プランを出して、適切な検索プランになっているか検討する。

負荷テストで現状の定量的な把握をおこないボトルネック解析、およびそれの対処を実装し、再度定量的に計測する。それを所望のゴールになるまで繰り返す。

上記のテストを繰り返している間は、機能はフリーズして、バグフィックス以外はチェックインしてはいけない。大規模な実験の前にバージョンアップをするというのは最もやってはいけない手なのだけど、外野(わたしの事)は勝手な事を言えるのでここの部分は聞き流してほしい。

vmstatでカーネルのCPU利用率を測定し、それが20%を越えていたらカーネルの処理にコストがかかりすぎなので、システムの実装を見なおした方がいいかもしれない。一方ユーザのCPU利用率が90%以上ならば、アプリケーションプログラムの実装を見直すいい機会になる。

どちらもoprofileのデータがチューニングする時によいヒントを提供するのでそれを利用したい。

1000クライアントを一つのPCサーバでサービスするというのは結構しんどいのではないかと想像するけど実装がどうなっているのか全く知らないので情報公開をまちたいと思う。(Lingr and Comet - 技術解説編)

いずれにせよ、データを取れデータを。(oprofileならなお可)

2月6日の追記：

「梅田サロン中止のお詫び、およびアーキテクチャ変更についての技術詳細レポート」という顛末が公開されている。

http://blog.japan.cnet.com/kenn/archives/003556.html

アーキテクチャの設計寿命

「マルチプロセッサ向けソフトウェアパラダイムとは？」で、

Alphaの開発チームはVAX開発チームの後継で、ある意味DNAを受けついでいるのだが、当時の論文(90年ごろ)で、マイクロプロセッサのスケーラビリティを、クロックの向上で10倍、アーキテクチャの進歩で10倍、マルチプロセッサで10倍、10x10x10=1000倍の性能向上を達成するとかしないとか書いてあって、感心したのを覚えている。
http://blog.miraclelinux.com/yume/2007/01/post_ab8c.html

と書いたのだが、先日たまたま下記の論文を発見した。

いまはなきDEC の技術論文集(digital technical journal)の第４巻第４号がAlpha AXPの特集号である。目次を参照されたい。

Alpha AXP Architecture
by Richard L. Sites
http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art1.pdf

この論文はDECのエンジニアリングスピリットが凝縮されている。

アーキテクチャゴールとして下記の4つをあげている。

1. 高性能
2. 寿命が長い事
3. VMSとUnixが動くこと
4. VAXおよびMIPSからの容易なマイグレーション

3、4はマーケットからの強い要請であるが、純粋な技術的なチャレンジは１の高性能と２の寿命が長い事ということになる。

アーキテクチャの寿命というのを15年から25年くらいに設定して、その期間に設計上の限界となりそうなものを注意深く避けている。

例えば32ビットのメモリアドレスは間違いなく当時の設計上の限界だったので64ビットにした。

We also considered how implementation performance should scale over 25 years. During the past 25 years, computers have become about 1,000 times faster. Therefore we focused our design decisions on allowing Alpha AXP system implementations to become 1,000 times faster over the coming 25 years.

過去25年をふりかえってみるとコンピュータは1000倍速くなった。そこでAlpha AXPシステムの実装が次の25年で1000倍速くできるように設計の決定に注力した。

In our projections of future performance, we reasoned that raw clock rates would improve by a factor of 10 over that time, and that other design dimensions would have to provide two more factors of 10.

クロックレートは10倍、それ以外の設計要素で10*10倍と推測している。

10*10倍するための設計要素の一つは、multiple instruction issue(同時に複数の命令を実行する)で、もう一つは、マルチプロセッサである。

そこでアグレッシブなmultiple issueを妨げる要素を徹底的に排除する。例えば、コンディションコード、グローバルな例外、ストリングレジスタ、遅延分岐、正確な演算例外、等々の従来のアーキテクチャにみられた要素を排除している。

また共有メモリマルチプロセッサのモデルを当初から想定している。厳密なメモリへの書きこみ順は共有メモリマルチプロセッサでは性能を限定するので、それを仮定しない。例えば、メモリA、メモリBの書きこみは、他のプロセッサからはA、Bの順ではなく、B、Aの順で見えるかもしれない。これにより高性能な共有メモリマルチプロセッサの実装が可能になる。

などなど、当時知られていた性能上の問題になりそうなものを徹底的に排除した設計になっている。

Alpha AXPが発表されてから15年。その開発はDECにとって最大のプロジェクトであった。DECという会社はなくなってしまったが、Alpha AXPで開発された、高速化技法は今も生き残っている。コンピュータアーキテクチャの設計寿命というのは正しく設計されれば15年〜25年と長いのである。

Rubyで習作

最近会社でRubyの勉強会をしていて手習でRubyのスクリプトを書いたりする。
http://blog.miraclelinux.com/asianpen/2007/02/ctrlz_bfd3.html
に触発されて、同じような事をするスクリプトをRubyで書いてみた。Ruby歴3日の初心者が書くとこんな感じになるという例として見てほしい。
繰り返しがいっぱいあるのでもっとブロックとか上手に使うとすっきりしそうな気がするのだが全然土地勘がないのでよくわからない。読者諸氏の添削を期待したい。

#!/usr/bin/env ruby
#
# by Hiro Yoshioka
# 2/2/'07: inspired by 
# http://blog.miraclelinux.com/asianpen/2007/02/ctrlz_bfd3.html

def makehash(h, f)
  while line=f.gets
    line=line.chop
    h[line]=line
  end
end

begin
  file1 = File.open(ARGV[0], "r")
  hash1 = Hash.new
  makehash(hash1, file1)
rescue
  puts 'error ARGV[0] ' + ARGV[0].to_s
  exit
ensure
  file1.close unless file1.nil?
end


begin
  file2 = File.open(ARGV[1], "r")
  hash2 = Hash.new
  makehash(hash2, file2)
rescue
  puts 'error ARGV[1] ' + ARGV[1].to_s
  exit
ensure
  file2.close unless file2.nil?
end

begin
  file3 = File.open(ARGV[2], "r")
  hash3 = Hash.new
  makehash(hash3, file3)
rescue
  puts 'error ARGV[2] ' + ARGV[2].to_s
  exit
ensure
  file3.close unless file3.nil?
end

hash1.each do |key, pkg|
  line = pkg.to_s + ', '

  line = line + if pkg == hash2[pkg] 
    "included,     "
  else 
    "not included, "
  end

  line = line + if pkg == hash3[pkg]
    "included\n"
  else
    "not included\n"
  end

  print line

end

どうでしょうか？

ISO/IEC 15408の取得

昨日下記のプレスリリースを出した。
http://www.miraclelinux.com/corp/pressroom/details/2007/0131_1.html

ミラクル・リナックス、
　　税額控除の対象である国際セキュリティ評価基準の認証を取得
-- 国内OSベンダーとして初めてのISO/IEC 15408認証取得により、
　　　　　MIRACLE LINUX導入企業のコスト削減に貢献 --

　ミラクル・リナックス株式会社(本社：東京都港区東新橋、代表取締役社長 佐藤 武、以下ミラクル・リナックス)は、 2007年1月24日付けで、国際セキュリティ評価基準「ISO/IEC 15408 情報技術セキュリティ評価基準*1（以下、ISO/IEC 15408）」の認証を取得いたしました。

中略

*1　「ISO/IEC 15408 情報技術セキュリティ評価基準」とは：
情報技術セキュリティの観点から、情報技術に関連した製品やシステムが適切に設計され、その設計が正しく実装されているかどうかを評価するためのセキュリティ評価基準です。欧米6ヶ国7機関で構成されるCCプロジェクトによって開発された共通基準(CC：Common Criteria)が基になっています。 1999年6月にISO/IEC規格として承認され、2000年7月にはJIS X 5070として制定されました。この規格によって、IT関連製品のセキュリティ機能は、様々な視点から系統的に評価できるようになりました。日本の情報処理ベンダーもこの規格に積極的に参画し、認証の取得によって安全性の高い製品やシステムの提供を推進しています。また「ISO/IEC 15408」の認証取得製品は、経済産業省が推進する情報基盤強化税制*2の対象にもなっており、国内の企業における「ISO/IEC 15408」認証の取得に拍車がかかっています。

*2　「情報基盤強化税制」とは：
高度な情報セキュリティが確保された情報システム投資を促進し、情報基盤を強化するために、個人事業者または法人が平成18年4月1日から平成20年3月31日までの間に、特定の対象設備の取得などにより、国内にある個人事業者または法人の営む事業に利用した場合に、特別償却または税額控除を認めるものです。

http://www.miraclelinux.com/products/linux/ml40/cc.html
http://www.miraclelinux.com/update/linux/security/index.html

今回MIRACLE LINUXがISO/IEC 15408を取得したので、情報基盤強化税制の適用により税額が控除できる。コスト削減になるので活用してほしい。

と、宣伝になってしまった。

15408の取得というのは非常に手間暇がかかるのであるが、それについては今回プロジェクトを担当したエンジニアがブログに書いてくれるかもしれない。