■日本語を含むメールを見たい場合
mail -> X
mailx -> O : ただし、./mbox に保存されたのを見るときは、mail -f
■ユーザ毎の設定ファイル
local.login などのスケルトンの置き場所
/etc/skel/
/etc/default/login にユーザのログイン設定があるが、指定できるものは限定されている。
TIMEZONE, PATH, ULIMIT など
使用されるファイル
sh系 : /etc/profile => ~/.profile
csh系 : /etc/.login => ~/.login => ~/.cshrc
■システム基本設定の場所
/etc/default/init に タイムゾーン、ファイルマスク、言語 の設定がある。
TZ=Japan
CMASK=022
LANG=ja
これは、init プロセスの設定ではあるが、すべてのプロセスがinitから派生するので、
この設定を引き継ぐことになる。問題が出るのは、FTPでの日付がうまく取れないなど。
LANGの方は消してしまって、ログイン設定で指定したほうがよい。
参考：
/etc 回りの設定
Solaris8インストール
システムデフォルトファイル
2009年2月20日金曜日
JNA でのLibrary
StandAloneの場合は、以下のような変数で指定する。
-Djava.library.path=xxxx
-Djna.library.path=yyyy
指定した場所に xxxx/aaa.dll のようにライブラリがあると読み込んでくれるのだが、
依存する別のライブラリがあると、うまく読み込めないことがあるようだ。
その場合に使用するのが、
NativeLibLoader
らしい、ゲーム関連の JOGL/JOAL で使用されているとのこと。
FFMPEGをJNAから使おうとして苦労している。
-Djava.library.path=xxxx
-Djna.library.path=yyyy
指定した場所に xxxx/aaa.dll のようにライブラリがあると読み込んでくれるのだが、
依存する別のライブラリがあると、うまく読み込めないことがあるようだ。
その場合に使用するのが、
NativeLibLoader
らしい、ゲーム関連の JOGL/JOAL で使用されているとのこと。
FFMPEGをJNAから使おうとして苦労している。
2009年2月14日土曜日
OpenSolaris の zone ではまる
OpenSoraris1108をインストールしたマシンにZONEを入れたのだが、いつのまにかdefautl の動作が変更になっていて、迷路にはまり込んでしまった。
旧来の設定
default => set brand=native
現在の設定
default => set brand=ipkg
何が変わるかというと、nativeの場合はGlobalのdirのいくつかが共有となるが、ipkgでは分離されて、共有がない。マニュアルやman,helpなどでは、defaultはnativeのように書かれていたが、実際はこの「ipkg」となっていた。(省略した場合はSunのDefaultになるとあって、以前の資料やWebの情報では、それがNativeであった)
完全に分離する指定に比べるとDiskサイズが節約なるようで、zoneごとにversionを分離できる点がよいようだ。ただし、このipkg形式だと、コマンド類が本体のsubsetになっていて、たとえば、pkgadd などは存在しない。pkg の方を使えということらしい。
旧来の設定
default => set brand=native
現在の設定
default => set brand=ipkg
何が変わるかというと、nativeの場合はGlobalのdirのいくつかが共有となるが、ipkgでは分離されて、共有がない。マニュアルやman,helpなどでは、defaultはnativeのように書かれていたが、実際はこの「ipkg」となっていた。(省略した場合はSunのDefaultになるとあって、以前の資料やWebの情報では、それがNativeであった)
完全に分離する指定に比べるとDiskサイズが節約なるようで、zoneごとにversionを分離できる点がよいようだ。ただし、このipkg形式だと、コマンド類が本体のsubsetになっていて、たとえば、pkgadd などは存在しない。pkg の方を使えということらしい。
2009年2月6日金曜日
フォーバルセミナー
フォーバルの社長のセミナーに出席したので、聞いたことをまとめる。
社長：大久保秀夫
日時：2009/01/29(木) 15:00-16:30
場所：飯田橋 ホテルメトロポリタンエドモント
＊25歳で会社を興し、日本最短記録でJASDAQ上場を果たした人
話の概要：
物売りから事売りへの転換
商品中心から、顧客の関心事の解決(Solution)へ
増収増益を10年以上続ける社長100人の共通点
・８つの特徴
ビジョンを持っている：5^10年後のこと 思わないとことはできない
会社にNo2がいる：有能でしっかりを仕事をこなす人
時間がある：No2にまなせられるから
捨てる勇気：ダメな事業は切る
細かいことには口を出さない：
外部にパートナー：ほんとの本音を言えるのは外部の人
見えない存在を信じている：孫正義 7人の恩人
利他主義：社会貢献
・１１の行動
とにかく考えている
ニーズを考える：シーズより顧客が困っていることを考える
考えたアイデアを即実行はしない：人に聞きまくる
小さいことに目が行く：SB孫社長 業務日報は毎日必ず目を通す、わたみ渡辺社長 全店舗の売上、全クレームをチェック
１ランク上の会社をリサしている：オペレーションを調べる
部下の報告書をそのままでは信頼しない：必ず自分で確かめる ユニー社長 現場で把握する
自分の会社のボトルネックを知っている：悪い例 AVEX(浜崎あゆみの次が、、、)
顧客満足を考える：
自社の強みを知っている：強いことを伸ばす
次の一手を考えている：成功は続かない
違和感のあることはしない：自分の器を超えることはしない
・４つの行動パターン
トップ自ら段取りする：大きい仕事は自分でやる
人間本能の活用：お金、勝負、メリハリ
チェック機能がすごい：予実差異の分析 真中のプロセス 行動管理 データ化
業務提携がうまい：できる会社と組む
・その他
凡事徹底：「こんなことくらい」が会社を滅ぼす
社員章にこだわる(外国人から見た日本企業の印象)
全員と握手する
相性の判断基準：人相と明元素
温顔無敵
明るく、元気で、素直
社長：大久保秀夫
日時：2009/01/29(木) 15:00-16:30
場所：飯田橋 ホテルメトロポリタンエドモント
＊25歳で会社を興し、日本最短記録でJASDAQ上場を果たした人
話の概要：
物売りから事売りへの転換
商品中心から、顧客の関心事の解決(Solution)へ
増収増益を10年以上続ける社長100人の共通点
・８つの特徴
ビジョンを持っている：5^10年後のこと 思わないとことはできない
会社にNo2がいる：有能でしっかりを仕事をこなす人
時間がある：No2にまなせられるから
捨てる勇気：ダメな事業は切る
細かいことには口を出さない：
外部にパートナー：ほんとの本音を言えるのは外部の人
見えない存在を信じている：孫正義 7人の恩人
利他主義：社会貢献
・１１の行動
とにかく考えている
ニーズを考える：シーズより顧客が困っていることを考える
考えたアイデアを即実行はしない：人に聞きまくる
小さいことに目が行く：SB孫社長 業務日報は毎日必ず目を通す、わたみ渡辺社長 全店舗の売上、全クレームをチェック
１ランク上の会社をリサしている：オペレーションを調べる
部下の報告書をそのままでは信頼しない：必ず自分で確かめる ユニー社長 現場で把握する
自分の会社のボトルネックを知っている：悪い例 AVEX(浜崎あゆみの次が、、、)
顧客満足を考える：
自社の強みを知っている：強いことを伸ばす
次の一手を考えている：成功は続かない
違和感のあることはしない：自分の器を超えることはしない
・４つの行動パターン
トップ自ら段取りする：大きい仕事は自分でやる
人間本能の活用：お金、勝負、メリハリ
チェック機能がすごい：予実差異の分析 真中のプロセス 行動管理 データ化
業務提携がうまい：できる会社と組む
・その他
凡事徹底：「こんなことくらい」が会社を滅ぼす
社員章にこだわる(外国人から見た日本企業の印象)
全員と握手する
相性の判断基準：人相と明元素
温顔無敵
明るく、元気で、素直
案ずることと成すこと
「案ずるより生むが易し」とはよく言われることだが、日々の開発においてコードの「生成」に対して「案ずる」ことで費やす時間は結構大きい。特に対象が個別の業務処理ではなく、基盤部分(フレームワークやライブラリなど)である場合はそれが顕著である。デザインの要素が入ると生産性が大きく下がるという話を聞いたことがあるが、規模が大きな業務アプリケーション開発では、人員を増やしてのコード作成フェーズに入った場合に作業者の手が止まらないように、デザインすべきこと(考えて決定すべきこと)を、前もって終えておく必要がある。個別の作業者の作業は仕様を実現するように与えられた基盤の上でコードを組立て、テストをすることであるのだから。
では、デザインフェーズでの決定に時間がかかる要因は何であろうか？それを明らかにするのが本書の目的である。
１．本書でのデザインの定義
デザインとは、ラテン語の[designare]が語源であり、意味は「計画を記号に表わす」ことである。つまり、ある問題を解決するために思考・概念の組み立てを行い、されを様々な媒体に応じて表現することと解すことができる。(wikipedia)
多くの言葉は、狭い意味で使用される場合と、広い意味で使用される場合があるが、デザインの場合もこれが当てはまる。建築を例にすると、設計図を作成することが狭い意味でのデザインであり、部品展開して材料や道具を明らかにし、作成工程の立てて人員や資材などの調達を計画することが広い意味でのデザインとなる。
本書では「デザイン」という言葉をソフトウェアの「システム設計」に限定して話を進める。システム設計において必要となる事柄には、以下のようなものがある。
・要件や仕様を実現するための
・基盤部分の調査、選定、作成、テスト
・業務機能実装のための要素分解と作業量見積もり
・人員や資材などの調達計画の作成
・開発環境および作業要領の作成
・工程計画の作成
・基盤部分の作成においての
・各種規約類の整理
・共通ライブラリの作成
・フレームワークの作成
２．デザインのメカニズム
多様体的な見方：地図では、都市というような限定した場所を示す場合は平面に表示するメルカトル図法が適しているが、地球や宇宙というような平面とはとらえられない場所では、他の方式を採用する方が妥当となる場合がある。デザインにおいても、マクロ的な観点でのアプローチやアウトプットは、ミクロ的な観点でのそれとは異なるのも十分にありうることである。
２－２．マクロ的観点
マクロ的な観点から「システム設計」の流れを記すと以下のようになる。この内、最初の3件は「システム分析」と呼ばれることが多い。
・把握：何をどうしたいのかという要件、仕様の抽出
・分離：要件、仕様を基盤共通、業務共通、業務固有へと分離
・確認：実現可能性の調査、使用可能は製品や部品などの調査
・作成：基盤部分およびモデルとなる業務要素
・計画：作業計画
２－３．ミクロ的観点
ミクロ的な観点では、個々の作業ごとにアプローチやプロセス、およびアウトプットがあることになる。ここでは、基盤部分のライブラリ作成について記す。
・課題の把握：何をどうすればいいのか
・類似コードの調査：すでの類似のものがある、流用できないか、拡張するだけですまないか
・作成場所(クラスやパッケージ)の選定、作成
・コードの作成とテスト：狭義のデザインには実装は入らない。それは建築などでは個々の部品が実在しており、その機能性や外観が分かっており、実際の組み立てをしなくとも計画を作成できるからである。ソフトウェアの場合にはこれが当てはまらない場合が多い。
それぞれのステップにおいて、「探し、考え、比較し、決定する」ことが求められるが、これが対象により作業時間が大幅に異なってくる要因となる。だからといってこの部分を仮決定のままにしておくことは許されない、後の作業に大きな影響をあたえることになるためである。
３．決定を遅らせる要因
多くの場合、実装そのものが困難な場合は少数であり、以下のようなことを決定するための材料が不足していることが、決定を遅くする要因になると想定される。
・最適ゴールの悩み：
そもそも、要求されていることの解決(対処)が妥当なのか
ミクロ的には必要に見えるが、マクロ的にとらえれと別のアプローチの方がすぐれていないか
それを採用するとそもそもの要求が無意味や不要にならないか
・重複の悩み：
すでに類似のものがあり、流用できるのではないか
車輪をもう一度発明したくない
・最適配置の悩み：
作成するものをどこに配置するのがいいのか
とくに作成するものが公開仕様を持つ場合は顕著
配置の変更が公開仕様の変更になってしまい、影響が大きくなるため
・最適単位の悩み：
どういう単位で公開するべきか
大きめの機能モジュールとしてか、小さめのライブラリやユーティリティとしてか
単位の変更が公開仕様の変更になっていしまうため
・効率の悩み：
処理効率が悪くならないか
・拡張性の悩み：
将来の拡張の妨げにならないか
・再利用の悩み：
共通基盤として利用され続けられるのか
４．決定の重さ
決定事項には重い・軽いの別がある。遅くなりがちなのはほとんどの場合、重い決定事項であるといえる。
例えば、システムを作成する場合に、「公開仕様を限定した部品同士の組合せ」としてデザインした場合、個々の部品の実装は後回しにしたり、仮組しておいて後で取り換えるなどの融通が効く。しかし、この公開仕様部分の決定を変更することはコストが高くなる。つまり、この仕様の決定は、部品内部の変更に比較すれば重いものになる。つまり、ソフトウェア設計において「重い、軽い」は、後から簡単に手直しできるか、手直しには多くの影響を招くかの違いが大きいといえる。
Javaなどのクラスという定義要素をもつ場合においては、以下のようなものがある。
簡単に手直しできるもの：影響が限定的なもの
名称の変更：名称をAPI仕様にしていない場合
公開仕様を固定したモジュールの取替え、組直し
Private要素の移動や変更
大きな影響をもたらすもの：影響が大きいもの
公開仕様の変更：APIや機能の変更
Public要素の移動や変更
では、デザインフェーズでの決定に時間がかかる要因は何であろうか？それを明らかにするのが本書の目的である。
１．本書でのデザインの定義
デザインとは、ラテン語の[designare]が語源であり、意味は「計画を記号に表わす」ことである。つまり、ある問題を解決するために思考・概念の組み立てを行い、されを様々な媒体に応じて表現することと解すことができる。(wikipedia)
多くの言葉は、狭い意味で使用される場合と、広い意味で使用される場合があるが、デザインの場合もこれが当てはまる。建築を例にすると、設計図を作成することが狭い意味でのデザインであり、部品展開して材料や道具を明らかにし、作成工程の立てて人員や資材などの調達を計画することが広い意味でのデザインとなる。
本書では「デザイン」という言葉をソフトウェアの「システム設計」に限定して話を進める。システム設計において必要となる事柄には、以下のようなものがある。
・要件や仕様を実現するための
・基盤部分の調査、選定、作成、テスト
・業務機能実装のための要素分解と作業量見積もり
・人員や資材などの調達計画の作成
・開発環境および作業要領の作成
・工程計画の作成
・基盤部分の作成においての
・各種規約類の整理
・共通ライブラリの作成
・フレームワークの作成
２．デザインのメカニズム
多様体的な見方：地図では、都市というような限定した場所を示す場合は平面に表示するメルカトル図法が適しているが、地球や宇宙というような平面とはとらえられない場所では、他の方式を採用する方が妥当となる場合がある。デザインにおいても、マクロ的な観点でのアプローチやアウトプットは、ミクロ的な観点でのそれとは異なるのも十分にありうることである。
２－２．マクロ的観点
マクロ的な観点から「システム設計」の流れを記すと以下のようになる。この内、最初の3件は「システム分析」と呼ばれることが多い。
・把握：何をどうしたいのかという要件、仕様の抽出
・分離：要件、仕様を基盤共通、業務共通、業務固有へと分離
・確認：実現可能性の調査、使用可能は製品や部品などの調査
・作成：基盤部分およびモデルとなる業務要素
・計画：作業計画
２－３．ミクロ的観点
ミクロ的な観点では、個々の作業ごとにアプローチやプロセス、およびアウトプットがあることになる。ここでは、基盤部分のライブラリ作成について記す。
・課題の把握：何をどうすればいいのか
・類似コードの調査：すでの類似のものがある、流用できないか、拡張するだけですまないか
・作成場所(クラスやパッケージ)の選定、作成
・コードの作成とテスト：狭義のデザインには実装は入らない。それは建築などでは個々の部品が実在しており、その機能性や外観が分かっており、実際の組み立てをしなくとも計画を作成できるからである。ソフトウェアの場合にはこれが当てはまらない場合が多い。
それぞれのステップにおいて、「探し、考え、比較し、決定する」ことが求められるが、これが対象により作業時間が大幅に異なってくる要因となる。だからといってこの部分を仮決定のままにしておくことは許されない、後の作業に大きな影響をあたえることになるためである。
３．決定を遅らせる要因
多くの場合、実装そのものが困難な場合は少数であり、以下のようなことを決定するための材料が不足していることが、決定を遅くする要因になると想定される。
・最適ゴールの悩み：
そもそも、要求されていることの解決(対処)が妥当なのか
ミクロ的には必要に見えるが、マクロ的にとらえれと別のアプローチの方がすぐれていないか
それを採用するとそもそもの要求が無意味や不要にならないか
・重複の悩み：
すでに類似のものがあり、流用できるのではないか
車輪をもう一度発明したくない
・最適配置の悩み：
作成するものをどこに配置するのがいいのか
とくに作成するものが公開仕様を持つ場合は顕著
配置の変更が公開仕様の変更になってしまい、影響が大きくなるため
・最適単位の悩み：
どういう単位で公開するべきか
大きめの機能モジュールとしてか、小さめのライブラリやユーティリティとしてか
単位の変更が公開仕様の変更になっていしまうため
・効率の悩み：
処理効率が悪くならないか
・拡張性の悩み：
将来の拡張の妨げにならないか
・再利用の悩み：
共通基盤として利用され続けられるのか
４．決定の重さ
決定事項には重い・軽いの別がある。遅くなりがちなのはほとんどの場合、重い決定事項であるといえる。
例えば、システムを作成する場合に、「公開仕様を限定した部品同士の組合せ」としてデザインした場合、個々の部品の実装は後回しにしたり、仮組しておいて後で取り換えるなどの融通が効く。しかし、この公開仕様部分の決定を変更することはコストが高くなる。つまり、この仕様の決定は、部品内部の変更に比較すれば重いものになる。つまり、ソフトウェア設計において「重い、軽い」は、後から簡単に手直しできるか、手直しには多くの影響を招くかの違いが大きいといえる。
Javaなどのクラスという定義要素をもつ場合においては、以下のようなものがある。
簡単に手直しできるもの：影響が限定的なもの
名称の変更：名称をAPI仕様にしていない場合
公開仕様を固定したモジュールの取替え、組直し
Private要素の移動や変更
大きな影響をもたらすもの：影響が大きいもの
公開仕様の変更：APIや機能の変更
Public要素の移動や変更
2009年2月4日水曜日
データの扱い方
システム分析では管理対象とするデータ項目を見つけ出し、整理して「Entity」とその関連として定義していくという作業をする。こうして見つけたデータ塊を正規化することでRDBを使用するための下地になるのであるが、パフォーマンスの観点からは正規化しない方が良い場合も存在する。
つまり、実行時にJOINやらUNIONやらが多数使用されると実行速度に影響を与えることがあり得るため、最初からまとまった形でデータを保有しておいた方がよい場合がある。こうするとRDBでは正規化が崩れることになり、重複するデータの存在をどこかで同期する必要が発生する。これをTriggerなどで形成すれば、以下のような構造のDBを作成できそうである。
概念モデル：正規化したものであり、更新や追加はここに行われる
論理モデル：実際に使用したい塊となっているもので、Viewや重複Tableなどで定義
物理モデル：
3層スキーマ
概念モデル：概念的なまとまり、概ね正規化された状態
論理モデル：アプリケーションで使用したいまとまり、上記モデルの合成や集計
物理モデル：実際にDBMSに作成する定義
リレーショナル型
リレーショナルとは、縦横の表形式でデータをまとめていることを指す
表の制約としてカラム定義が固定化される
他のデータとの関連はキーの一致による
Key-Value型
MS-Azule/SDS, GoogleAppEngine/BigTable, Amazone/C2D など
キーに対して値をとれれば何でも可の形式
RDBのように見せることもできる
つまり、実行時にJOINやらUNIONやらが多数使用されると実行速度に影響を与えることがあり得るため、最初からまとまった形でデータを保有しておいた方がよい場合がある。こうするとRDBでは正規化が崩れることになり、重複するデータの存在をどこかで同期する必要が発生する。これをTriggerなどで形成すれば、以下のような構造のDBを作成できそうである。
概念モデル：正規化したものであり、更新や追加はここに行われる
論理モデル：実際に使用したい塊となっているもので、Viewや重複Tableなどで定義
物理モデル：
3層スキーマ
概念モデル：概念的なまとまり、概ね正規化された状態
論理モデル：アプリケーションで使用したいまとまり、上記モデルの合成や集計
物理モデル：実際にDBMSに作成する定義
リレーショナル型
リレーショナルとは、縦横の表形式でデータをまとめていることを指す
表の制約としてカラム定義が固定化される
他のデータとの関連はキーの一致による
Key-Value型
MS-Azule/SDS, GoogleAppEngine/BigTable, Amazone/C2D など
キーに対して値をとれれば何でも可の形式
RDBのように見せることもできる
CMD.EXE に URL を渡す場合の注意
すこしはまったので、書いておく。
openURL.cmd などという感じでURLを元にブラウザを開くスクリプトを書いた場合に、渡すパラメータの文字には、CMDとしての制限が存在する。
Unix系だと、shやcshに渡す場合に 「*」や「$」や「&」がShellに解釈されてしまってそのままの文字としては渡されないのと同じである。
実は、CMDの場合も同様であり、以下のものは解釈されてしまう。
「% ^ " < > & | ( ) = ; ,」などが特殊な意味をもつものであり、特に「& && || | 」は、クォートされていない場合は、文区切りを意味してしまう。たとえば、以下の例だと、
「&」の前までと後ろが別の文とみなされるため、CMD.EXEでは以下のような実行をする。
もちろん、2行目はエラーとなる。クォートすればOKであり、きちんとURLを認識する。
問題はクォートしてもだめな文字が入った場合であり、代表格は「%」であるが、これは「%%」となり、他の多くの特殊文字のエスケープである「^」ではないところが注意点である。
参照：CMD.EXE TIPs
openURL.cmd などという感じでURLを元にブラウザを開くスクリプトを書いた場合に、渡すパラメータの文字には、CMDとしての制限が存在する。
Unix系だと、shやcshに渡す場合に 「*」や「$」や「&」がShellに解釈されてしまってそのままの文字としては渡されないのと同じである。
実は、CMDの場合も同様であり、以下のものは解釈されてしまう。
「% ^ " < > & | ( ) = ; ,」などが特殊な意味をもつものであり、特に「& && || | 」は、クォートされていない場合は、文区切りを意味してしまう。たとえば、以下の例だと、
openURL.cmd http://x.y.z/s?a=b&c=d
「&」の前までと後ろが別の文とみなされるため、CMD.EXEでは以下のような実行をする。
openURL.cmd http://x.y.z/s?a=b
c=d
もちろん、2行目はエラーとなる。クォートすればOKであり、きちんとURLを認識する。
openURL.cmd "http://x.y.z/s?a=b&c=d"
問題はクォートしてもだめな文字が入った場合であり、代表格は「%」であるが、これは「%%」となり、他の多くの特殊文字のエスケープである「^」ではないところが注意点である。
参照：CMD.EXE TIPs
パフォーマンスチューニング
実行速度のパフォーマンスが悪いと感じる場合の対処法をまとめる。
■前提として
実行速度や処理効率の目安として以下の２つを想定する
・反応速度：ある処理を起動してから応答が返るまでの時間
・スループット：単位時間あたりに処理できる件数
単独で測定している場合は、反応速度を見ていることになるのだが、
同時複数の処理をさせる場合にはスループットが重要になる。システムが
理想的なスケーラブル性を持っている場合は、規模を調節することで
スループットを自由に変更できることになるのだが、実際には様々
な要因により、反応速度が速くても、ある件数以上になるとスループット
が落ちてしまうのが普通である。
速度の早い、遅いは相対的なものであり、絶対的な指標は存在しない。
対象とするシステムにおいて妥当な値から見てどれくらい劣化しているか
と考える必要がある。慣用的に用いられる4秒ルールなどは、人間相手の
反応速度としては妥当であろう。(ちなみに、この4秒はTV放送などの世界で
は黙っていられる限界と思われているようで、これ以上沈黙が続くと視聴者
が違和感を感じる長さのようだ)
■解決のための一般的ステップ
以下のような順序で対応すれば解決への糸口が見つかるであろう。
１）調査：詳細な情報の収集
２）対象範囲確定：関連のありそうな部分とそれ以外を分離
３）データ収集：ログや設定値など
４）問題個所の推定：３）との繰り返し
５）再現：環境や条件をなるべく合致させて
６）対処：設定変更やコード修正
７）確認：
■調査
できる限り詳しく状況を聞き取る。早い、遅いは個人的・相対的な値である
場合が多いので、数値の表わせるものとして取得すること。ポイントは下記のもの。
・処理状況：
どんな状況で、どの処理や操作をした場合にパフォーマンス劣化を認められたか
・データ
特定のデータを使用した場合に発生するか
・繰返し：
特定の回数繰り返した場合に発生するか、単独で発生するか
・時系列的推移：
いつからそうなったのか
・他の処理との関連：
特定の時間帯でないと発生しないか
他の処理を同時に行った場合にのみ発生するか
■対象範囲確定
関連しない部分を切り離し、関連する部分を明らかにする。
・ネットワーク
実行環境でネットワークに依存する部分がある場合
・データベース
実行環境がデータベースを使用している場合
・マシン
該当するマシンすべて
■データ収集
設定値一覧やログファイルなどの処理実行の定義と経過に関するデータを取得する。
当該アプリケーションそのものだけでなく、その動作環境において調査対象とした
すべての部分を考慮する必要がある。例を以下に示す。
・システム設定、システムログ
・サーバ設定、ログ：アプリケーションがAppServerなどで動作している場合
・データベース設定、ログ：DBを使用している場合
・ネットワーク設定、ログ：ネットワークを使用していて関連がある場合
もし、有用な情報が取得できない場合は、フラグを設定して詳細情報を出力するように
変更してから再現させてログを取得するべきである。
■問題個所の推定
収集したデータから問題となりそうな対象と無関係な対象を切り分けていく。
関連がある対象に関しての情報を精査し、問題個所を推定する。
・ネットワーク
同じネットワークを使用する別のアプリケーションの動作状況などを調査して問題性の有無を確認
・データベース
同じデータベースを使用する別アプリケーションなどを調べる
・マシン
同じマシンで稼働する別のアプリケーションや、システムログの情報から
対象がしぼれてくれば、フラグを追加して詳細ログを取ったり、ソースを調査して原因と
なりそうな部分を見つけるなどの方法を試す。
■前提として
実行速度や処理効率の目安として以下の２つを想定する
・反応速度：ある処理を起動してから応答が返るまでの時間
・スループット：単位時間あたりに処理できる件数
単独で測定している場合は、反応速度を見ていることになるのだが、
同時複数の処理をさせる場合にはスループットが重要になる。システムが
理想的なスケーラブル性を持っている場合は、規模を調節することで
スループットを自由に変更できることになるのだが、実際には様々
な要因により、反応速度が速くても、ある件数以上になるとスループット
が落ちてしまうのが普通である。
速度の早い、遅いは相対的なものであり、絶対的な指標は存在しない。
対象とするシステムにおいて妥当な値から見てどれくらい劣化しているか
と考える必要がある。慣用的に用いられる4秒ルールなどは、人間相手の
反応速度としては妥当であろう。(ちなみに、この4秒はTV放送などの世界で
は黙っていられる限界と思われているようで、これ以上沈黙が続くと視聴者
が違和感を感じる長さのようだ)
■解決のための一般的ステップ
以下のような順序で対応すれば解決への糸口が見つかるであろう。
１）調査：詳細な情報の収集
２）対象範囲確定：関連のありそうな部分とそれ以外を分離
３）データ収集：ログや設定値など
４）問題個所の推定：３）との繰り返し
５）再現：環境や条件をなるべく合致させて
６）対処：設定変更やコード修正
７）確認：
■調査
できる限り詳しく状況を聞き取る。早い、遅いは個人的・相対的な値である
場合が多いので、数値の表わせるものとして取得すること。ポイントは下記のもの。
・処理状況：
どんな状況で、どの処理や操作をした場合にパフォーマンス劣化を認められたか
・データ
特定のデータを使用した場合に発生するか
・繰返し：
特定の回数繰り返した場合に発生するか、単独で発生するか
・時系列的推移：
いつからそうなったのか
・他の処理との関連：
特定の時間帯でないと発生しないか
他の処理を同時に行った場合にのみ発生するか
■対象範囲確定
関連しない部分を切り離し、関連する部分を明らかにする。
・ネットワーク
実行環境でネットワークに依存する部分がある場合
・データベース
実行環境がデータベースを使用している場合
・マシン
該当するマシンすべて
■データ収集
設定値一覧やログファイルなどの処理実行の定義と経過に関するデータを取得する。
当該アプリケーションそのものだけでなく、その動作環境において調査対象とした
すべての部分を考慮する必要がある。例を以下に示す。
・システム設定、システムログ
・サーバ設定、ログ：アプリケーションがAppServerなどで動作している場合
・データベース設定、ログ：DBを使用している場合
・ネットワーク設定、ログ：ネットワークを使用していて関連がある場合
もし、有用な情報が取得できない場合は、フラグを設定して詳細情報を出力するように
変更してから再現させてログを取得するべきである。
■問題個所の推定
収集したデータから問題となりそうな対象と無関係な対象を切り分けていく。
関連がある対象に関しての情報を精査し、問題個所を推定する。
・ネットワーク
同じネットワークを使用する別のアプリケーションの動作状況などを調査して問題性の有無を確認
・データベース
同じデータベースを使用する別アプリケーションなどを調べる
・マシン
同じマシンで稼働する別のアプリケーションや、システムログの情報から
対象がしぼれてくれば、フラグを追加して詳細ログを取ったり、ソースを調査して原因と
なりそうな部分を見つけるなどの方法を試す。
登録:
投稿 (Atom)