(57)【要約】【課題】  アプリケーションによる実装を行わなくてもデータ流量の目安を取得できるようにすること。【解決手段】  デバイス（４０）とユーザプロセスとの間でメッセージを通信するためのデータ経路を有するコンピュータシステムのSTREAMS機構にて、メッセージの統計情報を採取するためのメッセージ統計情報採取モジュール（１０）は、統計情報管理領域（２０）を割り当てるためのオープンルーチン（１１）と、統計情報管理領域（２０）に統計情報を記録するためのputプロシジャ（１２）と、統計情報管理領域（２０）を解放するためのクローズルーチン（１３）と、を有する。【選択図】      図１
2009205323.tif 000002
【特許請求の範囲】
【請求項１】
デバイスとユーザプロセスとの間でメッセージを通信するためのデータ経路を有するコンピュータシステムのSTREAMS機構にて、前記メッセージの統計情報を採取するためのメッセージ統計情報採取モジュールであって、
統計情報管理領域を割り当てるためのオープンルーチンと、
前記統計情報管理領域に前記統計情報を記録するためのputプロシジャと、
前記統計情報管理領域を解放するためのクローズルーチンと、
を有するメッセージ統計情報採取モジュール。
【請求項２】
前記オープンルーチンは、
前記統計情報管理領域を割り当てる処理と、
当該メッセージ統計情報採取モジュールが挿入されるストリームのストリームヘッドのアドレスを前記統計情報管理領域に登録する処理と、
書込み側、読取り側それぞれの管理領域へのポインタを登録する処理と、
前記統計情報管理領域を統計情報管理リストに登録する処理と、
を実行することを特徴とする、請求項１に記載のメッセージ統計情報採取モジュール。
【請求項３】
前記統計情報管理領域を前記統計情報管理リストに登録する処理は、前記統計情報管理領域を前記統計情報管理リストの最後尾に登録する処理である、請求項２に記載のメッセージ統計情報採取モジュール。
【請求項４】
前記統計情報管理領域を前記統計情報管理リストに登録する処理は、前記統計情報管理領域を前記統計情報管理リストの先頭に登録する処理である、請求項２に記載のメッセージ統計情報採取モジュール。
【請求項５】
前記putプロシジャは、
メッセージサイズを測定する処理と、
前記メッセージサイズを前記統計情報管理領域に登録する処理と、
前記メッセージの種類を判別する処理と、
前記メッセージの種類を前記統計情報管理領域に登録する処理と、
を実行することを特徴とする、請求項１に記載のメッセージ統計情報採取モジュール。
【請求項６】
前記クローズルーチンは、
ストリームヘッドのアドレスをキーに、統計情報管理リストから、自身の前記統計情報管理領域を検索する処理と、
前記統計情報管理リストから前記自身の統計情報管理領域を削除する処理と、
前記自身の統計情報管理領域を解放する処理と、
を実行することを特徴とする、請求項１に記載のメッセージ統計情報採取モジュール。
【請求項７】
ユーザ空間内のユーザプロセス側のインタフェースを提供するストリームヘッドと、デバイス側のインタフェースを提供するドライバと、前記ストリームヘッドと前記ドライバとの間に設けられた複数のモジュールとを有するストリームであって、
前記ストリームヘッド直下に請求項１乃至６のいずれか１つに記載のメッセージ統計情報採取モジュールが実装されていることを特徴とするストリーム。
【請求項８】
請求項７に記載のストリームを使用して書込み側のメッセージの統計情報を採取する方法であって、
アプリケーションの実行により前記ストリームヘッドがカーネル内にメッセージを作成するステップと、
該ストリームヘッドが前記メッセージ統計情報採取モジュールへ前記作成したメッセージを渡すステップと、
前記メッセージ統計情報採取モジュールが、前記渡されたメッセージのサイズとメッセージタイプを調べて、前記統計情報管理領域の該当エリアに加算を行うステップと、
前記メッセージ統計情報採取モジュールが、直ちに、前記メッセージを下位モジュールに渡すステップと、
を有する、統計情報採取方法。
【請求項９】
請求項７に記載のストリームを使用して読取り側のメッセージの統計情報を採取する方法であって、
下位モジュールから前記メッセージ統計情報採取モジュールにメッセージを渡すステップと、
前記メッセージ統計情報採取モジュールが、前記渡されたメッセージのサイズとメッセージタイプを調べて、前記統計情報管理領域の該当エリアに加算を行うステップと、
前記メッセージ統計情報採取モジュールが、直ちに、前記メッセージを前記ストリームヘッドに渡すステップと、
を有する、統計情報採取方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイスとユーザプロセスとの間でメッセージを通信するためのデータ経路を有するコンピュータシステムにおけるSTTEAMS機構にて、データの転送媒体であるストリームメッセージ（以下、単に「メッセージ」と呼ぶ。）のサイズ、使用用途（メッセージタイプ）別に使用量の統計情報を採取する事を可能とするストリームモジュールの実装、およびその統計情報の参照方法に関する。
【背景技術】
【０００２】
ＵＮＩＸ（登録商標）とは、周知のように、ＡＴ＆Ｔベル研究所で開発されたオペレーティングシステム（以下、「ＯＳ」と略称する。）である。
【０００３】
一方、STREAMS機構とは、ＵＮＩＸ（登録商標）のカーネル機能の一部として考案されたものである。STREAMS機構は、種々のタイプのデバイスドライバと同様に、データ通信ネットワークプロトコルを実施するための事実上の業界標準フレームワークになっている。また、ストリームとは、アプリケーションプログラム（以下、単に「アプリケーション」と呼ぶ。）のようなユーザレベルプロセスとカーネル内のデバイスドライバとの間の双方向性データ経路を提供する全二重パスの事を指す。
【０００４】
その基本的概念は、設計者であるRitchie，D.M.によって記述された非特許文献１にて述べられている。現在の標準的となっている概念は、上記基本的概念のものより改良がなされている。現在のSTREAMS機構の概念は、非特許文献２に記載されている。
【０００５】
STREAMS機構を実装しているコンピュータシステムにおいて、データ送受信履歴となるメッセージ流量を調査するに当っては、これまでは、次のような方法が採られている。すなわち、メッセージ流量の調査は、アプリケーション側でデータ送受信の履歴を採取する仕組みを独自に盛り込む方法が採られている。そのため、ＯＳ機能としてはそれに相当する情報採取を行う仕組みが備わっていない。
【０００６】
また、これまでのＯＳ機能に実装されているメッセージの統計情報としては、ＯＳ全体を対象としたメッセージの割り当て／解放の情報を採取しているものである。その結果、各ストリーム単位、かつメッセージの流量という観点での統計情報採取の仕組みは実装されていない。
【０００７】
尚、本発明と関連する先行技術文献も種々知られている。例えば、特許文献１（特開平１０−２２２３８２号公報）は、ＯＳの持つ優先度をデバイスドライバを構成する各モジュールの処理に反映することにより、優先度に応じた効率的な処理の実行を可能とした「デバイスドライバ実装方式」を開示している。特許文献１には、ストリームスヘッドとストリームスドライバとの間にストリームスモジュールが組み込まれることが記載されている。また、特許文献１には、ストリームスモジュールとは、ストリームスヘッドとストリームスドライバの間で受け渡されるストリームスメッセージに対して、加工処理を行う要素であることが記載されている。さらに、特許文献１には、ストリームスモジュールは、１つのストリームスに対して複数組み合わせて使用でき、また、ＯＳ動作中に動的に組み込みおよび削除できることが記載されている。
【０００８】
また、特許文献２（特開平９−２１８８４４号公報）は、フレームワークの変更を必要とせず、それぞれの機能の基礎的な識別性を意識せずに、ＳＴＲＥＡＭＳがいろいろなモジュール又はドライバの機能を実行することを可能にした「ダイナミック機能置換を有するデータ構造」を開示している。この特許文献２は、Streamsドライバでの、トレーシング、デバッギングとパフォーマンスの測定について開示している。
【０００９】
【非特許文献１】“A Stream Input Output System,” AT&T Bell Laboratories Technical journal, Oct. 1984, Vol.63, No8, Part 2, pp.1897-1910.（日本語訳：石田晴久監修、長谷部紀元、清水謙多郎訳、“ストリーム入出力システム”、『UNIX（登録商標）原典』、パーソナルメディア、1986，pp.365-379
【非特許文献２】『UNIX（登録商標）カーネルの設計』（Maurice J. Bach著、坂本文・多田好克・村井純訳、共立出版、1990）pp291-297
【特許文献１】特開平１０−２２２３８２号公報（図１７、段落０００７）
【特許文献２】特開平０９−２１８８４４号公報（段落００５３）
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上述したように、これまでは、カーネル内に存在する各ストリームに対して、どれだけのデータのやりとりがあったかの統計を確認する手段がない。その為、データの流量に関してはアプリケーション側にて統計情報を採取する仕組みを盛り込む方法が採られている。
【００１１】
また、障害や性能問題を解決するＯＳの保守部門において、メッセージ流量の多いストリームやサイズの大きなメッセージを扱っているストリームを容易に特定する手段が実装されていない。
【００１２】
なお、上記特許文献１は、ただ単に『ストリームモジュールとは何たるか』を説明しているに過ぎない。
【００１３】
一方、上記特許文献２では、『ストリームドライバ』の機能の一部として、パフォーマンス測定のルーチンを持っている。これはストリームドライバの機能の一部であり、ストリームドライバとしての本来の動作ルーチンも存在する事となる。また、ストリームドライバであるため、該当ドライバをオープンした場合のみに、該当ストリームのみで、上記パフォーマンス測定ルーチンが機能することとなる。
【００１４】
したがって、本発明の課題は、アプリケーションによる実装を行わなくてもデータ流量の目安を取得できる、メッセージ統計情報取得モジュールを提供することにある。
【００１５】
本発明の他の課題は、ＯＳ保守部門においても、メッセージ流量の多いストリームやサイズの大きなメッセージを扱っているストリームを容易に特定できる、メッセージ統計情報取得モジュールを提供することにある。
【００１６】
本発明の更に他の課題は、各ストリームにおいて、そのモジュールを使用するかどうかを状況に合わせて選択する事が可能な、メッセージ統計情報取得モジュールを提供することにある。
【課題を解決するための手段】
【００１７】
本発明によれば、デバイスとユーザプロセスとの間でメッセージを通信するためのデータ経路を有するコンピュータシステムのSTREAMS機構にて、メッセージの統計情報を採取するためのメッセージ統計情報採取モジュールであって、統計情報管理領域を割り当てるためのオープンルーチンと、統計情報管理領域に統計情報を記録するためのputプロシジャと、統計情報管理領域を解放するためのクローズルーチンと、を有するメッセージ統計情報採取モジュールが得られる。
【発明の効果】
【００１８】
アプリケーション側にてデータ送受信の統計情報を採取する仕組みを実装していなくても、カーネル側にてメッセージの統計情報を採取できる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
【００２０】
図１を参照して、本発明の第１の実施の形態に係るメッセージ統計情報採取モジュール１０について説明する。
【００２１】
図１は、メッセージ統計情報採取モジュール１０のドライバエントリルーチンを示す図である。メッセージ統計情報採取モジュール１０は、デバイス４０（図３参照）とユーザプロセスとの間でメッセージを通信するためのデータ経路を有するコンピュータシステムのSTREAMS機構にて、メッセージの統計情報を採取するためのものである。
【００２２】
周知ように、コンピュータシステムは、入力装置と、プロセッサと、記憶装置と、出力装置とを有する。記憶装置は、プログラムやデータを記憶する。入力装置はデータを記憶装置に書き込む。出力装置は記憶装置からデータを読み出す。プロセッサは、記憶装置に記録されたプログラムに従って、記憶装置に記憶されたデータを処理する。
【００２３】
STREAMS機構とは、前述したように、ＵＮＩＸ（登録商標）のカーネル機能の一部として考案されたものある。STREAMS機構は、種々のタイプのデバイスドライバと同様に、データ通信ネットワークプロトコルを実施するための事実上の業界標準フレームワークになっている。
【００２４】
図示のメッセージ統計情報採取モジュール１０（ドライバエントリルーチン）は、オープンルーチン１１と、putプロシジャ１２と、クローズルーチン１３とから構成されている。
【００２５】
図示の例では、オープンルーチン１１は、xxx_open()から成り、putプロシジャ１２は、xxx_wput()から成り、クローズルーチン１３は、xxx_close()から成る。尚、putプロシジャ１２であるxxx_wput()は、write（書込み）側の例を示し、read（読取り）側はxxx_rput()とする。read（読取り）側の処理概要は、write（書込み）側と同様のため、省略する。
【００２６】
ここで、接頭辞の“xxx_”は、そのストリームモジュールのモジュール名であり、その文字列はそのモジュール名にふさわしいものとする。
【００２７】
なお、上記各ドライバエントリルーチンの形式については、UNIX（登録商標） System V Relese4のものを例としている。以下、同様である。
【００２８】
オープンルーチン（xxx_open()）１１は、統計情報管理領域２０（図２参照）の割り当て処理と、当該モジュール１０が挿入されるストリームのストリームヘッド５１（図３参照）のアドレスを統計情報管理領域２０に登録する処理と、write側、read側のq->q_ptrにそれぞれの管理領域２３、２４（図２参照）へのポインタを登録する処理と、上記管理領域２０を統計情報管理リスト８０（図４参照）に登録する処理と、を実行する。
【００２９】
putプロシジャ（xxx_wput()）１２は、メッセージサイズを測定する処理と、メッセージサイズを統計情報管理領域（write側）２３（図２参照）に登録する処理と、メッセージの種類（メッセージタイプ）を判別する処理と、メッセージの種類を統計情報管理領域（write側）２３に登録する処理と、を実行する。
【００３０】
クローズルーチン（xxx_close()）１３は、ストリームヘッド５１（図３）のアドレスをキーに、統計情報管理リスト８０（図４参照）から、自身の統計情報領域を検索する処理と、統計情報管理リスト８０から自身の統計情報管理領域を削除する処理と、自身の統計情報管理領域を解放する処理と、を実行する。
【００３１】
図２は、実際にメッセージ統計情報採取モジュール１０が統計情報を記録するための、統計情報管理領域２０を示す図である。統計情報管理領域２０は、オープンルーチン（xxx_open()）１１により割り当てられ、putプロシジャ（xxx_wput()）１２（read側の場合はxxx_rput()）により統計情報が記録され、クローズルーチン（xxx_close()）１３によって解放される。
【００３２】
図２に示されるように、統計情報管理領域２０は、次の管理領域へのポインタ格納領域２１と、挿入されたストリームの、ストリームヘッド５１（図３参照）のアドレス格納領域２２と、write側管理領域２３と、read側管理領域２４とからなる。
【００３３】
なお、本実施の形態に係るメッセージ統計情報採取モジュール１０は、ドライバエントリルーチンであるサービスプロシジャを実装していない。つまり、本実施の形態に係るメッセージ統計情報採取モジュール１０は、STREAMSユーティリティルーチンであるputq()を行わないモジュールである。そのため、メッセージの転送効率に負担をかけることが極めて少ない。
【００３４】
次に、図３乃至図６を参照して、本実施の形態に係るメッセージ統計情報採取モジュールについて説明する。
【００３５】
図３は、本発明に係るメッセージ統計情報採取モジュール６０をストリームに挿入する前と後の動作を表す図である。図３において、（Ａ）はメッセージ統計情報採取モジュール６０を挿入する前のストリーム５０を示し、（Ｂ）はメッセージ統計情報採取モジュール６０’が挿入された後のストリーム７０を示し、（Ｃ）は挿入すべきメッセージ統計情報採取モジュール６０を示す。
【００３６】
前述したように、ストリームとは、アプリケーションのようなユーザレベルプロセスとカーネル内のデバイスドライバ５２との間の双方向性データ経路を提供する全二重パスの事を指す。換言すると、ストリームとは、ユーザ空間３０で動作するプログラム（アプリケーションプログラム）であるプロセス（図示せず）が、物理または論理装置であるデバイス４０を制御するための、デバイスドライバ構築手法である。
【００３７】
図３（Ａ）に示されるように、挿入前のストリーム５０は、ユーザ空間３０とデバイス４０との間のカーネル空間にある。挿入前のストリーム５０は、ストリームヘッド５１と、ドライバ５２と、ストリームヘッド５１とドライバ５２との間に配置された複数のモジュール５３、５４、・・・（モジュール１、モジュール２、・・・）とから成る。ストリームヘッド５１は、プロセス（ユーザ空間３０）側のインタフェースを提供する。ドライバ５２は、デバイス４０側のインタフェースを提供する。ストリームヘッド５１とドライバ５２と複数のモジュール５３、５４、・・・の各々は、書込み用待ち行列ＷＱ（Write Queue）と読取り用待ち行列ＲＱ（Read Queue）とから成る。書込み用待ち行列ＷＱはストリームヘッド５１からドライバ５２への待ち行列であり、読取り用待ち行列ＲＱはドライバ６２からストリームヘッド６１への待ち行列である。
【００３８】
図３（Ｃ）に示されるように、挿入すべき統計情報採取モジュール６０は、書込み用待ち行列ＷＱと読取り用待ち行列ＲＱとから成る。
【００３９】
図３（Ｂ）に示されるように、挿入後のストリーム７０も、ユーザ空間３０とデバイス４０との間のカーネル空間にある。挿入後のストリーム７０は、ストリームヘッド５１と、ドライバ５２と、統計情報採取モジュール６０’と、統計情報採取モジュール６０’とドライバ５２との間に配置された複数のモジュール５３、５４、・・・（モジュール１、モジュール２、・・・）とから成る。すなわち、統計情報採取モジュール６０’は、ストリームヘッド５１直下に実装される。
【００４０】
とにかく、挿入後のストリーム７０では、ストリームヘッド５１直下にメッセージ情報採取モジュール６０’が挿入される事となる。ＯＳ機能としてメッセージの流量を採取する仕組みを実現するにあたり、ストリームモジュール（メッセージ情報採取モジュール６０’）にて実装する事により、各ストリームドライバ単位でそのモジュール６０’の利用を選択できる事となる。各ストリーム単位で、メッセージの統計情報を把握することができる。
【００４１】
挿入の手段には、次の２通りがある。
【００４２】
第１の挿入手段では、autopushコマンドにより、事前に挿入が必要なドライバを指定しておき、ドライバオープン時に自動的に該当モジュールを挿入する。
【００４３】
第２の挿入手段では、strchgコマンドを用い、“strchg-h［統計情報採取モジュール名］<［ドライバのデバイスファイル名］”を実行することにより、特定のオープン中のストリームに挿入する。
【００４４】
図４は、統計情報管理領域の管理方法を表す図である。図１のオープンルーチン（xxx_open()）１１にて、統計情報管理リスト８０を先頭として、新たに割り当てられた統計情報管理領域２０−Ｎを統計情報管理リスト８０の最後尾に登録を行う。
【００４５】
図５（Ａ）は、メッセージ統計情報採取モジュールによる統計情報の採取手順（write側）を表す図である。まず、アプリケーションによる（１）write()，putmsg()，ioct1()の実行があると、ストリームヘッド５１はカーネル内にメッセージを作成し、（２）ストリームヘッド５１からのputnext(q，mp)により、下位モジュール、つまりメッセージ統計情報採取モジュール６０’にそのメッセージを渡す。メッセージ統計情報採取モジュール６０’は、（３）渡されたメッセージのサイズ、メッセージタイプを調べ、自身のキューのq->q_ptrにポインタが張られている統計情報管理領域２０−Ｎの該当エリアに加算を行う。メッセージ統計情報管理モジュール６０’は、その後直ちに、（４）putnext(q，mp)を実施し、下位モジュール５３（モジュール１）へメッセージを渡す。
【００４６】
図５（Ｂ）は、図５（Ａ）の処理（３）の詳細を示す図である。
【００４７】
図６（Ａ）は、統計情報採取モジュールによる統計情報の採取手順（read側）を表す図である。まず、（５）下位モジュール５３（モジュール１）からのputnext(q，mp)の実行があると、上位モジュール、つまりメッセージ統計情報採取モジュール６０’にそのメッセージを渡す。メッセージ統計情報採取モジュール６０’は、（６）渡されたメッセージのサイズ、メッセージタイプを調べ、自身のキューのq->q_ptrにポインタが張られている統計情報管理領域２０−Ｎの該当エリアに加算を行う。メッセージ統計情報管理モジュール６０’は、その後直ちに、（７）putnext(q，mp)を実施し、ストリームヘッド５１へメッセージを渡す。
【００４８】
図６（Ｂ）は、図６（Ａ）の処理（６）の詳細を示す図である。
【００４９】
このように、ストリームヘッド５１直下にメッセージ統計情報採取モジュール６０’を実装することで、アプリケーション側にてデータ送受信の統計情報を採取する仕組みを実装していなくても、カーネル側にて統計情報を採取できる。
【００５０】
ＯＳ保守部門においても、障害／性能調査を行う際、どのストリームに多量のメッセージ送受信があったのか、どのストリームが大きなサイズのメッセージを扱っているのかの把握が容易になる。
【００５１】
統計情報採取を、ストリームモジュール（メッセージ統計情報採取モジュール６０’）にて実現することにより、各ストリームドライバ単位に、そのモジュール６０’を使用するかどうかの選択が可能になる。
【００５２】
また、採取した統計情報の出力については、図４で示した統計情報管理リスト８０から、各統計情報採取領域を手操りその内容を出力するコマンドを用意し、標準出力に表示させる。もしくは、カーネルのデバック機能の一部として、同様の操作ができるサブコマンド等を用意し、参照するものとする。
【００５３】
次に、統計情報管理領域の他の登録方法について説明する。
【００５４】
本例の登録方法は、統計情報管理リスト８０に、統計情報管理領域をリンクリストとして登録する際の登録方法が異なる点を除いて、図４に図示した管理方法と同様の動作をする。
【００５５】
本例の登録方法は、各リスト８０上に既に統計情報管理領域が登録されている場合、リンクリスト８０上の先頭に統計情報管理領域を登録する方法である。
【００５６】
図３に示した、統計情報管理リスト８０上の最後尾に統計情報管理領域２０−Ｎを登録する方法においては、各リンクリスト８０上のセルは時間順に並ぶという利点がある。しかしながら、図３に示した登録方法では、セルを登録する際に、統計情報管理リスト８０の先頭からネクスト領域をたぐっていき、最後尾のセルを特定するだけの手間を要する。これに対して、本例に係る登録方法の場合、各リスト８０上に登録する際の効率化が期待できる。
【００５７】
以上、本発明について好ましい実施の形態について説明してきたが、本発明は上述した実施の形態に限定されず、本発明の趣旨（主題）を逸脱しない範囲内で種々の変形・変更が可能なのは勿論である。例えば、統計情報採取領域に統計情報を登録する動作を行うルーチンを別に作成して実装しても良い。
【図面の簡単な説明】
【００５８】
【図１】本発明の第１の実施の形態によるメッセージ統計情報採取モジュールのドライバエントリルーチンを示す図である。
【図２】実際にメッセージ統計情報採取モジュールが統計情報を記録するための、統計情報管理領域を示す図である。
【図３】本発明のメッセージ統計情報採取モジュールをストリームに挿入する前と後の動作を表す図である。
【図４】統計情報管理領域の管理方法を表す図である。
【図５】メッセージ統計情報採取モジュールによる統計情報の採取手順（write側）を表す図である。
【図６】メッセージ統計情報採取モジュールによる統計情報の採取手順（read側）を表す図である。
【符号の説明】
【００５９】
１０    メッセージ統計情報採取モジュール
１１    オープンルーチン
１２    putプロシジャ２
１３    クローズルーチン
２０、２０−１、２０−２、２０−Ｎ    統計情報管理領域
３０    ユーザ空間
４０    デバイス
５０    挿入前のストリーム
５１    ストリームヘッド
５２    ドライバ
５３、５４    モジュール
６０、６０’    メッセージ統計情報採取モジュール
７０    挿入後のストリーム
８０    統計情報管理リスト
【図１】
2009205323.tif 000003
【図２】
2009205323.tif 000004
【図３】
2009205323.tif 000005
【図４】
2009205323.tif 000006
【図５】
2009205323.tif 000007
【図６】
2009205323.tif 000008