「データベース」の検索結果

初期化パラメータ"O7_DICTIONARY_ACCESSIBILITY"の"O7"は"Oracle7"って意味ぽいというどうでもいいことに気付いた。

O7_DICTIONARY_ACCESSIBILITYは、SYSTEM権限の制限を制御します。このパラメータにtrueを設定すると、SYSTEM権限によるSYSスキーマ内のオブジェクトへのアクセスが許可されます(Oracle7の動作)。falseに設定すると、すべてのスキーマ内のオブジェクトへのアクセスが許可されるSYSTEM権限では、SYSスキーマ内のオブジェクトへアクセスできなくなります。

たとえば、O7_DICTIONARY_ACCESSIBILITYがfalseに設定されている場合、SELECT ANY TABLE権限によって、SYSスキーマ以外のスキーマ内のビューまたは表へのアクセスが許可されます(この場合、データ・ディクショナリにはアクセスできません)。システム権限のEXECUTE ANY PROCEDUREによって、SYSスキーマ以外のスキーマ内のプロシージャの実行が許可されます。

このパラメータがfalseに設定されており、SYSスキーマ内のオブジェクトにアクセスする必要がある場合は、オブジェクト権限が明示的に付与されている必要があります。また、データベース管理者に付与される次のロールでも、ディクショナリ・オブジェクトへのアクセスが許可されます。

SELECT_CATALOG_ROLE

EXECUTE_CATALOG_ROLE

DELETE_CATALOG_ROLE

NLS_TIMESTAMP_TZ_FORMAT

Permalink | コメント(0) | トラックバック(0) | 10:26

2012-12-08

パイプライン表関数

Oracle

テーブル・ファンクションは、行のコレクション(ネストした表またはVARRAY)を戻すユーザー定義のPL/SQLファンクションです。SELECT文のTABLE句の内部でテーブル・ファンクションを起動することで、データベース表のようにこのコレクションから要素を選択できます。次に例を示します。
SELECT * FROM TABLE(table_function_name(parameter_list))
(中略)

テーブル・ファンクションの実行をパラレル化でき、戻された行を中間的なステージングなしで次のプロセスに直接送ることができます。テーブル・ファンクションから戻されたコレクションに含まれる行を、パイプライン化することもできます。つまり、テーブル・ファンクションの入力の処理がすべて完了した後にバッチで戻すかわりに、生成されるたびに反復的に戻すことができます。

(中略)

スタンドアロン・ファンクションでは、CREATE FUNCTION文にPIPELINEDオプションを指定します(構文は、「CREATE FUNCTION文」を参照してください)。パッケージ・ファンクションでは、ファンクション宣言とファンクション定義の両方にPIPELINEDオプションを指定します(構文は、「ファンクションの宣言および定義」を参照してください)。
PL/SQLの最適化とチューニング

非パイプライン・テーブル・ファンクションの場合、問合せで1つの結果行が戻されるには、その前にテーブル・ファンクションから戻されるコレクション全体が構成され、サーバーに戻される必要があります。パイプライン化により、行が生成されるたびに反復的に戻すことができます。また、これにより、オブジェクト・キャッシュではコレクション全体をマテリアライズする必要がないため、テーブル・ファンクションに必要なメモリーも減少します。

(中略)

テーブル・ファンクションでのみ使用し、このファンクションがパイプラインであることを指定します。パイプライン・テーブル・ファンクションは、行を処理した直後に起動元に行を戻し、行の処理を継続します。起動元に(制御を戻さずに)行を戻すために、このファンクションでは「PIPE ROW文」を使用します。
ファンクションの宣言および定義

