読者です 読者をやめる 読者になる 読者になる

Linux のページ回収まわりのカーネルパラメータ

Linux(kernel 2.6.32-303 以降)のDBサーバでメモリ16GB、スワップ領域16GBの場合、ざっくりこんな感じが良いかなという妄想メモ。

vm.swapiness=1
vm.overcommit_memory=2
vm.overcommit_ratio=80
vm.min_free_kbytes=524288
vm.extra_free_kbytes=1048576(kernel 3.5以降)
  • vm.swappiness=1 でページアウトよりページキャッシュ解放を優先させる。kernel 2.6.32-303 以降、0 にすると OOM Killer が発動しやすくなるらしいので、1 にする。
  • vm.overcommit_memory=2 でオーバーコミットしないようにして、OOM Killer が発動しにくくする
  • vm.overcommit_ratio=80 で仮想メモリ割当をメモリサイズ + スワップ領域のサイズ * 80% にする。
  • vm.min_free_bytes をデフォルト(動的に導出される)より大きめに設定し、余裕を持ってページ回収する。
    • 512MB に設定すると、空きメモリが640MB(low pages)を下回ると kswapd がページ回収を開始し、768MB(high pages)を超えるとやめる。空きメモリが 512MB を下回るとプロセスがメモリ要求時に同期でページ回収が実行される(direct reclaim)。
  • kernel 3.5 以降なら、vm.extra_free_kbytes を設定して、low pages、high pages に 1GB 加算し direct reclaim が発生しにくくする。
  • メモリ使用率監視閾値(アラート)が 90% なら、low pages がメモリの 10%+α くらいにすると良さげな気がする。

Solaris テイストになりました。
80%、512MB、1GB は割と適当です。


ページ回収まわりでは zone_reclaim_mode も気になるところ。

RHEL6.4(kernel 2.6.32-303)以降の vm.swappiness=0 と OOM Killer の関係

RHEL6.4(kernel 2.6.32-303)以降、vm.swappiness=0 にすると OOM Killer が発動しやすくなるので、1 にしましょうという話を見かけるのでメモ。詳しくは後日調べる予定。

Warning: Since Red Hat
Enterprise Linux 6.4, setting swappiness to 0 will even more aggressively avoid swapping out, which increases the risk of out-of-memory (OOM) killing under strong memory and I/O pressure. To achieve the same behavior of swappiness as previous versions of Red Hat Enterprise Linux 6.4 in which the recommendation was to set swappiness to 0, set swappiness to the value of 1. The recommendation of swappiness for Red Hat Enterprise Linux 6.4 or higher running Oracle databases is now the value of 1.

This obviously changed the way we think about “vm.swappiness=0”. Previously, setting this to 0 was thought to reduce the tendency to swap userland processes but not disable that completely. As such it was expected to see little swapping instead of OOM.
This applies to all RHEL/CentOS kernels > 2.6.32-303 and to other distributions that provide newer kernels such as Debian and Ubuntu. Or any other distribution where this change has been backported as in RHEL.

https://www.percona.com/blog/2014/04/28/oom-relation-vm-swappiness0-new-kernel/

disk_asynch_io=false ならASMに対して同期I/O(pwrite)になる

As you know ASM is doing non (operating system) buffered I/O (also known as ‘DIO’ or Direct I/O) regardless of the oracle database filesystemio_options parameter.

But what’s about : Asynchronous/Synchronous I/O ?

If you have a look to MOS note [ID 751463.1] you’ll see that ASM asynchronous/synchronous I/O is entirely controlled by the DISK_ASYNCH_IO parameter and not the FILESYSTEMIO_OPTIONS one.

At the time being, this note only deals with 10.2 databases, so I want to check if this is still the case with 11.2 databases (Let me tell you than I hope so ;-) ) :


...

Conclusion :
With 11.2 databases, ASM asynchronous/synchronous I/O is still entirely controlled by the DISK_ASYNCH_IO parameter

ASM Asynchronous or Synchronous I/O | bdt's oracle blog

