[db tech showcase Tokyo 2015] B15:最新PostgreSQLはパフォーマンスが飛躍的に向上する！？ - PostgreSQLのCPUスケーラビリティについて - by NTT OSSセンタ山田達朗

Copyright©2015 NTT corp. All Rights Reserved.
最新PostgreSQLはパフォーマンスが
飛躍的に向上する！？
- PostgreSQLのCPUスケーラビリティについて -
2015年6月10日
NTT OSSセンタ
山田達朗

2Copyright©2015 NTT corp. All Rights Reserved.
１．はじめに
２．検証概要
３．検証結果
４．おわりに
アジェンダ

１．はじめに
NTT OSSセンタ紹介
PostgreSQLについて
PostgreSQLの進化とOSSセンタの関わり
PostgreSQLコミュニティへの貢献
２．検証概要
３．検証結果
４．おわりに

グ
ル
ー
プ
各
社
目的
OSS活用によるNTTグループのシステムのTCO削減
下記①〜④の4つのミッションでグループ事業に貢献
DBMSについてはPostgreSQLを推進
技術者育成、
⼈材交流
各種
ＯＳＳ
コミュニ
ティ
サポート
ベンダ、
NTT
研究所等
開発
連携
サポート
連携
①OSSトータル
サポート
NTT OSSセンタ
②OSS適用推進
(製品組合せ検証)
③技術開発
(DBMS,HA等)
④ソフトウェア
基盤技術⼒向上
NTT OSSセンタの紹介
プロダクト/
ツール類の開発
問合せ対応、
導入支援、
プロダクト保守
技術検証、
検証済OSS
の導入推進
お
客
様
NTT

OSSのRDBMS。エンタープライズ用途での利用も可能。
NTTでは多数のシステムで導入済。
PostgreSQLの良さ
機能
• 必要機能はほぼ完備、さらに独自拡張も可能
性能
• 参照クエリがメイン：他DBMSと比較しても遜色無し
• 更新クエリがメイン：少々注意が必要
品質
• 不具合発⽣率は非常に少ない
2014年度問合せ件数(NTT内) 308件中既知バグ｢2件｣, 新規バグ｢0件｣
ライセンス、コスト
• PostgreSQLライセンスで商用利用しやすい。
ライセンスコストは無償。
PostgreSQLについて

8.4(2009/7)
8.2
8.1
8.3(2008/2)
【黎明期】
小中規模構成をターゲット
商用DBMSと同等の機能、性能向上
2012
2006
2013
2005
2014
2008
2011
2010
2007
2009
OSSｾﾝﾀ設⽴
NTT参画
•HOT: 更新性能向上
•VACUUM自動化
PostgreSQLのエンタープライズ適用に向けた進化を
OSSセンタの活動状況と合わせてご紹介
Step1. 追いつけ！商用DBMS

9.1(2011/9)
9.0(2010/9)
8.4(2009/7)
8.2
8.1
8.3(2008/2)
【黎明期】
商用DBMSと同等の機能・性能向上
2012
2006
2013
2005
2014
2008
2011
2010
2007
2009
OSSｾﾝﾀ設⽴
NTT参画
Step2. 信頼性/可用性、移⾏性の向上
【発展期】
大規模構成、適用領域拡大に向けた
・機能性向上
・商用DBMSからの移⾏性向上
•同期/非同期レプリケーション
•移⾏ツール（db_syntax_diff）

9.4(2014/12)
9.1(2011/9)
9.0(2010/9)
8.4(2009/7)
8.2
8.1
8.3(2008/2)
【黎明期】
商用DBMSと同等の機能・性能向上
2012
2006
2005
2014
2008
2011
2010
2007
2009
OSSｾﾝﾀ設⽴
NTT参画
Step2. 信頼性/可用性、移⾏性の向上
Step3. MCシステムへの導入
(ミッションクリティカルシステム)
9.3(2013/9)
9.2(2012/9)
2013
【発展期】
大規模構成、適用領域拡大に向けた
・機能性向上
・商用DBMSからの移⾏性向上
【今後】
MCシステム適用
・レプリケーション
・外部データラッパー

NTT OSSセンタの貢献を一部ご紹介 (2014年度)
◆年間パッチ採用数
• PostgreSQL本体：39件
• PostgreSQL周辺ツール：30件
◆講演
• PGCon cluster summit
• PGECons PostgreSQL事例セミナー
• JPUG PostgreSQLカンファレンス
⇒コミュニティとの協業、オープンイノベーション
⇒PostgreSQL⾼度化に貢献
PostgreSQLコミュニティへの貢献

◆疑問点
最新PostgreSQLはパフォーマンスが
飛躍的に向上するでしょうか？
ここから本題！
レスポ
ンス
スルー
プット
CPU I/O