ライン生産方式などパイプライン的なものは様々なところに存在する。自動車の組み立てを考えてみよう。流れ作業の一工程として、エンジンのシャーシへの設置、フードの設置、車輪の設置があり、この順番で実施されるとする。ラインの各工程には、1台の組み立て中の自動車だけがある。エンジンを設置し終えた自動車は、次にフードの設置工程に移され、エンジン設置用の機械設備は次の自動車に取り掛かることができる。最初の自動車はさらに車輪設置工程に進み、2台目の自動車はフード設置工程に進み、3台目の自動車がエンジン設置工程に進んでくる。エンジン設置に20分かかり、フード設置に5分、車輪設置に10分かかるとすると、一度に1台ずつ組み立てると3台組み立てるのに105分かかる。しかし、ライン生産方式では75分で3台の組み立てが完了する。その後も20分間隔で自動車が組み立てられていく。
パイプライン処理 - Wikipedia

まとめ*1

表関数は表をSELECTしたときのように複数行を返す関数。
結果が全部揃うまで待つのではなくできた行から順次帰す表関数がパイプライン表関数。
仕組みは自動車組立工場のライン生産方式と同じ。
1人の職人が一から自動車を組立ていた時代もあるが、自動車組立工場では100台全てのシャーシにエンジンを設置し終えてからタイヤを取り付けるのではなく、できたものが次の工程に流して各工程の組立を並列で行っているため、同じ時間でたくさんの自動車を作ることができる。
パイプライン表関数のメリットとして全部結果ができてから返すのではなく、できた行から順次返すのでデータを溜めておくメモリが少なくてすむといった点がある。

2012-12-02

Oracle Database や OS の性能統計情報と財務諸表の共通点

JPOUG, Oracle

このエントリは JPOUG Advent Calendar 3日目への参加記事です。

"Advent Calendar" の意味を調べてみたところ、

「アドベントカレンダー」（Advent Calendar）とは、クリスマスまでの期間（待降節＝アドベント）をより楽しく過ごすため、12月1日から24日までの間カウントダウンしていく“日めくりカレンダー”のことです。

(中略)

IT業界では、このアドベントカレンダーの風習に習って、12月1～24日の間、何かのテーマや、何らかの制限事項（縛り）を設けてWebにコラム記事を書くというイベントを楽しむようになりました（なかには25日や年末まで続けるものもあるようです）。
師走を楽しもう。技術系アドベントカレンダーの魅力とは - ＠IT

ということらしいです。

お役立ちTIPSとか思い浮かばなかったので読み物を書きます。

この世には様々な事象がありますが、抽象化してみると本質は同じということがよくあると感じます。今回は Oracle Database と OS の性能統計情報、さらに会計の財務諸表(貸借対照表と損益計算書)に共通すると感じたことを書きます。なぜ抽象化するかというと、Oracle Database で学んだことを抽象化して本質を理解すると他の分野でも活かせると感じるからです*1。抽象化については地頭力を鍛える問題解決に活かす「フェルミ推定」という本の説明がわかりやすかったので少し引用します。

地頭力を鍛える問題解決に活かす「フェルミ推定」

作者: 細谷功
出版社/メーカー: 東洋経済新報社
発売日: 2007/12/07
メディア: 単行本
購入: 54人クリック: 878回
この商品を含むブログ (276件) を見る

P.158

そもそも抽象化して考えることがなぜ必要なのか。それは「限られた知識の応用範囲を飛躍的に広げる」ためである。(中略)我々の身の回りでも、一見違うものに対して本質を見きわめて単純化すれば同一の原理を多数のものに適用して解を導くことが可能になるのである。

P.173

およそこの世の中で起きていることというのは、表面的にはすべて異なっているものの根本的な構図を掘り下げていけばほとんど同じ構造になっていることが多い。自然科学においては、量子力学、相対性理論等ごく少数の理論によって宇宙の森羅万象がほとんど説明できるというのが現在の物理学の教えるところである。さらに人間の行動に目を向けてみても、人間の行動の根本的なモチベーションというのは心理学者のマズローの分析結果にあるように、生理的欲求、安全の欲求、自己実現の欲求といった基本的なものであって、環境が多少変わっても根本原理というのはそれほど変わるものではない。

