httpdstat.d スクリプトの紹介

Apache サーバを立てていると、どれくらいのアクセスが来ているか実際に 確認したくなります。そんな時 DTrace を使って http リクエストの統計を 簡単に取る事も可能です。
今回は、 DtraceToolkit の中から Apache Web Server がどれくらいの処理を受け付けて いるかモニタリングする httpdstat.d スクリプトを紹介します。
ベンチマークテストをやっている時にこのスクリプトを実行してみるのもいい ですね。

[httpdstat.d 出力サンプル]

  # httpdstat.d
  TIME                    NUM    GET  POST  HEAD TRACE
  2005 Nov 29 18:46:46     38     38     0     0     0
  2005 Nov 29 18:46:47    109    109     0     0     0
  2005 Nov 29 18:46:48    112    112     0     0     0
  2005 Nov 29 18:46:49    113    113     0     0     0
  2005 Nov 29 18:46:50    107    107     0     0     0
  2005 Nov 29 18:46:51     56     56     0     0     0
  2005 Nov 29 18:46:52      0      0     0     0     0
  2005 Nov 29 18:46:53      0      0     0     0     0
  2005 Nov 29 18:46:54     20     20     0     0     0
  2005 Nov 29 18:46:55     48     48     0     0     0
  ^C

  # httpdstat.d 30
  TIME                    NUM    GET  POST  HEAD TRACE
  2005 Nov 29 18:50:49    462    458     3     1     0
  2005 Nov 29 18:51:19    421    413     5     2     1
  2005 Nov 29 18:51:49   1361   1358     3     0     0
  ^C

Posted at 09:55午前 8 28, 2006 by Naoyuki Yamada in Sun  |  投稿されたコメント[0]

nfswizard.d スクリプトの紹介

最近は、NASサーバなどでストレージを統合する例が増えた事もあり NFS の性能監視 をする機会があると思います。そんな時は以前紹介した DtraceToolkit の中から nfswizard.d スクリプトが役立ちます。
このスクリプトは、NFS クライアントが NFS サーバに対して
- どれくらいの Read/Writeリクエストを行ったか？
- どれくらいのレスポンスで処理されているか？
- どのファイルをどれくらいアクセスしたか？
のサマリを表示します。

[nfswizard.d 出力サンプル]

# nfswizard.d
  Tracing... Hit Ctrl-C to end.
  ^C
  NFS Client Wizard. 2005 Dec  2 14:59:07 -> 2005 Dec  2 14:59:14
  
  Read:  4591616 bytes (4 Mb)
  Write: 0 bytes (0 Mb)
  
  Read:  640 Kb/sec
  Write: 0 Kb/sec
  
  NFS I/O events:    166
  Avg response time: 8 ms
  Max response time: 14 ms
  
  Response times (us):
             value  ------------- Distribution ------------- count
               128 |                                         0
               256 |                                         1
               512 |@@@                                      14
              1024 |@                                        4
              2048 |@@@@@@@                                  30
              4096 |@@@@@                                    20
              8192 |@@@@@@@@@@@@@@@@@@@@@@@                  97
             16384 |                                         0
 
  Top 25 files accessed (bytes):
     PATHNAME                                                         BYTES
     /net/mars/var/tmp/adm/vold.log                                   4096
     /net/mars/var/tmp/adm/uptime                                     4096
     /net/mars/var/tmp/adm/mail                                       4096
     /net/mars/var/tmp/adm/authlog.5                                  4096
     /net/mars/var/tmp/adm/ftpd                                       12288
     /net/mars/var/tmp/adm/spellhist                                  16384
     /net/mars/var/tmp/adm/messages                                   16384
     /net/mars/var/tmp/adm/utmpx                                      20480
     /net/mars/var/tmp/adm/ftpd.2                                     20480
     /net/mars/var/tmp/adm/ftpd.3                                     20480
     /net/mars/var/tmp/adm/ftpd.1                                     24576
     /net/mars/var/tmp/adm/ftpd.0                                     24576
     /net/mars/var/tmp/adm/lastlog                                    28672
     /net/mars/var/tmp/adm/ipf                                        61440
     /net/mars/var/tmp/adm/loginlog                                   69632
     /net/mars/var/tmp/adm/ipf.4                                      73728
     /net/mars/var/tmp/adm/messages.20040906                          81920
     /net/mars/var/tmp/adm/ipf.3                                      102400
     /net/mars/var/tmp/adm/ipf.1                                      110592
     /net/mars/var/tmp/adm/ipf.5                                      114688
     /net/mars/var/tmp/adm/ipf.2                                      114688
     /net/mars/var/tmp/adm/ipf.0                                      122880
     /net/mars/var/tmp/adm/route.log                                  266240
     /net/mars/var/tmp/adm/pppd.log                                   425984
     /net/mars/var/tmp/adm/wtmpx                                      2842624

