Tech Ed 2006 四日目
T3-403 Dr.K's SQL Server チューニング研修
SQL ServerはOracleなどと比べてチューニングできないと言われているけれど、ほんと？という話。おおむねこのキーマンインタビューでも出てきた話。
- 稼働後チューニングが必要になるのはよくある。特に利用者急増について考えられていないことが多い。アプリケーションアーキテクチャを気をつけましょう。
- Isolationレベルと同時実行ユーザ数(排他ロックにブロックされない読み取りの実現)
- パフォーマンス阻害要因はどのデータベースサーバでも同じだが、SQL Serverではインデックスは前方一致(A,B,C列に作っていたらA列のみのインデックスを作る必要はない)なので、不要なインデックスを作らないようにしよう。
- Oracleと違って、原則としてヒントを指定する必要はない。
- 動的管理ビューで問題の可視化はできるが、「何故そうなっているか」ということはわからない
- 内部的なWait Eventsが大幅に増加
- SQL Server 2000:75種類
- SQL Server 2005:221種類
- SQL Server 2005 SP1:225種類
- パフォーマンスカウンタも大幅に増加しているので活用しよう。
- SQL Server 2005は物理CPU数に依存するので、できれば4コア(2ソケット)は欲しい。HyperThreadはあまりよくない。
- SQL Server 2005は2000と違い、Standard Editionでも物理メモリの制限はないので、Standardでも有効に使用可能。ただし、IA-32版でActive-Activeクラスタを組むと縮退用のメモリが相当量必要になるため、気をつける必要がある。
- SQL Server 2005でTEMPDBへの負荷はさらに増大した。究極はRAMディスクでも使うしかない。通常はCPU数と同じだけデータファイルを分割する。
- トランザクションログファイルも気をつけよう。
- よほどのことがない限りx64版を使いましょう。
- ないと思われているが、実は環境設定パラメータが結構ある。
- UMS(User Mode Scheduler)のSchedule ID毎の稼働状況のうち、num workersとidle workersの合計がワーカスレッドの数になる。この数の合計に2048bytesをかけた値がスタックサイズ。
- ワーカスレッドの設定値に注意する。x32版では1024以下、大規模な64bit環境では2048以上を推奨。CPU数と64bit/32bit版の組み合わせで規定値が決定される。
- ワーカスレッドを使い果たすと自動的にブロック状態のスレッドを停止させる。また、管理者接続用に必ず一本コネクションをキープしているので、2000のように管理者接続すらできなくなると言うことはない。
- パフォーマンスの問題を引き起こす要因は5種類(アーキテクチャ,DB設計,SQL,ハードウェアの設定,ワークロード変更)。このうち、後3者は導入後のチューニングでもなんとかできる可能性がある。
SQL Serverはチューニングがしにくいという話が定説だったけれど、いくつか設定することはできるというお話でした。ファイル配置の最適化はどんな環境でも通じる話だけれど、UMSでのチューニング話をちゃんと聞いたのは初めてだったので、大変参考になりました。
T2-403 Internet Explorer7の機能概要と評価のポイント
多くはすでに雑誌や各種Webで触れているので、細かい機能については省略。知らなかった話をちょっと列挙してみます。
- モーダル/モーダレスダイアログのサイズ指定がコンテンツエリアに依存するようになった。
- タブはセッションが引き継がれる(やはり)。
- タブからウィンドウオブジェクトのほとんどはスクリプト制御不可。
- 評価にはACTを使えば互換性問題を収集することができる。ただし、Vistaを使用するか、XP上でIE7を動作させなくてはならない。
T5-319 WindowsフォームからWindows Presentation Foundationへの移行
大変ためになったセッションでした。デモもおもしろかったし、今回聞いた中で一番よかった。二年前のWindows Forms高速化のときよりも派手だったし。以下、Windows Presentation FoundationはWPF、Windows FormはWFとします。
Windows FormsとWPFのパフォーマンス比較。ほとんどの場合、WPFの方がよいパフォーマンスを発揮する。GDIベースのWFではウィンドウのリサイズによる再描画はプログラム側の責任だけれど、WPFではWPFが面倒を見る。WPFが負けるのは多くのForm(1000個とか)を作成するような場合。直線、円、リストボックスへの追加などをデモしたところ、おおむね10倍程度高速。
WFを捨てなくてはならないか？そんなことはない。ちゃんと相互運用の仕組みが提供されており、WPFのウィンドウ内にWFのコントロールを貼り付ける、逆にWF内にWPFのコントロールを貼り付ける事もできる。過渡期には必要な技術。移行ツールなどは用意されないので、必要に応じて手動でコードを作成しましょう。
慣れ親しんだウィンドウハンドルさようなら(WPF本にも書いてありますが)。コントロールは単なるイメージになっているため。従来のようにGetWindow(..)とかでウィンドウハンドルを取得して、操作すると言うことはだめ。
できればExpression Interactive Designerを使った方がいい。タイムラインなども操作できる。Ciderでは不可。私個人の印象では、デザイナを巻き込んでUIを作ると言った開発スタイルをする場合、最初にCiderでUIの大まかなところを決めて、専門のデザイナがExpression Interactive Designerで凝ったところを作ってもらうなんてスタイルでいいんじゃないだろうか。とんでもないUIまで作れてしまうので、そこは最初にUIの専門の人などがコントロールしなくてはならないと思う。
アニメーションはCPU速度に依存しないということだけれど、Windowsは基本的にリアルタイムOSじゃないので、「確実に10秒後に到達する」といっても途中の処理とか保証されているのだろうか。具体的に言えば駒落ちとか。この辺後で聞きたかったなぁ..。
ウィンドウの背景にビデオを流して、XAMLのオブジェクトと同期再生させるなんて事もできる。まぁ、ビジネスアプリケーションでは3Dのグラフを作って、ぐりぐり回転させるなんてのがお客さんによっては有効かもしれない。
以上、四日間のメモなど。聞き間違いがあるかもしれないので、全面的に信用しないでください。