前置きはこの辺にして本題へ。Oracle Database の AWR や Statspack、UNIX系OSの vmstat や top などのコマンド、会計の財務諸表(貸借対照表や損益計算書)には共通点があると思います。それは「アクティビティを数値化して記録して累計していき特定の期間での変動(増加もしくは減少)を見る」というものです。では、Oracle Database から順番に見ていきます。

Oracle Database の性能統計情報

AWRレポートとは、任意の2時点で取得したスナップショットに基づき、データベースパフォーマンスに関連した統計をレポート形式で出力したものです。データベース全体のアクティビティやアプリケーションの傾向、待機イベントの発生状況などの負荷状況をチェックし、チューニングするのに非常に役立つデータを取得できます。
no title

オラクルエンジニア通信からの引用です。このように AWR や Statspack の説明として、スナップショットを取得し、2つの時点の差分(後 - 前)を算出してレポートを作成するという説明をよく見かけます。

定期的にスナップショットを取って、2つの時点の差分を計算(後 - 前)して、その期間の変動(増減)を見ます。一般的に AWR や Statspack は1時間毎、30分毎といった間隔でスナップショットを取得していることが多いのではないかと思います。例えば、V$SYSSTAT や V$SYSTEM_EVENT などの情報を30秒間隔といった間隔で取得しておくと瞬間的な変動を把握することができます。これらのV$ビューの情報は累計値であるため差分を算出して分析するので、ある時点の累計値を取得して(スナップショット)他の時点の累計値との差分を算出して分析するという点では AWR や Statspack と考え方は同じです。

OS の性能統計情報

OS の性能統計情報についても同じことが言えます。例えば vmstat で5秒間隔で表示させると5秒間毎にCPU使用率などの性能統計情報が表示されますが、これはカーネル空間(メモリ)に累計されていく性能統計情報を5秒間隔で取得して差分や平均を計算して表示していると思われます*2。

[oracle@localhost ~]$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 699480  17404 153760    0    0  1479   121 1057  240  4  9 70 17  0 ★1行目は見ない
 0  0      0 699480  17420 153784    0    0     0    34 1002   33  0  0 99  1  0
 0  0      0 699480  17428 153776    0    0     0     2  991   25  0  1 99  0  0
 0  0      0 699480  17428 153784    0    0     0     0  999   28  0  1 99  0  0
 0  0      0 699480  17436 153776    0    0     0     2  989   25  0  1 99  0  0
 0  0      0 699480  17436 153784    0    0     0     0  997   29  0  1 99  0  0

vmstat の最初の行は起動時からの平均値になるため現在の瞬間的な状況を見るためには使わないのはそのためです。普通に考えると、最初の1回目は「現在の値 - 5秒前の値」や「(現在の値 + 5秒前の値) / 2」などとしようとしたときに5秒前の値が存在しないことがわかると思います。また、ps コマンドには5秒間隔などインターバルの指定ができないので、CPU使用率などがプロセス起動時から現在の平均になるのも納得がいくのではないでしょうか。累計値を取得して差分や平均を算出しているという点では、top、iostat なども同じと思われます。

少し脱線すると、Linux で strace コマンドでこれらのコマンドが発行しているシステムコールを調べるとプロセスファイルシステム(/proc)にアクセスしていることがわかります。プロセスファイルシステムにはディレクトリやファイルとしてアクセスできますが、実体はカーネル空間にある性能統計情報です。ファイルというシンプルなインターフェースが用意されていることで容易にアクセスできるようになっています。例えば、シェルスクリプトでプロセスファイルシステムにアクセスして性能統計情報を表示させるといったことも簡単にできます。Oracle Database ではファイルではなくビュー(V$ビュー)にアクセスすることで共有メモリにある性能統計情報を参照することができます。こちらもビューという汎用的なインターフェースが用意されているため、SQLで好きなように性能統計情報を参照することができます。Statspack のスナップショット取得時はV$ビューにアクセスしています*3。全てのものをファイルとして扱うUNIXの哲学と全てのものをデータベースオブジェクトとして扱う Oracle Database の哲学？*4には共通点を感じます。