Posted at 12:31午後 8 25, 2006 by Naoyuki Yamada in Sun  |  投稿されたコメント[0]

UltraSPARC T1 は発想の転換から生まれた(連載２)

UltraSPARC T1 は発想の転換から生まれた(連載２)

UltraSPARC T1 は従来のパイプラインの概念を変えました。これと引き替えに、多くのスレッド処理能力を手に入れました。 これを理解するためにはCPUの進化の歴史を知る必要があります。 まずは「ステージ」と「パイプライン」を解説します。 (以下の解説は厳密性に欠けるので、その点は大目にみて頂きたい。)

現在普及しているCPUはフォンノイマン型である。 このほかに、ベクトル型、ニューラルネットワーク型などがある。 フォンノイマン型は処理をいくつかに分割(ステージ)し、その繰り返しで成り立っている。 一般的には次の６ステージからなる。 (実際にはCPUごとに異なるが、理論を理解するには都合がよい。)

# I(Instruction fetch)  命令の取り出しとプログラムカウンタの更新
# D(Instruction decode) 命令の解読
# A(Address calculation) オペランドのアドレスの計算
# B(Operand fetch) オペランドの読み出し
# E(Execution) 命令の演算を実行
# W(Write/store back) 結果の格納

これを基本動作クロックごとに順次繰り返して処理を行う。

I D A B E W I D A B E W......

簡単に言えば CPU はこの繰り返しを行う装置である。 CPUのもっとも基本的な姿である。

CPU処理速度を上げる方法としてはいろいろ考えられるが、その一つの方法としてパイプラインという考えが登場した。
パイプラインの導入によって、クロックを上げることなく、処理速度を向上することができる。
全体として短時間で処理が済む。

パイプラインの例
      1 2 3 4 5 6 7 8 91011
命令1 I D A B E W
命令2   I D A B E W
命令3     I D A B E W
命令4       I D A B E W
命令5         I D A B E W
命令6           I D A B E W
      |<----------------->|

上記の例では、本来36クロック必要なところ、11クロックで済んでいる(1ステージ/1クロック換算)。

ただし、パイプラインの副作用もある。それが分岐命令である。 分岐命令があると、後続の途中までパイプラインに読み込んでいた内容は無駄になり破棄しなければならない。 このペナルティを最小限にとどめるために、分岐予測機能などをさらに組み込んでいるCPUもある。
パイプラインは多ければよいというわけではない。過ぎたるは及ばざるがごとし。
プログラムには「局所性原理」と呼ばれるものがあり、頻繁に分岐命令が実行される。 局所性原理があるからこそ、キャッシュが有効でもある。

パイプラインの次に考え出されたのが、スーパースケーラ(表記の仕方によってはスーパースカラ)である。 簡単に言えば、パイプライン構造の並列化が行われたものである。 ALU(演算ユニット)を複数もち、同時に複数の演算ステージをこなすようにした。

スーパースケーラの例
      1 2 3 4 5 6 7 8 91011
命令1 I D A B E W
命令7 I D A B E W
命令2   I D A B E W
命令8   I D A B E W
命令3     I D A B E W
命令9     I D A B E W
命令4       I D A B E W
命令10      I D A B E W
命令5         I D A B E W
命令11        I D A B E W
命令6           I D A B E W
命令12          I D A B E W
      |<----------------->|

もちろん UltraSPARC III, IV はスーパースケーラである。
スパースケーラにより処理能力を向上させることができるが、演算ユニットなどを複数持たせることから、回路が複雑になり、チップの面積も必要とする。

