DROP SHADOW CTRL


GaragebandとiMovieで



検索

  • Google
フォト

Twitter

2024年10月
日 月 火 水 木 金 土
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

気まぐれ写真館

  • spider lily - 白と赤の彼岸花（曼珠沙華）

カテゴリー

Oracle

Apple

その他

  • ブログ de ノベルティ
    ノベルティグッズをただ、ただ、記録していくブログ。Mac De Oracleでは出来ないネタなので、別ブログを立てた次第。

Googleの広告



RSS

ブログ:ココログ

当サイトについて

プライバシーポリシー
■プライバシーポリシー

■個人情報の利用目的

　当ブログでは、メールでのお問い合わせ、ブログへのコメントの際、名前（ハンドルネーム）等の個人情報をご登録いただく場合がございます。これらの個人情報は質問に対する回答などでご連絡する場合や、スパムコメント抑止のために利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。

■個人情報の第三者への開示

　当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。

  • 本人のご了解がある場合
  • 法令等への協力のため、開示が必要となる場合

個人情報の開示、訂正、追加、削除、利用停止については、ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上で速やかに対応させていただきます。

■アクセス解析ツールについて

　当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

  • 目的：アクセス数を把握するため
  • 送信先：Google LCC
  • Googleは受け取った情報をどのように利用するか：Googleの規約に従います
  • 送信される情報：以下４点(R), ユーザー数、セッションの統計情報、おおよその位置情報、ブラウザとデバイスの情報

■広告の配信について

当サイトはGoogleとAmazonの広告を配信しています。

Googleについて

Google及びGoogleのパートナー（第三者配信事業者）の提供する広告を設置しております。その広告配信にはCookieを使用し、当サイトやその他のサイトへの過去のアクセス情報に基づいて広告を配信します。

Google が広告 Cookie を使用することにより、当サイトや他のサイトにアクセスした際の情報に基づいて、Google やそのパートナーが適切な広告を表示しています。

お客様はGoogleアカウントの広告設定ページ（https://adssettings.google.com/u/0/authenticated）で、パーソナライズ広告を無効にできます。また aboutads.info のページにアクセスして頂き、パーソナライズ広告掲載に使用される第三者配信事業者のCookieを無効にできます。

その他、Googleの広告におけるCookieの取り扱い詳細については、Googleのポリシーと規約ページ（https://policies.google.com/technologies/ads）をご覧ください。

Amazonについて

AmazonはアソシエイトリンクのURLに含まれるパラメータを通じて利用者が直前に閲覧したアソシエイトサイトに関する情報などを収集し、これをアソシエイトパートナーに対する紹介料の算定、報告及び支払いに使用したり、アソシエイトパートナーによる複数のウェブサイトや商品戦略毎のパフォーマンスの分析に供したりしています。

  • アソシエイトパートナーの利用目的：閲覧の傾向や履歴の分析のため広告効果の分析のため
  • 外部送信プログラム名：Amazonアソシエイトプログラム
  • 送信先の会社名：アマゾンジャパン合同会社
  • 送信する情報の内容：閲覧した内容についての情報送信先の利用目的：自社の広告宣伝を目的とした広告情報の掲載のため、ウェブサイトやアプリの監視のため

Amazonによる個人に関する情報の取得及び取扱いに関する方針につきましてはAmazon.co.jpプライバシー規約をご覧ください。

■免責事項

　当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

■プライバシーポリシーの変更について

　当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。
修正された最新のプライバシーポリシーは常に本ページにて開示されます。

2017年7月 1日 (土)

リソースマネージャ：MTA環境のインスタンスケージングが効いているかざっくり確認するスクリプト

元になるビューは１分間隔で更新されているようで秒単位の粒度では確認できないもののざっくりでもいいからリアルタムに確認したい場合には便利

むかーしやった検証はnon CDBかつ、秒単位で見たいという要望だったため他のビューから算出したこともあり、ここで利用しているv$rsrcmetricの類は使わなかったことを思い出した。
完全に忘れてた(@@)。
２年も触らなきゃ忘れるさ。人間だものw　orz.

ということで、 Oracle Database 12c 12.1.0.2.0 向けのメモ

注）以下、CDB$ROOTに接続してSQL文を実行しています


利用環境は以下の通りのMTA

orcl12c@SYS> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production              0
PL/SQL Release 12.1.0.2.0 - Production                                                    0
CORE	12.1.0.2.0	Production                                                               0
TNS for Linux: Version 12.1.0.2.0 - Production                                            0
NLSRTL Version 12.1.0.2.0 - Production                                                    0