会計の貸借対照表と損益計算書

最後に貸借対照表と損益計算書です。数字は見るな! 簿記があなたの会計力をダメにするという本の絵が直感的にわかりやすいので紹介します。

数字は見るな! 簿記があなたの会計力をダメにする

作者: 田中靖浩
出版社/メーカー: 日本実業出版社
発売日: 2006/09/14
メディア: 単行本（ソフトカバー）
購入: 1人クリック: 12回
この商品を含むブログ (11件) を見る

P.92

P.145

複式簿記では日々の支出や収入を仕訳入力します。貸借対照表がスナップショットで損益計算書が2時点の差分(Oracle Database でいうAWRレポート)になります。例えば、貸借対照表でその時点でいくら現金があるかはわかりますが、1年間で現金が増えたか減ったかはわかりません。損益計算書を見ると2時点の差分がわかり、前年より現金が増えたのか減ったのかわかります。

まとめ

一応まとめておきます。

性能統計情報は定期的に累計値のスナップショットを取得しての2時点の差分を算出して見ることが多い。
「アクティビティを数値化して記録して累計していき特定の期間での変動(増加もしくは減少)を見る」という点では Oracle Database や OS の性能統計情報も会計の貸借対照表と損益計算書も似ている。
抽象化して考えると限られた知識の応用範囲を飛躍的に広がる。

参考文献

前提

記事の主旨からして、あまり重要でないので最後に前提を書いておきます。

OS はUNIX系OSを前提としています*5。
UNIX系OS での Oracle Database を前提としています。

明日はいつもハイクオリティーな情報をブログ等で発信されている yoshikaw さん、楽しみです。

Permalink | コメント(0) | トラックバック(0) | 04:54

*1：実は役に立つかどうかというより、俺のゴーストの囁きに従っているだけ

*2：ソースコードは見ていません

*3：AWRの場合はMMONプロセスが直接共有メモリにアクセスしています

*4：そんな哲学があるかどうかは知りませんが、私はあるように感じます

*5：部分的にはUNIX系以外のOSでも通用するところもあると思います

2012-10-30

性能問題の切り分け方法について考えてみる

妄想系, Linux, Oracle

つれづれなるままに、日ぐらしパソコンに向かひて、心にうつりゆくデータベースの性能問題の切り分け方法をそこはかとなく書き付くれば、あやしうこそ物狂ほしけれ。なエントリ（書きかけ）。一度、脳内をフラッシュしてからまとめるべし。

性能問題による影響

性能問題による影響を以下の2つに分類する。

システム全体が遅い

一部の処理が遅い

性能問題の原因

性能問題の原因を以下の2つに分類する。

交通量が多い

単純に交通量が多くて渋滞している
例）年末年始やお盆の帰省ラッシュやUターンラッシュ

経路の途中で詰まっている

車線減少や通行止めなどで渋滞している
例）年度末の工事による車線減少、飲酒の検問、交通事故による通行止めなどで経路のどこかで詰まっている

切り分け手順の分類

システム全体が遅いケースと一部の処理が遅いケースで切り分け手順は変わる。

切り分けはOSレイヤーとデータベースレイヤーの2つの観点から行う。

システム全体が遅いケース
- 交通量が多いか
- 経路の途中で詰まっていないか
一部の処理が遅いケース
- 交通量が多いか
- 経路の途中で詰まっていないか

切り分けフロー

ワイルドな切り分けフローを書いてみる。

システム全体が遅いケース
- 交通量が多いか（OSレイヤー）

sar でだいたいのことはできると思うが、とりあえずベタに書いてみる。

$ uptime
 13:30:10 up 2 days, 23:46,  1 user,  load average: 3.78, 3.01, 1.76