さて、ここまで理解すると、勘のよい方は UltraSPARC T1 の構造を想像することができる。 発想を転換し、パイプライン構造を転用して、異なるスレッドを走らせている。 今までのパイプライン構造を転用したため、設計の変更箇所が少なくて済み、開発時間を大幅に短縮できた。
またUltraSPARC T1 の仕様をよくみていただくと、スーパースケーラの文字が見つからない。
構造を単純化しcoreのチップ面積を小さくして、8coreも搭載することができた。

T1のスレッド構造をパイプライン構造的に記述すると従来とあまり変わらないように見える。

T1の例(1core分)
thread1 I D A B E W
thread2   I D A B E W
thread3     I D A B E W
thread4       I D A B E W

しかしそこには考え方に大きな違いがある。
従来のパイプライン構造では 命令1,命令2,命令3,命令4 は同じプログラムの連なりであり、関連性がある。
そして１つの CPUで処理される。
一方、UltraSPARC T1 では thread1,thread2,thread3,thread4 は別のプログラムであり、関連性がない。
そのため、Solaris 上からみた場合、個々のthreadはあたかも別々の CPU 上で動作しているかのように見える。
従来のパイプライン構造は処理時間を短くする目的で使われたが、T1 では複数のスレッドを同時に実行できる目的に使われている。

処理能力を考える上で、速く走ることが大きな仕事量とはいえないこともある。 遅くても一度に大量輸送した方が大きな仕事量ともいえる。 例えるなら今までのクロック重視のCPUは２人乗り(Dual core)のスポーツカーといえ、 T1 は32人乗り(8core x 4thread)バスといえる。 2人をA地点からB地点まで輸送するのであれば、スポーツカーの方が速いであろう。 しかし、32人を輸送する場合はどうであろうか？スポーツカーで16往復するよりは、 32人乗りバスで一度に運ぶ方が速いであろう。スポーツカーとバスに16倍の速度差はないので。

今と昔では、コンピュータの使われ方も変化してきた。 昔は一つのコンピュータでは一つの処理しかできなかった。 一つのプログラムをいかに速く処理するかに注目がおかれてきた。 現在は、マルチタスクが標準であり、平行していくつも処理をさせることが多くなっている。
Webサーバなどがその最たるものである。複数の人が同時にアクセスしてくるので いかに多くのタスク(スレッド)を処理できるかが要求される。 そのためトータルでみた場合、一つの処理に長けたパイプライン構造よりも複数の処理を こなすスレッド構造の方が優れている。 UltraSPARC T1 がWebサーバに最適な理由がここにある。
車も用途に応じて車種があるように、これからはCPUも用途に応じて選択する時代が到来した。

Posted at 03:21午後 8 24, 2006 by onodera in Sun  |  投稿されたコメント[2]

Solaris Containers Technology Architecture Guide の紹介

今回は、Solaris Containers 技術に関する Sun BluePrint を紹介します。
題名は 「Solaris Containers Technology Architecture Guide(P/N 819-6186-11)です。
この BluePrint は、単に Solaris Containers の概要を解説したものでは なく、Solaris Containers に関する実用的な内容が盛りだくさんに記載 されております。

以下は第二章の目次を抜粋したものですが、興味のあるキーワード ばかりで構成されています。

** Chapter 2: Using Solaris Containers Technology **
  Storage Configuration
    File Systems Structure
    File Systems versus Raw Devices
    Selecting DAS,NAS,SAN
    File System Types
    General File System Consolidations
    Backup and Restore
    Tape Backup
    Disk Snapshot
    
  Network Configuration
    Dynamic host Configuration Protocol
    Changing the IP Address for a Zone
    Routing
    Firewalls and Filters
    Internet Protocol Multi-Pathing and Sun Trunking
    Subnet Maks

  Printing

  Security Risks

  Resource Management
    Processor Sets, pools, and Projects
    CPU Resources
    Resource Capping Explained
    Resource Capping Guidelines
    Resource Capping and Solaris Containers Technology
    Resource Management Using Kernel Parameters
    
......

また、具体的な Solution 例として、「１筐体内に複数Zoneを立ち上げて DMZ を構成し Secure なサービスを提供する構築例」や「あるユーザ環境での Solaris Containers を使ったサーバ統合構築例」も詳細に解説されております。

Solaris Containers に興味のある方は是非参照下さい。
http://www.sun.com/blueprints/0506/819-6186.html

Posted at 09:56午前 8 22, 2006 by Naoyuki Yamada in Sun  |  投稿されたコメント[0]