まとめると、Oracle Database(10.2-11.2) on Linux でデータベースファイルを ASM に置いている場合、

  • filesystemio_options は非同期I/O(io_submit and io_getevents or 同期I/O(pwrite)とは関係ない
  • disk_asynch_io=true(デフォルト)なら、非同期I/O(io_submit and io_getevents)だが、false なら同期I/O(pwrite)になる

ということが書かれています。

ここでの同期 or 非同期は O_SYNC or not の話ではありません。Oracle Database は I/O がロストしないよう常に O_SYNC で I/O を行います。

physical reads prefetch warmup

今更なネタですがメモ。
Oracle Database (10.1以降)でバッファキャッシュがスカスカの場合、アクセスパスが INDEX UNIQUE/RANGE SCAN でも db file scattered read でマルチブロックリードすることがある。
これはブロックにアクセスするついでに近くのブロックもそのうちアクセスされると予測してバッファキャッシュに乗せて、以降の処理を高速化する意図があると思われる。

まとめ

  • INDEX UNIQUE/RANGE SCAN などで db file sequential read でなく db file scattered read が発生している
  • SQLトレース、V$SQLSTATS、DBA_HIST_SQLSTAT などで、physical reads より logical reads が少ない(そのSQLで使わないブロックを physical read している)
  • V$SESSTAT、V$SYSSTAT、DBA_HIST_SYSSTAT などで以下の統計値がカウントアップされる
    • physical read total multi block requests: マルチブロックリードが発生している
    • physical reads cache prefetch: マルチブロックリードでプリフェッチが発生している
    • physical reads prefetch warmup: バッファキャッシュのウォームアップのため、マルチブロックリードでプリフェッチが発生している
  • _db_cache_pre_warm で制御できる

Oracle Database on Linux で SGA(共有メモリ) のスワップアウトを防ぐ方法

  • Oracle Database の初期化パラメータ SGA_LOCK = true を設定する
  • SGA(共有メモリ) に HugePages を使う
  • Linuxカーネルパラメータ vm.swappiness=0 にする(Linux Kernel 3.5 未満は 0 にしてもページアウトされることがある)

"ipcs -um"で共有メモリがスワップアウトされているか確認する

ipcs -um の "pages swapped" がスワップアウト(ページアウト)されたページ数。
これに 4KB を掛けるとページアウトされたサイズを算出できる。

$  ipcs -um
------ Shared Memory Status --------
segments allocated 39
pages allocated 3464 ★仮想メモリに割当てられたページ数
pages resident  2803 ★物理メモリを使用しているページ数
pages swapped   0 ★スワップアウト(ページアウト)されているページ数
Swap performance: 0 attempts	 0 successes

上記例では、0 だが、例えば 10 の場合、10 * 4KB = 40KB がページアウトされた共有メモリサイズになります。

書籍”Oracle の現場を効率化する100の技”の紹介

この本を一言で言うと「オラクルコンサルタントのノウハウモロ見せ」です。

Oracleの現場を効率化する100の技

Oracleの現場を効率化する100の技

困った時の辞書として、現場に置いておくと必ず役に立つ一冊です。
本のタイトルはTips集ぽいですが、一つ一つの技が深く濃く、これで2,980円はお買い得です。
詳細は Oracleの現場を効率化する100の技:書籍案内|技術評論社 をご覧ください。

著者

個性豊かな面々が執筆しています。

内容紹介

一部紹介しますが、これだけでも深さと濃さが分かると思います。

  • 17 スピーディーにトラブルの原因を切り分けるテクニック

  • 37 共有プール設計の勘所

  • 40 PGA_AGGREGATE_TARGET が想像以上に増加する原因と対策

  • 42 ラージページで大規模メモリ環境でのトラブルに対処する

  • 98 ヒートマップを利用して、発生頻度を直感的に把握する

目次

第1章 パフォーマンス管理のTips
1 実行計画を理解する
2 適切な表の結合方法の選択と定石
3 カバーリングインデックスでアクセスブロック数を減らす
4 NOT IN句でパフォーマンスが出ない場合の対応法
5 パーティションを活用してアクセスブロック数を減らす
6 SQLをパラレルクエリで高速化する方法
COLUMN アプリケーションによるパラレル化の注意点
7 大量レコードのINSERTを高速化する方法
8 SPMを使って実行計画を管理する
COLUMN SQL計画管理とは
9 SPMアーキテクチャを理解する
COLUMN SPMの登録方法
10 SPMを利用したハード解析の仕組みを理解する
COLUMN SIGNATUREとPLAN_ID
11 SPMへ実行計画を登録する
12 SPMが利用できていることを確認する
13 SQLを書き変えずに実行計画を変更する
14 過去の実行計画でSQLを実行する
COLUMN SQLチューニングセット(STS)
15 SPMを別データベースへ移行する
16 システム開発でのSPM導入の勘所
第2章 トラブルシューティングのTips
17 スピーディにトラブル原因を切り分けるテクニック
COLUMN Oracleのエラー内容の確認方法
18 AWRのイベントの一歩進んだ見方
19 インターコネクトのボトルネックを見つけ出すパフォーマンス分析のコツ
20 2つのAWRレポートをスマートに比較する
21 自動パフォーマンス診断機能を使う
22 遅いSQLの原因を自動的に分析する
COLUMN SQLチューニングの事前スクリーニング
23 既に実行されたSQLと実行計画を取得する〜AWRとV$SQL〜
24 SQLが遅いと感じたときのチェックリスト
25 実行時間の長いSQLを調査する
26 ASHを利用して今起きている問題や短期間の問題を分析する
27 待機イベントのパラメータ列からセグメントを特定する
28 物理I/Oを減らす〜待機イベント処方箋(1)
29 一時表領域へのアクセスを減らす〜待機イベント処方箋(2)
30 SQL情報を漏れなく取得する
COLUMN 特定のSQLのトレースのみを取得する方法
31 実行計画が変化した原因を調査する
32 SQL性能分析情報を取得する
33 ADRCIを使ってスムーズにサポート問合せをする
第3章 アーキテクチャのTips
34 自動メモリ管理機能の使いどころを理解する
35 自動共有メモリ管理機能の調整ルールとIMMEDIATEモードを理解する
36 共有プールの仕組みを理解してORA-4031エラーを防ぐ
37 共有プール設計の勘所
COLUMN DEFERREDモードと,IMMEDIATEモード
38 共有プールを効果的に監視する
39 PGAのメモリ増加を抑える
40 PGAが想像以上に増加する原因と対策
41 PGA_AGGREGATE_TARGETが実行計画に与える影響
42 ラージページで大規模メモリ環境でのトラブルに対処する
43 オンライン索引再構築と通常の索引再構築を使い分ける
44 索引の作成順番が実行計画に与える影響を理解する
45 意図しないパラレルクエリの実行を防ぐ
46 削除処理の高速化テクニック
47 NOLOGGINGオペレーションを効果的に使う
48 NOLOGGINGオペレーションの副作用に注意する
49 ロールバックの時間を見積もる
50 コネクションプーリングが使えない環境で新規接続を高速化する
第4章 開発・運用に役立つTips
51 SQL*Plusを使いこなす作業効率化技
52 SQL*Plusを使いこなす検証技
53 SQL*Plusを使いこなすトラブルシュート技
54 オブジェクトの定義情報を確認してSQL文を簡単に作成する
55 簡単にテストデータを作成する
56 PL/SQLのボトルネックを調査する
57 Enterprise Managerを使って簡単かつ確実にDBオブジェクトを管理する
58 Enterprise Managerを使って定期的にDB稼働状況の詳細なレポートを作成する
59 Enterprise Managerを使ってリアルタイムにSQL実行状況を監視する
COLUMN リアルタイムSQL監視のSQL実行計画行数制限について
60 データベースの状況をリアルタイムで把握する
61 簡単にOSリソース情報を取得する方法
62 長時間のSQL実行をタイムアウトさせる
63 データベースのOSリソース使用を制御する
64 データベースのOSリソース使用の制御内容を確認する
65 データベースに接続できるクライアントを制限する
66 アプリケーションサーバーとデータベースサーバー間で発生した無効接続を検知する
COLUMN 無効接続を検知する新機能
67 簡単にインデックスの効果を検証する
68 統計情報を操作して本番機の実行計画を再現する
69 セグメントの断片化解消効果を見積もる
COLUMN セグメントの断片化の仕組み
70 AUTOTRACE機能で簡単にSQLの実行計画を確認する
71 ボトルネックを調べるためSQLトレースを取得する
COLUMN SQLトレースのファイル名に任意の文字列を埋め込む
COLUMN 現在のセッションIDを調べる
72 外部表を使ってcsvファイルをSQLで扱う
73 隠し初期化パラメータを確認する
74 バッチ処理の進捗状況をログ出力する
75 調べたい内容が書かれたマニュアルを効率的に探す方法
第5章 システムテストのTips
76 システムテストを自動化するときの注意点
77 DBサーバを中心としたシステムテストをする
COLUMN インストール時にRATオプションを選択し忘れた!
78 SQL単位のパフォーマンステストを自動化する
79 SQLチューニングセットを作成する
80 SQLチューニングセットをテスト環境に移行する
81 SQLパフォーマンスを比較する
82 SQLチューニングアドバイザと連携する
COLUMN SQLプロファイル
83 SPAを上手に使うためのテクニック
84 DB Replayで本番環境の負荷を再現する
85 ワークロードをキャプチャする
86 DB Replayに必要な前処理をする
87 ワークロードをリプレイする
88 本番とリプレイのパフォーマンスを比較する
89 DB Replayの負荷を調節する
90 DB Replayを上手に使うためのテクニック
第6章 データマイニングのTips
91 Oracle Rの特徴とデータ分析の目的を把握する
COLUMN Rとは?
92 データベースにRからアクセスして統計解析する
COLUMN アソシエーション分析とは?
93 データベースからRへアクセスする
COLUMN Rパッケージについて
94 Rから表計算ソフトにアクセスする
COLUMN クラスター分析とは?
95 Rのデバッグやボトルネックを発見するテクニック
COLUMN OSのstraceコマンドも強力なツール
96 バイトコードコンパイルでRの実行を高速化する
COLUMN オブジェクトの入出力はバイナリ形式で高速化
97 Rのメモリー使用量を制限する
98 ヒートマップを利用して,発生頻度を直感的に把握する
COLUMN パッケージのインストール方法
99 3次元グラフを利用して類似度を直感的に把握する
COLUMN 過去の問い合わせ内容をデータベースに格納するサンプルスクリプト
100 ワードクラウドで膨大なデータを視覚化する
COLUMN Twitterのアプリケーションを作成するには?