uptime で load average を見る*1。load average は CPU待ち*2 + I/O待ち*3のプロセス数*4の平均値。左から1分間、5分間、15分間の平均値。この数をCPUコア数で割って2以上だと待ちが発生している*5。例えると、load average はマック*6のレジに並んでいるお客さんの行列の人数。例えば、合計でお客さん3人並んでいても、レジが3台あれば待ちは発生していないので無問題。ちなみにこの環境は2コアなので、load average の直近1分間の平均が 3.78 は結構重い状態。2コアとも常に処理を実行中で1プロセスが待ちの状態が1分続いている。

$ sar  -s 13:00:00
01:00:01 PM       CPU     %user     %nice   %system   %iowait    %steal     %idle
01:10:01 PM       all      0.11      0.00      0.06     15.45      0.10     84.28
01:20:01 PM       all      0.04      0.00      0.05     15.60      0.11     84.21
01:30:01 PM       all     74.00      0.00      0.06      2.56      0.07     23.31
Average:          all     24.72      0.00      0.06     11.20      0.09     63.93

次に sar でCPU使用率を見る。-sオプションで表示開始時刻を指定している*7。まず %user と %system を見る。DBのプロセスなどユーザープログラムが忙しいときは %user の値が大きくなる。%system はシステムコールやカーネルスレッドなどOS カーネルがCPUを使用した割合*8。通常 %system がそんなに大きい値になることは少ない。%user でも %system でもCPU使用率が高くなる要因として、単純に処理量が多い以外にスピンロックで大量のプロセスやスレッドがCPUを使いながら待機したり、スピン*9してハングしているなどのケースがある。100 ÷ CPUコア数*10の倍数の場合は、一部のコアの使用率が100%になっているかもという感覚を持っておくとよい。例えば、4コアで25%だと1コアが100%になっていることがある。%iowait が高い場合は、CPUは空いていてプロセスがI/O待ちでスリープしている割合が高くI/Oがボトルネックになっていることが多い*11。

$ sar -P ALL -s 13:00:00
01:00:01 PM       CPU     %user     %nice   %system   %iowait    %steal     %idle
01:10:01 PM       all      0.11      0.00      0.06     15.45      0.10     84.28
01:10:01 PM         0      0.16      0.00      0.07     29.06      0.11     70.60
01:10:01 PM         1      0.06      0.00      0.05      1.84      0.10     97.95
01:20:01 PM       all      0.04      0.00      0.05     15.60      0.11     84.21
01:20:01 PM         0      0.06      0.00      0.07     29.72      0.11     70.04
01:20:01 PM         1      0.02      0.00      0.03      1.48      0.10     98.37
01:30:01 PM       all     74.00      0.00      0.06      2.56      0.07     23.31
01:30:01 PM         0     75.46      0.00      0.08      4.98      0.08     19.40
01:30:01 PM         1     72.55      0.00      0.04      0.13      0.07     27.21
Average:          all     24.72      0.00      0.06     11.20      0.09     63.93
Average:            0     25.23      0.00      0.07     21.25      0.10     53.34
Average:            1     24.21      0.00      0.04      1.15      0.09     74.51

sar -P ALL でCPUコア別の使用率を確認する。この環境は0番と1番の2コアであることがわかる。全コアの平均ではCPU使用率が低く見えても、内訳を見ると実は一部のコアだけ100%で他のコアは暇ということもある。

$ top
top - 13:46:10 up 3 days, 2 min,  4 users,  load average: 4.83, 3.90, 2.93
Tasks: 116 total,   5 running, 111 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.1%us,  2.9%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2097152k total,  2085004k used,    12148k free,   143416k buffers
Swap:  6258680k total,    61344k used,  6197336k free,  1513876k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15042 oracle    25   0 77860 1416 1116 R 99.7  0.1  23:39.52 perl -e while(1){}
15046 oracle    25   0 77860 1420 1116 R 97.8  0.1  17:50.85 perl -e while(1){}
    1 root      15   0 10348  684  576 S  0.0  0.0   0:00.16 init [3]
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:00.14 [migration/0]
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.03 [ksoftirqd/0]
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 [watchdog/0]
    5 root      10  -5     0    0    0 S  0.0  0.0   0:00.01 [events/0]
    6 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 [khelper]
    7 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 [kthread]