CPUは4 (VMですが）

orcl12c@SYS> show parameter cpu_count

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cpu_count                            integer     4


ORCLとORCL2という２つのPDB対してCPUのUTILIZATION_LIMITでCPU利用率を制限しています。
12.2以降はPDBのインスタンスケージングもnon-CDB環境同様に、CPU_COUNT設定＋リソースマネージャで制御できちゃうらしい。わかりやすくて良い！（時間があればいずれ）

orcl12c@SYS> select name from v$containers;

NAME
------------------------------
CDB$ROOT
PDB$SEED
ORCL
ORCL2


orcl12c@SYS> r
  1  SELECT
  2      vc.name
  3      , vp.utilization_limit
  4  FROM
  5      v$rsrc_plan vp
  6      INNER JOIN v$containers vc
  7      ON vp.con_id=vc.con_id
  8  ORDER BY
  9*     vc.con_id

NAME                           UTILIZATION_LIMIT
------------------------------ -----------------
CDB$ROOT
PDB$SEED
ORCL                                          25
ORCL2                                         50

それぞれのPDBでCPU数以上のCPUバウンドな処理を実行して負荷かけ中

resmgr:cpu quantumとう待機イベントはresource managerがCPUの利用率を制御していることを示す待機イベント！
リソース制御が効いていることを示してます。

orcl12c@SYS> select username,event from v$session where username is not null order by username;

USERNAME       EVENT
-------------- ----------------------------------------------------------------
SYS            Streams AQ: waiting for messages in the queue
SYS            Streams AQ: waiting for messages in the queue
SYS            SQL*Net message from client
SYS            Streams AQ: waiting for messages in the queue
SYS            Streams AQ: waiting for messages in the queue
SYS            resmgr:cpu quantum
SYS            SQL*Net message to client
SYS            SQL*Net message from client
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum
TOTHER01       resmgr:cpu quantum


vmstatでは全体のCPU利用率は見えますが複数のPDBが想定通りケージングされているかは見えません。

$ vmstat -t 5 1000
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- -----timestamp-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st                 JST
12  0      0 1487628  55660 4727120    0    0   125    13  452  262 21  1 78  0  0 2017-06-29 23:48:16
11  0      0 1480868  55668 4727176    0    0     0    28 3817 1459 69  2 29  0  0 2017-06-29 23:48:21
11  0      0 1480900  55676 4727068    0    0     0    16 3982 1480 73  2 25  0  0 2017-06-29 23:48:26
13  0      0 1480948  55684 4727008    0    0     0    17 3722 1383 68  2 30  0  0 2017-06-29 23:48:31
 1  0      0 1480956  55684 4726980    0    0     0    10 3765 1410 69  2 29  0  0 2017-06-29 23:48:36
 3  0      0 1480956  55692 4726984    0    0     0    18 3886 1417 76  2 22  0  0 2017-06-29 23:48:41
10  0      0 1480336  55716 4727044    0    0     0    35 3830 1441 69  2 29  0  0 2017-06-29 23:48:46
 0  0      0 1480336  55724 4727036    0    0     0    24 4033 1536 76  2 22  0  0 2017-06-29 23:48:51
14  0      0 1469888  55724 4727100    0    0     0    14 3722 1508 67  2 31  0  0 2017-06-29 23:48:56
11  0      0 1459988  55732 4727384    0    0     0    17 4049 1685 73  3 24  0  0 2017-06-29 23:49:01
13  0      0 1419652  55740 4728940    0    0   134    38 4299 1901 80  3 16  0  0 2017-06-29 23:49:06
10  0      0 1419676  55748 4728860    0    0     0    21 3861 1491 69  2 29  0  0 2017-06-29 23:49:11
10  0      0 1419768  55756 4729044    0    0     0    28 3914 1471 71  2 27  0  0 2017-06-29 23:49:16
12  0      0 1421380  55764 4729064    0    0     0    31 3697 1445 68  2 31  0  0 2017-06-29 23:49:21
11  0      0 1421412  55764 4729016    0    0     0    13 3735 1412 68  2 30  0  0 2017-06-29 23:49:26
10  0      0 1421544  55772 4728980    0    0     0    18 3986 1521 73  2 25  0  0 2017-06-29 23:49:31
11  0      0 1464824  55780 4728524    0    0     0    11 3702 1372 68  2 30  0  0 2017-06-29 23:49:36
10  0      0 1458468  55788 4728572    0    0     1    20 4030 1495 74  2 24  0  0 2017-06-29 23:49:41
10  0      0 1458624  55796 4728452    0    0     0    17 3836 1520 68  2 29  0  0 2017-06-29 23:49:46
 0  0      0 1458880  55804 4728400    0    0     0    20 3908 1522 70  2 28  0  0 2017-06-29 23:49:51
 0  0      0 1458864  55804 4728424    0    0     0    13 4039 1453 76  2 21  0  0 2017-06-29 23:49:56
 0  0      0 1458864  55812 4728420    0    0     0    18 3870 1471 70  2 28  0  0 2017-06-29 23:50:01
 1  0      0 1454680  55820 4728804    0    0     2    16 4541 2070 76  4 20  0  0 2017-06-29 23:50:06
 1  0      0 1454728  55828 4728688    0    0     0    29 3829 1453 70  2 28  0  0 2017-06-29 23:50:11
 9  0      0 1454048  55836 4728596    0    0     0    18 3751 1415 69  2 29  0  0 2017-06-29 23:50:16
10  0      0 1454056  55836 4728548    0    0     0    15 3867 1472 72  2 26  0  0 2017-06-29 23:50:21
11  0      0 1454088  55844 4728480    0    0     0    21 3704 1390 67  2 31  0  0 2017-06-29 23:50:26
10  0      0 1454252  55852 4728396    0    0     0    17 3774 1391 70  2 28  0  0 2017-06-29 23:50:31
10  0      0 1465692  55860 4728416    0    0     0    24 3914 1484 71  2 26  0  0 2017-06-29 23:50:36
10  0      0 1465468  55868 4728380    0    0     0    18 3794 1435 68  2 30  0  0 2017-06-29 23:50:41


最初に書いたように、１分間隔で少々粒度は粗めですがざっくり各PDBのCPU利用率を確認する場合には以下のようなスクリプトが便利！！
以下クエリをshellで定期的に実行するなり、随時実行するなりして確認すると便利、なお、gv$rsrcmgrmetricの代わりに、gv$rsrcmgrmetric_historyを
利用すれば過去１時間分だけですが、遡って確認することもできます。

orcl12c@SYS> !cat show_con_cpu.sql
SELECT
    to_char(begin_time, 'RR/MM/DD HH24:MI:SS') AS time
    , vc.con_id
    , vc.name
    , (SELECT value FROM v$osstat WHERE stat_name = 'NUM_CPUS') AS "CPUs"
    , round((sum(cpu_consumed_time) / 1000) / (60 * (SELECT value FROM v$parameter WHERE name = 'cpu_count'))*100,2) AS "%cpu"
FROM
    gv$rsrcmgrmetric gvr
    INNER JOIN v$containers vc
    ON
        vc.con_id = gvr.con_id
GROUP BY
    vc.con_id
    ,vc.name
    ,begin_time
ORDER BY
    begin_time
    ,vc.con_id
/

各PDBが25%、50%で制限されていることがわかります！！

orcl12c@SYS> @show_con_cpu.sql

TIME                  CON_ID NAME                                 CPUs       %cpu
----------------- ---------- ------------------------------ ---------- ----------
17/06/29 23:48:30          1 CDB$ROOT                                4        .32
17/06/29 23:48:30          2 PDB$SEED                                4          0
17/06/29 23:48:30          3 ORCL                                    4      25.87
17/06/29 23:48:30          5 ORCL2                                   4       51.3

orcl12c@SYS> @show_con_cpu.sql

TIME                  CON_ID NAME                                 CPUs       %cpu
----------------- ---------- ------------------------------ ---------- ----------
17/06/29 23:49:31          1 CDB$ROOT                                4        .03
17/06/29 23:49:31          2 PDB$SEED                                4          0
17/06/29 23:49:31          3 ORCL                                    4      25.31
17/06/29 23:49:31          5 ORCL2                                   4      50.74


しかし、おとといの無茶振りというか、俺、何スレッドで動作すればいいの的な、パススルーな振りに、疲れて
こんなネタにしてみましたよ。と。w

投稿日時 2017年7月 1日 (土) 15時00分 チューニング, Oracle Database 12c release 1, Resource Manager, マルチテナント, Oracle Database 12c Release 2 | | | コメント (0) | トラックバック (0)

2014年8月23日 (土)

IO Resource Manager 関係のメモ

黒い画面の好きなyskwkzhrさんも気に入るよね、きっと :)


PART 1 of 4 "Test interdatabase consolidation with Oracle Exadata IORM"

PART 2 of 4 "Test interdatabase consolidation with Oracle Exadata IORM"

PART 3 of 4 "Test intradatabase consolidation with Oracle Exadata IORM"

PART 4 of 4 "Test intradatabase consolidation with Oracle Exadata IORM"


ここで使ってるモニターリングツールはSwingbenchでも有名なDominic Gilesさんのサイトね。ステキです:)
Database Time Monitor
CPU Monitor
Monitor DB

投稿日時 2014年8月23日 (土) 08時33分 Oracle Database 11g Release 2, パフォーマンス, Exadata Machine, Resource Manager, IO Resource Manager | | | コメント (0) | トラックバック (0)