１．はじめに
２．検証概要
目的
アプローチ
検証条件
ベンチマークツール
検証環境
サーバアーキテクチャ
CPUコアの使用方法
３．検証結果
４．おわりに

目的
◆なぜCPUスケーラビリティ検証を⾏ったのか？
メニーコア
ボトルネック
LWLock
OLTP
スケールアップ
スキル向上
技術の目利き
①過去から続くボトルネックLWLockは改善？
②パフォーマンスは向上しているのか？

LWLockの補足
Heavy weight Lock
SQLレベルのロック。
Select for updateなどで利用
Light weight Lock(LWLock)
PostgreSQLの内部的なロック
共有バッファの排他制御などで利用
昔からボトルネックの原因
Spin Lock(s_lock)
リソースを排他制御するための最小のロック
Atomicな命令で実装（TAS）、ロック失敗時にスピン
LWLockは
s_lockを利用

ベンチマークツール
◆CPUスケーラビリティを確認するために
TPC-Wベースのツールを利用
DBサーバ
ストレージ
CPU
ボトルネックになりやすい
サーバリソース
コア数
ス
ル
ー
プ
ッ
ト
結果のイメージ
TPC-W実⾏
どこまで
スケールするか？

◆最⾼性能だけを狙った検証条件を採用したのか？
⇒NO.
商用システムとしてありえる現実的なものを
目指した。
一部紹介
◆PostgreSQL
• 測定期間中にチェックポイントが定期的に発生
• アーカイブログ出⼒あり
• データ量1TB
• 共有バッファ1TB
など
◆測定方法
• ランプアップ30分、本測定30分
検証条件
CPUネックにするため

検証環境
Data用ストレージ
HP 3PAR StoreServ 7450
L3 Switch
HP 5900AF-48XGT-4QSFP
Clientサーバ（負荷サーバ）
HP ProLiant DL360 Gen9
Boot用ストレージ
HP 3PAR StoreServ 7400
FC Switch
HP SN3000B
DBサーバ
HP Superdome X
FiberChannel 16Gb
10GBASE-T

ハードウェア構成
ソフトウェア構成
HW 製品名台数仕様
DBサーバ HP Superdome X 1 CPU ：Intel Xeon E7-2890v2 2.8GHz
(16P240C)
メモリ：12TB
ストレージ HP StoreServ7450 2 ディスク：SSD 480GB 32本 RAID10
負荷サーバ HP DL360Gen9 5 CPU：Intel Xeon E5-2650v3 2.3GHz (2P24C)
メモリ：128GB
SW 製品名バージョン
OS Red Hat Enterprise Linux 6.5 x86_64
DBMS PostgreSQL 9.3.5(以降PG935)
9.4.0(以降PG940)
9.5dev(以降PG95dev)hash:d88976c
ベンチマーク
ツール
TPC-Wベースのツール OSSセンタ改良版DBT-1
検証環境

◆一般的によく使用されるサーバのNUMA構成のイメージ
DL360Gen9
ノード0 ノード1

◆Superdome X は以下のイメージ
• 複数ブレードで構成
• インターコネクトが存在。メモリのアクセスコストに違いあり。
ブレード１
Interconnect Fablic
ブレード３
ブレード５
ブレード７
ブレード２
ブレード４
ブレード６
ブレード８
Superdome X

多数のCPUコアをどのように使用する？
◆ノード単位で使用する
• 事前検証により、ハイパースレッドを有効とした
• ノードとブレードまたぎのメモリアクセスを極⼒抑えたい
ブレード１
Interconnect Fablic
ブレード３
ブレード５
ブレード７
ブレード２
ブレード４
ブレード６
ブレード８

１．はじめに
２．検証概要
３．検証結果
測定結果
実⾏計画、OSリソースを⾒る
ボトルネックは？
〜省略〜
まとめ
４．おわりに

測定結果
◆質問
PG935 vs PG940 vs PG95devのうち、
最もスループットが出たのはどれか？

測定結果
コア数
スループット（BT/sec.）
PG935 PG940 PG95dev
15 1,714.90 2,461.30 -
30 2,374.00 3,328.60 6,615.40
45 1,377.50 5,640.20 -
60 1,120.40 5,149.30 7,733.50
90 - - 7,741.30
120 661.10 2,448.00 7,424.70
180 1382.30 1,990.10 -
240 492.90 1,737.90 7,229.30
負荷 80000EU
DBサイズ 1TB
共有バッファ 1TB
接続数 200
0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
0 30 60 90 120 150 180 210 240 270
スループット(BT/sec.)
コア数
PG935 PG940 PG95dev
◆答え
PG95dev