全体、もしくは一部のコアのCPU使用率が高い場合は top でどのプロセスが原因か調べる。top 起動後、「c」を押すとプログラム名ではなくコマンドラインが表示されるのでわかりやすい*12。例えば、Oracle Database は $ORACLE_HOME/bin/oracle を実行しているので、プログラム名だとサーバープロセスもバックグラウンドプロセスも oracle と表示されるが、コマンドラインにすると、ora_lgwr_orcl のように表示され、どのプロセスかわかりやすい。次に「O」を押すと、ソートする項目を選ぶことができる。ここでは「k」を押してCPU使用率が高い順にソートして表示させている。「n」ならメモリ使用量が大きい順になる。*13

デフォルトで3秒間隔で表示が更新されるが、%CPU はその3秒間に1コアを使用していた割合を表す。この例では一番上の perl ワンライナーが 99.7% となっているが、これは1コアを3秒間のほぼ占有している。

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  2  60580  25848 100408 1482816    0    0   880    40    7   50  5  0 75 19  0
 4  2  60580  25600 100424 1482820    0    0 20837    36  697  489 99  1  0  0  0
 3  2  60580  31600 100436 1482820    0    0 28834    66  881  485 99  0  0  0  0
 2  2  60580  31600 100440 1482824    0    0 23909    58  771  478 100  0  0  0  0
 4  2  60580  31600 100472 1482812    0    0 38050    62 1093  501 99  1  0  0  0
 3  4  60580  31600 100476 1482836    0    0 24733    56  787  473 99  1  0  0  0
 2  7  60580  31724 100476 1482836    0    0 29248    37  891  478 99  1  0  0  0

vmstat ではまずr列とb列を見る。r列はランキューつまりCPU待ち、b列はI/O待ちのプロセス数*14。si、soの値が大きいとメモリ枯渇によりスワップが発生していると考えられる*15。bi*16、bo*17はブロックデバイスに対してI/Oを行ったブロック数。

$ mpstat -P ALL 5

10:09:48 AM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
10:09:53 AM  all    0.00    0.00    0.00   11.67    0.00    0.00    0.10   88.24    177.84
10:09:53 AM    0    0.00    0.00    0.00   23.35    0.00    0.00    0.20   76.45    169.66
10:09:53 AM    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00      8.18

10:09:53 AM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
10:09:58 AM  all    0.00    0.00    0.00   31.39    0.00    0.00    0.10   68.51    159.60
10:09:58 AM    0    0.00    0.00    0.00   62.40    0.00    0.00    0.20   37.40    150.20
10:09:58 AM    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00      9.40

10:09:58 AM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
10:10:03 AM  all    0.10    0.00    0.10    1.38    0.00    0.00    0.10   98.32    167.00
10:10:03 AM    0    0.20    0.00    0.00    2.80    0.00    0.00    0.20   96.80    156.40
10:10:03 AM    1    0.00    0.00    0.20    0.00    0.00    0.00    0.00   99.80     10.60

mpstat でCPUコア別の使用率と割込みなどの情報を確認する。特定のCPUに偏りがないか見る。また、%irq、%soft を確認することで割込みでCPUを使用している割合がわかる。%irq はハードウェア割込み、%soft はソフトウェア割込み。例えば、特定のCPUで %irq の割合が高い場合は Solaris の場合、intrstat で、どのデバイスで割込みが多く発生しているか確認することができる。異常に偏りがある場合は、OSサポートベンダーに調査を依頼するなり、オープンソースなら自分でソースを追い掛けるなりすると良い。

交通量が多いか（DBレイヤー）
経路の途中で詰まっていないか（OSレイヤー）
経路の途中で詰まっていないか（DBレイヤー）