X4500 について

先日リリースされた新型x64サーバー３機種(*1)ですが、どれも Sunらしい ユニークな製品で、最近の Sunの好調さを象徴すると同時に、この勢いを 加速する強力な推進エンジンとなるのは間違いなく、私個人的にも今回の 製品群に大きな期待を抱いています。

特に私が贔屓にしているのは何と言っても Sun Fire X4500 です。サー バーなのに内蔵ディスクを 48本も持ち、しかもディスク一本の 容量が 500GBもあるため、わずか４Ｕラックサイズに合計 24TBもの データを溜め込むことができるのです。これまでの Sun のサーバーは 内蔵ディスク２～４本程度でちょっと物足りないかと感じてはいたのですが、 何もここまでやるとは 恐れ入ります。専業のディスクアレイ製品達もデータ密度に無関心な訳 ではありませんが、X4500 の 12x4 二次元配置には降参です。ディスク 交換は、本体をスライドレールで引き出しトップパネルを開けて行うの ですが、1990年代センセーションを巻き起こした "引き出す冷凍" 冷蔵庫 を彷彿とさせ「今日はどの冷凍食品にする？」などとディスク交換を 行えば、味気ない労働にも不思議と心が和みます。X4500 の広告には 中○○穂さんを起用して「ほいほいっ」とディスク交換のショットなどを 期待するのですが、なにぶん広告費は嵩みます。

CPUには AMD Opteron 285, 2.6GHz デュアルコアプロセッサを２基、 計４コアを搭載しています。今回同時発表の X4600 や Blade 8000 と 比較してしまいますが、決して遅いスペックではありません。この箱に ソフトウェアをインストールすればシンプルかつ低コストなオールイン ワンのサービスが作れそうですが、後はアイデア次第です。X4500 の 大容量をいかに使いこなすか、考え出すと結構はまります。

容易に辿り着くところでは、ディスクバックアップ、テープライブラリ キャッシュ、ビデオストリーミングサーバーあたりでしょうか。

ディスクバックアップの機能は最近のメジャーなバックアップソフトは どれも持っているので比較的簡単に構築できると思います。多くのバック アップストリームを同時実行でき、さらにディスク上で差分バックアップ データを合成できるなど、汎用的かつ効果の高いソリューションです。 また手っ取り早く NFSでマウントして fssnapと ufsdump でバック アップを取るのも安価で良いと思います。

また Sun StorageTek SAM-FS(*2)を使うとニアラインストレージやテープ ライブラリを巨大な階層化ファイルシステムとして扱えるので、 Sun StorageTek テープライブラリと組み合わせ、速度・容量共これまで 以上に余裕のある、競争力の高いソリューションを構築できます。

ただ、ビデオストリーミング用途においては Web2.0という言葉と共に 懐疑的に受け止められる方も居られるのではないでしょうか。この手の サービスでは著作権問題や情報漏洩のイメージもありますし、また見る 価値のあるメディアデータがそんなに爆発的に増えるのかという疑問も あると思います。個人的意見かもしれませんが、匿名・不特定多数相手の サービスより、現実の繋がりを持つコミュニティに大きな可能性があると 思っています。

例えばクラブ活動の試合のビデオをメンバで共有し戦略を研究する、 といった使い方はどうでしょうか。熱心な中学・高校の部活では、 部員・コーチに加え保護者、ボランティア、外部指導者など、より多く の人たちに見てもらえますし、DVD をコピー回覧するやり方だと特に 社会人チームでは大変です。このようなビデオ研究によってある チームが突然強くなったりすると、他のチームも一斉に取り入れる ようになります。

他にも文章や静止画だけで伝えられないものは数多くあります。皆さんも ビデオ共有の可能性について近未来予測などしてみてはいかがでしょうか。

Sun Fire X4500 の技術詳細はこちらのホワイトペーパーをご参照ください：

http://www.sun.com/servers/x64/x4500/arch-wp.pdf

• (*1) Sun Fire x64 サーバーファミリ http://jp.sun.com/products/servers/x64/
• (*2) Sun StorageTek SAM-FS http://jp.sun.com/products/storage/software/utilization/

Posted at 10:30午前 8 15, 2006 by masahiko in Sun  |  投稿されたコメント[0]