OracleOSWatcherの概要とログの読み取り
Oracle®OSWatcherは、vmstatなどのコマンドからデータを収集するユーティリティです。 、iostat 、top 、ps 、netstat 、HP-UX®sar 、およびLinux®meminfo 。 OSWatcherはデータファイルをアーカイブし、問題を自動的に検索し、可能であれば問題の根本原因を特定するのに役立ちます。
OSWatcherは、次のOSコマンドを使用して、1時間ごとにバックグラウンドでオペレーティングシステム（OS）の統計を収集します。
- CPU
- メモリ
- ディスクI/O
OSWatcherはファイルを$TFA_HOME / repository / suptools / walhall / oswbb / oracle / archive /に書き込みます 。
自動ハウスキーピングは存在しないため、cronジョブを作成して、OSstatisticsをクリーンアップするために数日より古いファイルを自動的に削除する必要があります。たとえば、cronのクリーンアップジョブで次のコマンドを実行して、10日より古いファイルを削除する場合があります。
find $TFA_HOME/repository/suptools/walhall/oswbb/oracle/archive -name "*.*" -mtime +10 -exec rm -f {} \;
oswiostatログ出力を読み取ります
iostatの場合 がインストールされ、OSWatcherユーザーがユーティリティを実行する権限を持っている場合、OSWatcherログは、デフォルトでiostatから1時間ごとに出力を収集してアーカイブします。 コマンド。
iostat は、システムの入出力デバイスの負荷を監視するために使用され、次の情報を収集します。
- 時間
- 物理ディスクとその平均データ転送速度
oswiostat ログファイルには次のデータが含まれています：
device：デバイス名-
r/s：1秒あたりの読み取り数 -
w/s：1秒あたりの書き込み数 -
rsec/s：1秒あたりの読み取りキロバイト -
wsec/s：1秒あたりに書き込まれるキロバイト -
avgrq-sz：サービスを待機しているトランザクションの平均数 -
avgqu-sz：アクティブに処理されているトランザクションの平均数 -
%util：ディスクがビジーである時間の割合
以下は、oswiostatの2つの例です。 7時間間隔で取得されたログ：
遅い時間：
Time: 00:01:09
avg-cpu: %user %nice %system %iowait %steal %idle
5.22 0.01 1.77 0.10 0.00 92.90
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 10.24 101.92 10.28 29.60 569.53 1057.09 40.79 0.21 5.30 0.53 2.11
sda1 0.00 0.00 0.00 0.00 0.17 0.00 138.66 0.00 12.37 3.45 0.00
sda2 10.24 101.92 10.28 29.57 569.36 1057.09 40.81 0.21 5.30 0.53 2.11
dm-0 0.00 0.00 1.72 77.98 75.95 623.85 8.78 1.20 14.99 0.08 0.67
dm-1 0.00 0.00 0.46 2.37 3.80 18.94 8.04 0.01 2.71 0.29 0.08
dm-2 0.00 0.00 7.44 50.74 278.30 410.79 11.84 0.72 12.30 0.23 1.33
dm-3 0.00 0.00 0.00 0.00 0.15 0.00 509.61 0.00 46.78 7.53 0.00
dm-4 0.00 0.00 0.49 0.00 117.41 0.02 238.95 0.00 1.94 1.05 0.05
dm-5 0.00 0.00 0.05 0.00 10.84 0.00 230.78 0.00 2.58 1.34 0.01
dm-6 0.00 0.00 0.00 0.00 0.10 0.00 479.96 0.00 54.94 8.70 0.00
忙しい時間に：
Time: 07:32:57
avg-cpu: %user %nice %system %iowait %steal %idle
8.16 0.00 70.29 21.55 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 163.40 7.73 2074.74 53.95 73642.61 493.47 34.83 107.13 50.07 0.47 100.07
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 163.40 7.73 2074.74 53.95 73642.61 493.47 34.83 107.13 50.07 0.47 100.07
dm-0 0.00 0.00 201.03 0.86 8412.37 6.87 41.70 58.68 281.80 4.96 100.07
dm-1 0.00 0.00 180.76 26.46 1446.05 211.68 8.00 25.24 119.01 4.83 100.07
dm-2 0.00 0.00 1868.90 34.54 63913.40 276.29 33.72 332.23 172.22 0.53 100.09
dm-3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
画像ソース ：https：//www.dbas-oracle.com/2013/05/How-to-Analyze-or-Read-OS-Watcher-Output-in-three-easy-steps-With-Example.html
真夜中のスナップショットは良好なパフォーマンスを示し、午前7時32分のスナップショットはパフォーマンスが低いことを示しています。 2番目のスナップショットのパフォーマンスが低いという次の兆候に注意してください。
-
%utilに見られるように、いくつかのディスクは100％ビジーです。 列。 -
r/s列には、1秒あたりの読み取り数が非常に多いことが示されています。 -
avg-cpu %idle統計によると、システムは0％アイドルであるのに対し、以前のスナップショットでは92％アイドルでした。
mpstatログ出力を読み取ります
mpstatの場合 がインストールされ、OSWatcherユーザーがユーティリティを実行する権限を持っている場合、OSWatcherログは、デフォルトでmpstatから1時間ごとに出力を収集してアーカイブします。 指図。データベース管理者は、このコマンドを使用して、中央処理装置（CPU）の使用率を監視します。
mpstat ログファイルには次のデータが含まれています：
-
CPU：どのCPU。allシステムで使用可能なすべてのCPUからの統計が含まれます。 -
%user：USERプログラムによって使用されるCPUの割合 -
%sys：システムプログラムによって使用されるCPUの割合 -
%iowait：IO待機によって消費されるCPUの割合 -
%idle：アイドル状態のシステムリソースの割合
以下は、mpstatの2つの例です。 1時間間隔で取得されたログ：
遅い時間：
zzz ***Tue Apr 23 06:13:44 EDT 2013 Sample interval: 5 seconds
Linux 2.6.32-400.21.1.el5uek (remote.database.com) 04/23/13
06:13:44 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
06:13:49 all 6.26 0.00 1.32 0.00 0.01 0.02 0.00 92.39 36448.70
06:13:54 all 8.17 0.00 1.92 0.01 0.00 0.05 0.00 89.86 38918.09
06:13:59 all 8.11 0.00 1.18 0.01 0.00 0.05 0.00 90.65 40989.86
06:14:04 all 8.04 0.00 1.25 0.06 0.00 0.05 0.00 90.61 40242.86
06:14:09 all 6.62 0.00 1.27 0.02 0.00 0.05 0.00 92.04 37460.32
06:14:14 all 7.56 0.00 1.47 0.02 0.00 0.02 0.00 90.94 37288.67
06:14:19 all 7.19 0.00 1.21 0.14 0.00 0.02 0.00 91.44 36947.91
06:14:24 all 6.50 0.00 1.02 0.01 0.00 0.02 0.00 92.45 35792.86
06:14:29 all 7.28 0.00 1.82 0.01 0.00 0.02 0.00 90.87 36795.42
06:14:34 all 7.37 0.02 1.20 0.02 0.00 0.01 0.00 91.37 36818.80
06:14:39 all 7.41 0.00 1.05 0.02 0.00 0.02 0.00 91.49 36874.90
06:14:44 all 7.15 0.01 1.62 0.04 0.00 0.02 0.00 91.16 35904.77
06:14:49 all 7.21 0.00 1.22 0.14 0.00 0.02 0.00 91.41 38867.73
06:14:54 all 7.31 0.00 1.00 0.00 0.00 0.03 0.00 91.65 39378.74
忙しい時間に：
zzz ***Tue Apr 23 07:23:02 EDT 2013 Sample interval: 5 seconds
Linux 2.6.32-400.21.1.el5uek (remote.database.com) 04/23/13
07:24:20 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
07:24:25 all 2.74 0.00 97.16 0.00 0.00 0.10 0.00 0.00 39066.67
07:24:30 all 3.06 0.00 96.87 0.00 0.00 0.07 0.00 0.00 37637.52
07:24:37 all 3.13 0.00 96.79 0.01 0.00 0.07 0.00 0.00 36788.64
07:24:42 all 2.69 0.00 97.17 0.05 0.00 0.09 0.00 0.00 38270.04
07:24:48 all 3.86 0.01 94.92 1.02 0.00 0.20 0.00 0.00 43247.39
07:24:53 all 3.51 0.00 96.19 0.20 0.00 0.11 0.00 0.00 39887.45
07:24:59 all 4.22 0.00 93.51 2.12 0.00 0.15 0.00 0.00 40638.08
07:25:04 all 6.26 0.00 85.04 8.56 0.00 0.13 0.00 0.00 41915.79
07:25:09 all 8.69 0.00 67.31 23.85 0.00 0.11 0.00 0.03 44586.56
07:25:15 all 8.09 0.00 80.62 11.17 0.00 0.12 0.00 0.00 44321.66
07:25:21 all 7.18 0.00 71.95 20.80 0.00 0.07 0.00 0.00 35399.65
07:25:26 all 6.69 0.00 68.20 24.97 0.01 0.12 0.00 0.00 38734.99
07:25:31 all 7.11 0.01 74.71 18.09 0.00 0.08 0.00 0.00 36695.68
07:25:36 all 7.46 0.00 14.17 78.20 0.00 0.05 0.00 0.13 32934.53
07:25:50 all 9.71 0.00 23.99 66.24 0.00 0.05 0.00 0.00 33617.64
07:25:56 all 7.80 0.00 85.97 6.13 0.00 0.10 0.00 0.00 41234.83
06:13のスナップショットは良好なパフォーマンスを示し、7：32AMのスナップショットはパフォーマンスが低いことを示しています。 2番目のスナップショットのパフォーマンスが低いという次の兆候に注意してください。
-
%sys列は97.17のピーク使用率を示しています。 -
%iowait列は78.20のピーク使用率を示しています。
top コマンドは、プロセッサアクティビティの1時間ごとのスナップショットを提供します。ログには、CPU使用率の降順でリストされたプロセスが表示されるため、CPUを最も多く使用しているプロセスが最初にリストされます。
システムのCPU使用率が突然増加し、プロセス数が変更されていない場合は、top 問題の特定に役立ちます。
負荷が増加しなかったにもかかわらずCPUが急上昇する、次のシナリオを考えてみます。
zzz ***Tue Apr 23 03:13:44 EDT 2013 Sample interval: 5 seconds. All measurements in KB (1024 bytes)
top - 04:13:44 up 22 days, 21:12, 10 users, load average: 65.80, 169.78, 117.65
Tasks: 2297 total, 4 running, 2229 sleeping, 0 stopped, 64 zombie
Cpu0 : 12.7%us, 2.6%sy, 0.0%ni, 84.2%id, 0.5%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 6.7%us, 2.0%sy, 0.0%ni, 91.1%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st
Cpu2 : 6.4%us, 1.7%sy, 0.0%ni, 91.8%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 5.5%us, 1.3%sy, 0.0%ni, 93.1%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 7.6%us, 1.6%sy, 0.0%ni, 90.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 5.3%us, 1.1%sy, 0.0%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 11.8%us, 2.7%sy, 0.0%ni, 85.3%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st
Cpu7 : 7.0%us, 2.2%sy, 0.0%ni, 90.6%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st
Cpu8 : 5.8%us, 1.5%sy, 0.0%ni, 91.8%id, 0.8%wa, 0.0%hi, 0.1%si, 0.0%st
Cpu9 : 8.0%us, 1.7%sy, 0.0%ni, 90.0%id, 0.1%wa, 0.0%hi, 0.2%si, 0.0%st
Cpu10 : 3.8%us, 1.2%sy, 0.0%ni, 94.9%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu11 : 3.6%us, 1.0%sy, 0.0%ni, 95.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 99060540k total, 91969324k used, 7091216k free, 84044k buffers
Swap: 25165816k total, 17797404k used, 7368412k free, 609612k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20343 oracle 20 0 13.4g 10g 5864 R 98.4 10.7 18:56.54 oraclevntrd2 (LOCAL=NO)
30180 root 20 0 11872 2312 656 R 98.4 0.0 0:00.68 /bin/netstat -n -p -l
6568 root 39 19 0 0 0 R 89.9 0.0 263:39.04 [kipmi0]
30262 root 20 0 23704 3116 1048 R 11.9 0.0 0:00.15 /usr/bin/top -b -d 5 -n 720
4921 root RT 0 247m 86m 55m S 6.8 0.1 328:08.44 /u01/app/11.2.0.3/grid/bin/osysmond.bin
28116 oracle 20 0 2623m 71m 14m S 6.8 0.1 51:51.62 /u01/app/11.2.0.3/grid/bin/oraagent.bin
4970 grid RT 0 359m 176m 54m S 5.1 0.2 157:05.89 /u01/app/11.2.0.3/grid/bin/ocssd.bin
64 root 20 0 0 0 0 S 1.7 0.0 4:39.22 [ksoftirqd/20]
4903 root 20 0 367m 20m 13m S 1.7 0.0 26:09.97 /u01/app/11.2.0.3/grid/bin/orarootagent.bin
6496 root 20 0 1274m 15m 11m S 1.7 0.0 28:27.53 /u01/app/11.2.0.3/grid/bin/orarootagent.bin
6535 oracle 20 0 1830m 263m 4620 S 1.7 0.3 88:05.31 /u01/app/oracle/product/agent12c/core/12.1.0.2.0/jdk/bin/java -Xmx128M -server -Djava.secu
7803 oracle -2 0 1266m 11m 4068 S 1.7 0.0 9:15.42 ora_lms0_oradb2
7874 oracle -2 0 1266m 15m 4188 S 1.7 0.0 9:16.20 ora_lms0_oradb2
7999 oracle 20 0 1284m 10m 3292 S 1.7 0.0 2:49.08 ora_lmd0_oradb2
8297 oracle 20 0 1230m 3368 2864 S 1.7 0.0 0:39.95 ora_pmon_oradb2
8333 oracle -2 0 1252m 2380 2108 S 1.7 0.0 13:19.99 ora_vktm_bid2
8443 oracle -2 0 1252m 2340 2096 S 1.7 0.0 13:21.86 ora_vktm_oradb2
8535 oracle 20 0 1253m 2712 2412 S 1.7 0.0 0:14.28 ora_dskm_oradb2
8727 oracle -2 0 1266m 11m 3656 S 1.7 0.0 9:01.37 ora_lms0_im1d2
8905 oracle 20 0 1267m 13m 3468 S 1.7 0.0 9:52.75 ora_dia0_pstd2
ログの分析：
行zzz ***Tue Apr 23 03:13:44 EDT 2013 Sample interval: 5 seconds. All measurements in KB (1024 bytes) ログが統計をキャプチャした時間を識別します。
行top - 04:13:44 up 22 days, 21:12, 10 users システムが最後の再起動から22日間実行されていることを示します。
行load average: 65.80, 169.78, 117.65 は、過去1分間、5分間、および15分間の実行キュー内のプロセスの平均数を示しています。平均負荷が高いほど、システムはビジーになります。負荷平均の大幅な増加は、問題を示している可能性があります。たとえば、上記のログは、負荷平均数に基づいて、7分後のログと比較してビジー時間を示しています。top - 04:20:53 up 22 days, 21:19, 10 users, load average: 2.93, 43.22, 75.56
行Tasks: 2297 total, 4 running, 2229 sleeping, 0 stopped, 64 zombie ：このスナップショットの時点で、2297のプロセスがあり、2229がスリープ状態であり、I / Oまたはシステムコールによってブロックされ、4つが実行中またはCPUに割り当てられていました。実行中のプロセスの数がCPUの数を超えることはありません。追加の64のプロセスはゾンビです。つまり、それらは死んでいますが、システムはそれらを完全にクリーンアップしていません。プロセスの数はさまざまですが、数が急激に増減する場合は、問題がある可能性があります。
行Mem: 99060540k total, 91969324k used, 7091216k free, 84044k buffers は、使用されているランダムアクセスメモリ（RAM）の量をキロバイト単位で示しています。問題を特定できるように、これが時間の経過とともにどのように変化するかに注意してください。
行Swap: 25165816k total, 17797404k used, 7368412k free, 609612k cached ：RAMが使い果たされると、システムはスワップメモリに切り替わります。スワップメモリの使用量が一貫してRAMの約40％を超える場合は、RAMの増加を検討する必要があります。スワップの使用量が多いと、パフォーマンスに悪影響を及ぼします。 100％に達すると、システムが再起動する可能性があります。
次のCPU行は、このシステムの12個のCPUの数と使用率を示しています。
Cpu0 : 12.7%us, 2.6%sy, 0.0%ni, 84.2%id, 0.5%wa, 0.0%hi, 0.0%si, 0.0%st
...
Cpu11 : 3.6%us, 1.0%sy, 0.0%ni, 95.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
次のプロセス行は、スナップショットの時点で実行されているプロセスの詳細を示しています。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20343 oracle 20 0 13.4g 10g 5864 R 98.4 10.7 18:56.54 oraclevntrd2 (LOCAL=NO)
30180 root 20 0 11872 2312 656 R 98.4 0.0 0:00.68 /bin/netstat -n -p -l
6568 root 39 19 0 0 0 R 89.9 0.0 263:39.04 [kipmi0]
30262 root 20 0 23704 3116 1048 R 11.9 0.0 0:00.15 /usr/bin/top -b -d 5 -n 720
...
8727 oracle -2 0 1266m 11m 3656 S 1.7 0.0 9:01.37 ora_lms0_im1d2
8905 oracle 20 0 1267m 13m 3468 S 1.7 0.0 9:52.75 ora_dia0_pstd2
プロセスセクションには、次の情報が含まれています。
-
PID：プロセスのOSプロセスID USER：プロセスの所有者-
%CPU：CPUの何パーセントがプロセスによって使用されているか -
%MEM：メモリ消費の割合 COMMAND：実行中のコマンド
OSWatcherを使用すると、システムパフォーマンスを監視し、考えられる問題を特定できます。たとえば、プロセスが一定時間CPUを頻繁に使用しているかどうかを確認します。 SQLコマンドの負荷が高い場合は、これがチューニングの候補になる可能性があります。プロセスが大量のメモリを使用している場合は、これが正常かどうかを調査できます。
CPU、メモリ、およびディスクI / O（システム負荷など）を調べた後、OSWatcherで考慮すべき他の統計があります。 OSWatcher分析を使用してシステムの負荷の増加を特定すると、戦いの半分が勝ちます。
[フィードバック]タブを使用して、コメントを書き込んだり、質問したりします。
参照ソース：
例を使用して3つの簡単なステップでOSWatcher出力を分析または読み取る方法
専門家による管理、管理、構成で環境を最適化する
Rackspaceのアプリケーションサービス（RAS） 専門家は、幅広いアプリケーションポートフォリオにわたって次の専門的かつ管理されたサービスを提供します。
- eコマースおよびデジタルエクスペリエンスプラットフォーム
- エンタープライズリソースプランニング（ERP）
- ビジネスインテリジェンス
- Salesforceの顧客関係管理（CRM）
- データベース
- メールホスティングと生産性
お届けします：
- 偏りのない専門知識 ：私たちは、即時の価値を提供する機能に焦点を当てて、お客様の近代化の旅を簡素化し、導きます。
- 狂信的な経験 ™：最初にプロセスを組み合わせます。テクノロジーセカンド。包括的なソリューションを提供するための専用のテクニカルサポートを備えたアプローチ。
- 比類のないポートフォリオ ：豊富なクラウドエクスペリエンスを適用して、適切なテクノロジーを適切なクラウドに選択して導入できるようにします。
- アジャイルデリバリー ：私たちはあなたがあなたの旅の途中であなたに会い、あなたの成功と一致します。
今すぐチャットして始めましょう。
-
AutonomousDatabaseDedicatedおよびExadataクラウドインフラストラクチャ
この投稿では、Oracle®AutonomousDatabaseDedicatedおよびExadata®クラウドインフラストラクチャに関するさまざまなソースからの情報を紹介します。 はじめに Oracle Autonomous Databaseの技術概要によると、「Oracle Autonomous Databaseは、クラウドの柔軟性と機械学習の能力を組み合わせて、データ管理をサービスとして提供します。」このドキュメントは後で追加します。「OracleAutonomousデータベースには、OracleExadataおよびExadataCloud Serviceにある製品のフルセットが含まれ
-
OracleSQLプロファイルとベースライン
この投稿では、SQLプロファイルとOracle®のベースラインの違いに焦点を当て、クエリを調整するときにどのように機能するかを説明します。 オプティマイザー、プロファイル、およびベースライン 大まかに言うと、これら3つの要素は次のように連携して機能します。 クエリオプティマイザは、システム統計、バインド変数、コンパイルなどの情報を使用して、クエリ実行の最適なプランを取得します。ただし、入力の欠陥が最適ではない計画につながる場合があります。 SQLプロファイルには、この問題を軽減する補助情報が含まれています。SQLプロファイルは、これらの間違いを最小限に抑え、オプティマイザーが最適