一部の処理が遅いケース
- 交通量が多いか（OSレイヤー）
- 交通量が多いか（DBレイヤー）
- 経路の途中で詰まっていないか（OSレイヤー）
- 経路の途中で詰まっていないか（DBレイヤー）

前提

正確さよりわかりやすさに重点をおき、可能な限り情報をそぎ落としている。
Linux を前提に書いているが、考え方は他のOSでもだいたい同じ。
できるだけ、どの環境でも入っているコマンドを使用している。

注意

SystemTap、DTrace など本番環境で使うには負荷の高いコマンドも記載しています。
この記事に書いているコマンドは内容を理解した上で自己責任で使用してください。

参考

[24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)

作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己
出版社/メーカー: 技術評論社
発売日: 2008/08/07
メディア: 単行本（ソフトカバー）
購入: 133人クリック: 2,270回
この商品を含むブログ (283件) を見る

4.1 Linux単一ホストの負荷を見極める

宣伝

絵で見てわかるITインフラの仕組み (DB SELECTION)

作者: 山崎泰史,三縄慶子,畔勝洋平,佐藤貴彦,小田圭二
出版社/メーカー: 翔泳社
発売日: 2012/09/19
メディア: 単行本（ソフトカバー）
購入: 11人クリック: 204回
この商品を含むブログ (4件) を見る

Permalink | コメント(0) | トラックバック(0) | 10:49

*1：top でも確認できる

*2：実行可能状態(TASK_RUNNING)のプロセスの数。LinuxではCPU使用中でもCPU待ちでもプロセスの状態は実行可能状態(TASK_RUNNING)になる。

*3：スリープしているがシグナルによる待機状態解除不可(TASK_UNINTERRUPTIBLE)

*4：またはスレッド

*5：I/O待ちはCPUを使っていないので厳密にはちょっと違うが、まずはざっくり行列の長さを見る。あと、LinuxではCPUを使用中のプロセスもランキューにカウントされるが、SolarisではカウントされないなどOSの実装によって異なる。

*6：マクドナルド。大阪では「マクド」と言う

*7：-eで終了時刻を指定できる。このあたりのオプションは問題が発生した時間帯を把握していて特定の範囲を指定したい場合などに使うと見やすい。

*8：OSによっては割込みも %system にカウントされる。Linux では割込みは %system ではなく、%irq(ハードウェア割込み) と %soft(ソフトウェア割込み) にカウントされる

*9：ループと言ったほうが分かりやすいかもしれない。例えば perl -e 'while(1){}' という Perl ワンライナーを実行すると1コアが100%になる。これはI/Oなどを発行せずにただCPU命令を実行しているとCPU使用率は100%になることを意味している。

*10：ハイパースレッディングのようなものを使っている場合はスレッド

*11：ただし、他のプロセスがCPUを使うと%iowaitにはカウントされなくなる。つまり、I/Oがボトルネックかどうかは %iowait だけでは判断できない。そこは vmstat の b 列で判断できるはず。後は sar とか

*12：プログラム名で表示されている状態で「c」を押すとコマンドラインになり、さらに「c」を押すとプログラム名になる。このようにある同じ操作を繰り返すことで、機能や状態のON/OFFを切り替える仕組みを「トグル」と言う

*13：「O(大文字のオー)」を押したときに画面が切り替わり、どのキーを押すとどの列でソートされるかが表示されるのでそれに従う。ちなみに「o(小文字のオー)」を押すと表示する列を選択することができる

*14：同期I/OではI/O要求を発行するとブロックされる、つまり待つが非同期は待たないので非同期I/Oではb列には表れないので、iostat などでブロックレイヤーでのIOPS、キューの長さなどを確認する必要がある

*15：メモリが枯渇していなくても使われていないとページアウトされた気がする

*16：読み込み

*17：書き込み

2012-10-19

db tech showcase 2012 で「Welcome to the Real World」というお題で発表しました

Oracle

