プロセス別の PTE は /proc/[pid]/status の VmPTE で確認できる

$ cat /proc/1741/status
Name:   bash
State:  S (sleeping)
Tgid:   1741
Pid:    1741
PPid:   1740
TracerPid:      0
Uid:    1200    1200    1200    1200
Gid:    54321   54321   54321   54321
FDSize: 256
Groups: 54321 54322 54323 54324 54325 54326 54327 
VmPeak:   108516 kB
VmSize:   108516 kB
VmLck:         0 kB
VmHWM:      1968 kB
VmRSS:      1968 kB
VmData:      468 kB
VmStk:       136 kB
VmExe:       848 kB
VmLib:      1876 kB
VmPTE:        72 kB ★
VmSwap:        0 kB
Threads:        1
SigQ:   0/47806
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000010000
SigIgn: 0000000000384004
SigCgt: 000000004b813efb
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed:   f
Cpus_allowed_list:      0-3
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        97
nonvoluntary_ctxt_switches:     34

1年前に自分で書いてた。。。
Linux のページテーブルのサイズの見方と見積式 - ablog

参考

• proc(5) - Linux manual page
• http://d.hatena.ne.jp/naoya/20080727/1217119867

Awr1page

AWR Ambiguity: Performance reasoning when the numbers don't add up
DB Time < DB CPU + Wait Time になっている理由は、db file parallel/sequential read はシステコール発行から返ってくるまでの時間で、その中にはOSカーネルが ON CPU で使う時間が含まれ、DB CPU(Linuxなら getrusageで取得)にも含まれるのでダブルカウントされるからという話。しかし、1回のI/Oシステコールあたり 1ms もCPU時間を使うのは遅すぎる。perf や ftrace でプロファイリングすれば原因特定できそう。

Awr1page - Sanity checking time instrumentation in AWR reports
AWRレポートのOSSTAT、TIME MODEL、ASH をマトリックスにすると、システコールの先でカーネルモードでCPU使ってる時間が長くてダブルカウントされるケースや、ランキュー待ちや AIX on Power(SMT) で DB CPU にも待機にもカウントされないケースを状況証拠から推定できますよという深イイ話。

NVDIMMのホワイトペーパー

赤井さん、伊藤さん、長谷川さんに教えてもらった、NVDIMMの検証結果。
SSDの限界を超えるアプリケーション高速化、「NVDIMM」の導入効果は？／日本ヒューレット・パッカード株式会社 [SSD／半導体ストレージ／フラッシュストレージ] 事例・サービス資料等 | 【TechTargetジャパン ホワイトペーパー ダウンロードセンター】 ITに関する製品や企業の情報総合サイト
PCIe接続SSDに比べて14倍高速！アプリケーションの性能不足をHPE ProLiant Gen9 サーバー + NVDIMMテクノロジーが解決：不揮発性メモリテクノロジーがアプリケーション性能を大幅加速 - ＠IT

Oracle Database の Wait Time と CPU Time が１つの Flame Graph に

Oracle Database の Wait Time と CPU Time が１つの Flame Graph に、素晴らしい！
I/Oシステムコール発行時に実はカーネルコードが ON CPU で時間を使っていたというようなケースも腕ひしぎ十字固めで一本。それくらいならAWRレポートだけでも Awr1page 的アプローチで三角絞めで落とせるけど。
もっと難しい DB CPU の割合が高く特定のSQLではなく特定の関数でCPU時間を消費しているケースも無双転生できる(Mixしなくても普通の Flame Graph でできるけど、一枚って素敵)。

perf_events : Off/On/Mixed CPU flamegraph extended with oracle wait events | Hatem Mahmoud Oracle's blog

InnoDB の Double Write の話

"Partial page writes is when page write request submited to OS completes only partially. "
MySQL のストレージエンジン InnoDB は partial page writes を防ぐ為に double write という機能がある。page は Oracle Database でいう block。Partial page writes は Oracle Database で言うブロック破損。ユーザープロセスがI/Oシステムコールを発行して、カーネルモードにスイッチ後、以下のレイヤーで一部しか書けてなかったというケース。Oracle Database でソフトウェア的に partial page writes を検知する仕組みは DB_ULTRA_SAFE パラメータのような機能だけど、書込み時は検知できない。Oracle Database on Oracle Linux + ストレージでユーザー空間、カーネル空間、ストレージまで、フルスタックで書込み時に partial page writes を検知するのが T10 DIF/DIX。

https://oss.sios.com/oracle-ch/t10dif-oraclelinux

Flame Graph を使った Java-on-JDBC vs. PLSQL の分析

Oracle Real-World Performance チームの Toon Koppelaars の Flame Graph を使った Java-on-JDBC vs. PLSQL の分析面白い。

The Helsinki Declaration (IT-version): NoPlsql vs ThickDB: which one requires a bigger database server?