測定結果
0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
0 30 60 90 120 150 180 210 240 270
コア数
PG935 PG940 PG95dev
◆PG935,PG940,PG95devを比較してみると
最高スループット（倍率）
1 : 2.4 : 3.3
PostgreSQLの性能は向上している！

測定結果
0
1,000
2,000
3,000
4,000
5,000
6,000
7,000
8,000
9,000
0 30 60 90 120 150 180 210 240 270
コア数
PG935 PG940 PG95dev
◆PG935,PG940,PG95devを比較してみると
何コアまで使えるか
30：45：60
使用可能なコア数は増加している！
最高スループット（倍率）
1 : 2.4 : 3.3

実⾏計画やOSリソースを⾒る(1/3)
◆実⾏計画
変動なし
◆NW帯域
問題なし
◆クライアント
問題なし
◆OSリソース
I/Oネックでは無い ⇒CPU使用率を⾒てみます

0
20
40
60
80
100
15 30 45 60 90 120 240
%user %system %iowait
0
20
40
60
80
100
15 30 45 60 90 120 240
0
20
40
60
80
100
15 30 45 60 90 120 240
%user %iowait %iowait
◆CPUの平均使用率を紹介。%userに着目してみる。
PG935
PG940
PG95dev
93%
74%
77%
59%
35%
17%
さらに
実質的なコア数＝コア数 × %user
を算出すると、
PG935 PG940 PG95dev
60コア時： 56コア 45コア 46コア
240コア時：142コア 84コア 41コア
240コア時に注目すると、
実質的なコア数に違いがある

0
20
40
60
80
100
15 30 45 60 90 120 240
0
20
40
60
80
100
15 30 45 60 90 120 240
0
20
40
60
80
100
15 30 45 60 90 120 240
%user %iowait %iowait
◆実質的なコアあたりのスループットを計算すると、
PG935
PG940
PG95dev
単位スループット＝スループット／コア数
PG935 PG940 PG95dev
60コア時： 20 114 168
240コア時： 3 21 177
93%
74%
77%
59%
35%
17%
コアの使用効率が違う。
なぜ約８倍も違うのか？
0
2,000
4,000
6,000
8,000
10,000
0 30 60 90 120 150 180 210 240 270
コア数
PG935 PG940 PG95dev

◆コア毎のCPU使用率を⾒ると
0
50
100
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59
使用率(%)
core 番号
%iowait %system %user
PG940 60コア
PG95dev 60コア
0
50
100
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59
使用率(%)
core 番号
⇒共に%iowaitは無く、CPUネックの状況。
※ core番号1〜60は0〜14 ,15〜29,240〜254,255〜269に対応
※
※

◆コア毎のCPU使用率を⾒ると
0
50
100
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59
使用率(%)
core 番号
PG940 60コア
PG95dev 60コア
0
50
100
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59
使用率(%)
core 番号
⇒共に%iowaitは無く、CPUネックの状況。
0
2,000
4,000
6,000
8,000
10,000
0 30 60 90 120 150 180 210 240 270
コア数
PG935 PG940
グラフに違いは無いがスループットに違いがある。
昔からのボトルネックLWLockはどうなった？

PostgreSQLのボトルネックは？
◆PG940内の時間が掛かっていた関数を調査した
s_lock
約80％UP
Perf結果 PG940
8.78
63.22
0
10
20
30
40
50
60
70
80
90
100
30 コア 60 コア 240 コア
割合(%)
hash_search_with_hash_value
PinBuffer
slot_deform_tuple
heap_hot_search_buffer
LWLockRelease
LWLockAcquire
s_lock
PG95devではどうなっている？
LWLock
s_lockが足を引っ張っている！

◆PG95dev内の時間が掛かっていた関数を調査した
s_lock
大幅減少
Perf結果 PG95dev
0
10
20
30
40
50
60
70
80
90
100
30 コア 60 コア 240 コア
割合(%)
PinBuffer
slot_deform_tuple
LWLockRelease
LWLockAcquire
LWLock
PG940で目⽴っていたs_lockが消えた

8.78
63.22
0
10
20
30
40
50
60
70
80
90
100
30 コア 60 コア 240 コア
割合(%)
PG940
PinBuffer
slot_deform_tuple
LWLockRelease
LWLockAcquire
s_lock
◆PG940 と PG95devの比較
0
10
20
30
40
50
60
70
80
90
100
30 コア 60 コア 240 コア
割合(%)
PG95dev
PinBuffer
slot_deform_tuple
LWLockRelease
LWLockAcquire
⻑年のボトルネックLWLock(s_lock)が改善された！
LWLock
LWLock