db tech showcase 2012 の Unconference で、

"Welcome to the Real World" というお題で発表しました。

「世界中のデータベース技術者の"Rock"な叫びと生意気さがここに」というテーマということでワイルドで荒削りな資料になってます。

映画「The Matrix」をテーマに仮想世界から現実世界へというストーリーにしました。

説明がないと意味不明な資料ですが、自分の備忘録としてアップしておきます。

※slideshare にアップしたら一部のフォントがなくて表示が崩れているところがあります

手前味噌ですが、私の発表内容や絵で見てわかるITインフラの仕組み (DB SELECTION)の「4.4 排他制御」あたりの本質を理解していれば、db tech show case 2012 での Tanel Poder のセッション "Troubleshooting the Most Complex Oracle Performance Problem I’ve Ever Seen" を理解できるのではないかと思いました。

今回の発表の準備のための検証環境の構築手順は以下の通りです。

VirtualBox Downloads から VirtualBox-4.2.2-81494-Win.exe をダウンロードしてインストールする。
Developer Day - Hands-on Database Application Development から Oracle Developer Day.ova をダウンロードする。
VirtualBoxを起動し、[ファイル]-[仮想アプライアンスのインポート]を選択して、Oracle Developer Day.ova をインポートする
/etc/inittab を編集してランレベルを 3 にする。

#id:5:initdefault:
id:3:initdefault:

Oracle Database と TimesTen が自動起動しないようにする。

# cd /etc/rc3.d
# rm S99oracle K99oracle
# rm K99timesten S99timesten
# shutdown -r now

yum のリポジトリの設定をする

$ cd /etc/yum.repos.d/
$ wget http://public-yum.oracle.com/public-yum-el5.repo
$ vi public-yum-el5.repo
[el5_u5_base]  
name=Enterprise Linux $releasever U5 - $basearch - base  
baseurl=http://public-yum.oracle.com/repo/EnterpriseLinux/EL5/5/base/$basearch/  
gpgkey=http://public-yum.oracle.com/RPM-GPG-KEY-oracle-el5  
gpgcheck=1  
#enabled=0  
enabled=1  
--  
[ol5_u5_base]  
name=Oracle Linux $releasever - U5 - x86_64 - base  
baseurl=http://public-yum.oracle.com/repo/OracleLinux/OL5/5/base/x86_64/  
gpgkey=http://public-yum.oracle.com/RPM-GPG-KEY-oracle-el5  
gpgcheck=1  
#enabled=0  
enabled=1

SystemTap をインストールする

# rpm -ivh https://oss.oracle.com/el5/debuginfo/kernel-debuginfo-2.6.18-194.17.1.0.1.el5.i686.rpm
# rpm -ivh https://oss.oracle.com/el5/debuginfo/kernel-debuginfo-common-2.6.18-194.17.1.0.1.el5.i686.rpm
# yum install systemtap systemtap-runtime systemtap-sdt-devel

strace をインストールする

# yum install strace

pstack をインストールする

# yum install pstack

tar.xz を解凍できるようにする。

$ wget http://tukaani.org/xz/xz-5.0.4.tar.gz
$ cd xz-5.0.4
$ ./configure
$ make
$ su -
# cd /home/oracle/software/tar-1.26
# make install
$ wget http://mirrors.kernel.org/gnu/tar/tar-1.26.tar.gz
$ tar xvfz tar-1.26.tar.gz 
$ cd tar-1.26
$ ./configure
$ make
$ su -
# cd /home/oracle/software/tar-1.26
# make install

最後に、株式会社インサイトテクノロジー、協賛企業、スピーカー、JPOUG、来場者、そして、Queeness のみなさま、ありがとうございました。

参考

db tech showcase 2012に行ってきました - Keep It Simple, Stupid

Permalink | コメント(0) | トラックバック(1) | 15:26

ablog

2013-02-12

初期化パラメータ"O7_DICTIONARY_ACCESSIBILITY"の"O7"