PG95devで s_lock は改善された？
◆s_lockとは（再掲）
• リソースを排他制御するための最小のロック。
• LWLockから多数呼び出される。ロック失敗時はスピン。
◆PG95devではLWLock周りが改善された
LWLock改善のパッチ
• Add a basic atomic ops API abstracting away
platform/architecture details. →atomic操作のAPI改善
• Improve LWLock scalability. →LWLockの改善
共有バッファ利用時の競合回避のパッチ
• Increase the number of buffer mapping partitions to 128.
→共有バッファの管理表分割数の改善
• Lockless StrategyGetBuffer clock sweep hot path.
→共有バッファ取得時のロック削減

◆Increase the number of buffer mapping partitions to 128.
概要
共有バッファの管理テーブルの分割数を増やした
（NUM_BUFFER_PARTITIONS 9.4まで 16 → 128）
効果
ロックの衝突確率の削減（競合低減）
・9.4まで
分割数が少ないため、高負荷時に衝突多発。
待ちが発⽣しやすい。
・9.5から
分割数が増えたため、衝突確率が減少。待ちが軽減。

◆Increase the number of buffer mapping partitions to 128.
00 11 22 〜〜 1515
ディスクのブロック
共有バッファ上の
ブロック
16分割
管理テーブル
ロックは16個しか
取れなかった00 127
before after
128分割
16 128
ディスクのブロック
共有バッファ上の
ブロック
並列度向上！競合減少！待ち減少！

①過去から続くボトルネックLWLockは改善？
②パフォーマンスは向上しているのか？
ここまでを整理すると、
PG95dev s_lock大幅削減に伴い改善した。
スループットはPG935と比較し、
PG940 ２倍向上（ピーク：４５コア）
PG95dev ３倍向上（ピーク：６０コア）
⇒YES
⇒YES
good

PG95dev 60コア以上を使えなかった理由は？
PostgreSQL
・LWLock以外のボトルネック？
OS
検証ではRHEL6.5を利用したが、
6.6以降や7でメニーコアに効く改善がある模様・・・
HP社のRHEL改善に関する資料（LinuxCon North America 2014）
http://events.linuxfoundation.org/sites/events/files/slides/linux
con-2014-locking-final.pdf
⇒OSのspinlockを改善し性能向上？

◆postgresプロセスのsleep状況(psでWCHANを調査)
PG95dev 60コア以上を使えなかった理由は？
0%
20%
40%
60%
80%
100%
3
13
23
33
43
53
63
73
83
93
103
113
wait
sync_page
semtimedop
poll_schedule_timeout
ext4_llseek
-
0%
20%
40%
60%
80%
100%
3
13
23
33
43
53
63
73
83
93
103
113
sync_page
semtimedop
poll_schedule_timeout
-
poll_schedule_timeoutが
増えているのが怪しいが・・
select/pollシステムコール？
sleepする箇所の調査と
カーネルのプロファイリング
もやった方が良さそう。
to be continued.
30コア
240コア

PostgreSQL
• 次なるボトルネック調査
• Increase the number of buffer mapping partitions to 128.
128が最適？
• プロセスがSleepしている原因
OS
• 最適なチューニングパラメータ
DBに最適なパラメータは？RHEL7のプロファイルは？
• affinity設定時の性能
プロセス、CPU、メモリを括りつけ、キャッシュヒット率向上
さらにスケールさせるために今後明らかにしたいこと
⇒H/W性能を引き出し、PostgreSQLの適用領域を増やす

まとめ
大規模なメニーコアのサーバに対しても、
PostgreSQLは年々進化しているため、
有効活用できる！
過去から言われ続けていたボトルネック
LWLockは改善した！
パフォーマンスは向上し続けている！

１．はじめに
２．検証概要
３．検証結果
４．おわりに

NTT OSSセンタは、
これからも PostgreSQL を用いて
付加価値を提供いたします。
みなさんも一緒に使ってみませんか！
コミュニティと共に

ご清聴ありがとうございました。
"elephants beach walk" by Senorhorst Jahnsen is licensed under CC BY 2.0

[db tech showcase Tokyo 2015] B15:最新PostgreSQLはパフォーマンスが飛躍的に向上する！？ - PostgreSQLのCPUスケーラビリティについて - by NTT OSSセンタ山田達朗

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (18)

Ähnlich wie [db tech showcase Tokyo 2015] B15:最新PostgreSQLはパフォーマンスが飛躍的に向上する！？ - PostgreSQLのCPUスケーラビリティについて - by NTT OSSセンタ山田達朗

Ähnlich wie [db tech showcase Tokyo 2015] B15:最新PostgreSQLはパフォーマンスが飛躍的に向上する！？ - PostgreSQLのCPUスケーラビリティについて - by NTT OSSセンタ山田達朗 (20)

Mehr von Insight Technology, Inc.

Mehr von Insight Technology, Inc. (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (7)