[db tech showcase tokyo 2015]...
TRANSCRIPT
Copyright©2015 NTT corp. All Rights Reserved.
最新PostgreSQLはパフォーマンスが飛躍的に向上する!?- PostgreSQLのCPUスケーラビリティについて -
2015年6月10日NTT OSSセンタ
山田 達朗
3Copyright©2015 NTT corp. All Rights Reserved.
1.はじめにNTT OSSセンタ紹介PostgreSQLについてPostgreSQLの進化とOSSセンタの関わりPostgreSQLコミュニティへの貢献
2.検証概要3.検証結果4.おわりに
4Copyright©2015 NTT corp. All Rights Reserved.
グループ各社
�目的OSS活用によるNTTグループのシステムのTCO削減
下記①〜④の4つのミッションでグループ事業に貢献
DBMSについてはPostgreSQLを推進
技術者育成、⼈材交流
各種OSS
コミュニティ
サポートベンダ、
NTT研究所等
開発連携
サポート連携
①OSSトータルサポート
NTT OSSセンタ
②OSS適用推進(製品組合せ検証)
③技術開発(DBMS,HA等)
④ソフトウェア基盤技術⼒向上
NTT OSSセンタの紹介
プロダクト/ツール類の開発
問合せ対応、導入支援、
プロダクト保守
技術検証、検証済OSSの導入推進
お客様
NTT
5Copyright©2015 NTT corp. All Rights Reserved.
�OSSのRDBMS。エンタープライズ用途での利用も可能。NTTでは多数のシステムで導入済。
�PostgreSQLの良さ機能
• 必要機能はほぼ完備、さらに独自拡張も可能性能
• 参照クエリがメイン:他DBMSと比較しても遜色無し• 更新クエリがメイン:少々注意が必要
品質• 不具合発⽣率は非常に少ない
2014年度 問合せ件数(NTT内) 308件中 既知バグ「2件」, 新規バグ「0件」
ライセンス、コスト• PostgreSQLライセンスで商用利用しやすい。
ライセンスコストは無償。
PostgreSQLについて
6Copyright©2015 NTT corp. All Rights Reserved.
8.4(2009/7)
8.28.1
8.3(2008/2)
【黎明期】小中規模構成をターゲット商用DBMSと同等の機能、性能向上
PostgreSQLの進化とOSSセンタの関わり
2012
2006
2013
2005
2014
2008
20112010
2007
2009
OSSセンタ設⽴
NTT参画
•HOT: 更新性能向上•VACUUM自動化
�PostgreSQLのエンタープライズ適用に向けた進化をOSSセンタの活動状況と合わせてご紹介�Step1. 追いつけ!商用DBMS
7Copyright©2015 NTT corp. All Rights Reserved.
9.1(2011/9)
9.0(2010/9)
8.4(2009/7)
8.28.1
8.3(2008/2)
【黎明期】小中規模構成をターゲット商用DBMSと同等の機能・性能向上
PostgreSQLの進化とOSSセンタの関わり
2012
2006
2013
2005
2014
2008
20112010
2007
2009
OSSセンタ設⽴
NTT参画
�PostgreSQLのエンタープライズ適用に向けた進化をOSSセンタの活動状況と合わせてご紹介
�Step2. 信頼性/可用性、移⾏性の向上�Step1. 追いつけ!商用DBMS
【発展期】大規模構成、適用領域拡大に向けた・機能性向上・商用DBMSからの移⾏性向上
•同期/非同期レプリケーション•移⾏ツール(db_syntax_diff)
8Copyright©2015 NTT corp. All Rights Reserved.
9.4(2014/12)
9.1(2011/9)
9.0(2010/9)
8.4(2009/7)
8.28.1
8.3(2008/2)
【黎明期】小中規模構成をターゲット商用DBMSと同等の機能・性能向上
PostgreSQLの進化とOSSセンタの関わり
2012
20062005
2014
2008
20112010
2007
2009
OSSセンタ設⽴
NTT参画
�Step2. 信頼性/可用性、移⾏性の向上�Step1. 追いつけ!商用DBMS
�Step3. MCシステムへの導入(ミッションクリティカルシステム)
9.3(2013/9)
9.2(2012/9)
2013
�PostgreSQLのエンタープライズ適用に向けた進化をOSSセンタの活動状況と合わせてご紹介
【発展期】大規模構成、適用領域拡大に向けた・機能性向上・商用DBMSからの移⾏性向上
【今後】MCシステム適用
・レプリケーション・外部データラッパー
9Copyright©2015 NTT corp. All Rights Reserved.
NTT OSSセンタの貢献を一部ご紹介 (2014年度)
◆年間パッチ採用数• PostgreSQL本体 :39件• PostgreSQL周辺ツール :30件
◆講演• PGCon cluster summit
• PGECons PostgreSQL事例セミナー• JPUG PostgreSQLカンファレンス
⇒コミュニティとの協業、オープンイノベーション⇒PostgreSQL⾼度化に貢献
PostgreSQLコミュニティへの貢献
10Copyright©2015 NTT corp. All Rights Reserved.
◆疑問点最新PostgreSQLはパフォーマンスが飛躍的に向上するでしょうか?
ここから本題!
レスポンス
スループット
CPU I/O
11Copyright©2015 NTT corp. All Rights Reserved.
1.はじめに2.検証概要
目的アプローチ検証条件ベンチマークツール検証環境サーバアーキテクチャCPUコアの使用方法
3.検証結果4.おわりに
12Copyright©2015 NTT corp. All Rights Reserved.
目的◆なぜCPUスケーラビリティ検証を⾏ったのか?
メニーコア ボトルネックLWLock
OLTPスケールアップ
スキル向上技術の目利き
①過去から続くボトルネックLWLockは改善?②パフォーマンスは向上しているのか?
13Copyright©2015 NTT corp. All Rights Reserved.
LWLockの補足Heavy weight Lock
SQLレベルのロック。Select for updateなどで利用
Light weight Lock(LWLock)PostgreSQLの内部的なロック共有バッファの排他制御などで利用昔からボトルネックの原因
Spin Lock(s_lock)リソースを排他制御するための最小のロックAtomicな命令で実装(TAS)、ロック失敗時にスピン
LWLockはs_lockを利用
14Copyright©2015 NTT corp. All Rights Reserved.
ベンチマークツール◆CPUスケーラビリティを確認するために
TPC-Wベースのツールを利用
DBサーバ
ストレージ
CPU
ボトルネックになりやすいサーバリソース
コア数
スループット
結果のイメージ
TPC-W実⾏
どこまでスケールするか?
15Copyright©2015 NTT corp. All Rights Reserved.
◆最⾼性能だけを狙った検証条件を採用したのか?⇒NO.商用システムとしてありえる現実的なものを目指した。
一部紹介◆PostgreSQL
• 測定期間中にチェックポイントが定期的に発生• アーカイブログ出⼒あり• データ量1TB
• 共有バッファ1TB
など◆測定方法
• ランプアップ30分、本測定30分
検証条件
CPUネックにするため
16Copyright©2015 NTT corp. All Rights Reserved.
検証環境
Data用ストレージHP 3PAR StoreServ 7450
L3 SwitchHP 5900AF-48XGT-4QSFP
Clientサーバ(負荷サーバ)HP ProLiant DL360 Gen9
Clientサーバ(負荷サーバ)HP ProLiant DL360 Gen9
Clientサーバ(負荷サーバ)HP ProLiant DL360 Gen9
Clientサーバ(負荷サーバ)HP ProLiant DL360 Gen9
Clientサーバ(負荷サーバ)HP ProLiant DL360 Gen9
Boot用ストレージHP 3PAR StoreServ 7400
FC SwitchHP SN3000B
DBサーバHP Superdome X
FiberChannel 16Gb10GBASE-T
17Copyright©2015 NTT corp. All Rights Reserved.
ハードウェア構成
ソフトウェア構成
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
検証環境
18Copyright©2015 NTT corp. All Rights Reserved.
サーバアーキテクチャ◆一般的によく使用されるサーバのNUMA構成のイメージ
DL360Gen9
ノード0 ノード1
19Copyright©2015 NTT corp. All Rights Reserved.
サーバアーキテクチャ◆Superdome X は以下のイメージ
• 複数ブレードで構成• インターコネクトが存在。メモリのアクセスコストに違いあり。
ブレード1
ノード0 ノード1
Interconnect Fablic
ブレード3
ノード4 ノード5
ブレード5
ノード8 ノード9
ブレード7
ノード12 ノード13
ブレード2
ノード2 ノード3
ブレード4
ノード6 ノード7
ブレード6
ノード10 ノード11
ブレード8
ノード14 ノード15
Superdome X
20Copyright©2015 NTT corp. All Rights Reserved.
多数のCPUコアをどのように使用する?◆ノード単位で使用する
• 事前検証により、ハイパースレッドを有効とした• ノードとブレードまたぎのメモリアクセスを極⼒抑えたい
ブレード1
ノード0 ノード1
Interconnect Fablic
ブレード3
ノード4 ノード5
ブレード5
ノード8 ノード9
ブレード7
ノード12 ノード13
ブレード2
ノード2 ノード3
ブレード4
ノード6 ノード7
ブレード6
ノード10 ノード11
ブレード8
ノード14 ノード15
21Copyright©2015 NTT corp. All Rights Reserved.
1.はじめに2.検証概要3.検証結果
測定結果実⾏計画、OSリソースを⾒るボトルネックは?〜省略〜まとめ
4.おわりに
22Copyright©2015 NTT corp. All Rights Reserved.
測定結果◆質問
PG935 vs PG940 vs PG95devのうち、最もスループットが出たのはどれか?
23Copyright©2015 NTT corp. All Rights Reserved.
測定結果
コア数 スループット(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.5090 - - 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
負荷 80000EUDBサイズ 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
24Copyright©2015 NTT corp. All Rights Reserved.
測定結果
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
◆PG935,PG940,PG95devを比較してみると
最高スループット(倍率)
1 : 2.4 : 3.3
PostgreSQLの性能は向上している!
25Copyright©2015 NTT corp. All Rights Reserved.
測定結果
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
◆PG935,PG940,PG95devを比較してみると
何コアまで使えるか
30:45:60
使用可能なコア数は増加している!
最高スループット(倍率)
1 : 2.4 : 3.3
26Copyright©2015 NTT corp. All Rights Reserved.
実⾏計画やOSリソースを⾒る(1/3)◆実⾏計画
変動なし
◆NW帯域問題なし
◆クライアント問題なし
◆OSリソースI/Oネックでは無い ⇒CPU使用率を⾒てみます
27Copyright©2015 NTT corp. All Rights Reserved.
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
%user %system %iowait
0
20
40
60
80
100
15 30 45 60 90 120 240
%user %iowait %iowait
実⾏計画やOSリソースを⾒る(2/3)◆CPUの平均使用率を紹介。%userに着目してみる。
PG935
PG940
PG95dev
93%
74%
77%
59%
35%
17%
さらに実質的なコア数 = コア数 × %userを算出すると、
PG935 PG940 PG95dev60コア時: 56コア 45コア 46コア
240コア時:142コア 84コア 41コア
240コア時に注目すると、実質的なコア数に違いがある
28Copyright©2015 NTT corp. All Rights Reserved.
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
%user %system %iowait
0
20
40
60
80
100
15 30 45 60 90 120 240
%user %iowait %iowait
実⾏計画やOSリソースを⾒る(2/3)◆実質的なコアあたりのスループットを計算すると、
PG935
PG940
PG95dev
単位スループット = スループット/コア数PG935 PG940 PG95dev
60コア時: 20 114 168 240コア時: 3 21 177
93%
74%
77%
59%
35%
17%コアの使用効率が違う。なぜ約8倍も違うのか?
0
2,000
4,000
6,000
8,000
10,000
0 30 60 90 120 150 180 210 240 270
スル
ープ
ット
(BT
/sec.
)
コア数
PG935 PG940 PG95dev
29Copyright©2015 NTT corp. All Rights Reserved.
実⾏計画やOSリソースを⾒る(3/3)◆コア毎の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 %userPG940 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 %system %user
⇒共に%iowaitは無く、CPUネックの状況。
※ core番号1〜60は0〜14 ,15〜29,240〜254,255〜269に対応
※
※
30Copyright©2015 NTT corp. All Rights Reserved.
実⾏計画やOSリソースを⾒る(3/3)◆コア毎の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 %userPG940 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 %system %user
⇒共に%iowaitは無く、CPUネックの状況。
0
2,000
4,000
6,000
8,000
10,000
0 30 60 90 120 150 180 210 240 270
スル
ープ
ット
(BT
/sec.
)
コア数
PG935 PG940
グラフに違いは無いがスループットに違いがある。
昔からのボトルネックLWLockはどうなった?
31Copyright©2015 NTT corp. All Rights Reserved.
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が足を引っ張っている!
32Copyright©2015 NTT corp. All Rights Reserved.
PostgreSQLのボトルネックは?◆PG95dev内の時間が掛かっていた関数を調査した
s_lock大幅減少
Perf結果 PG95dev
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
LWLockAcquireLWLock
PG940で目⽴っていたs_lockが消えた
33Copyright©2015 NTT corp. All Rights Reserved.
8.78
63.22
0
10
20
30
40
50
60
70
80
90
100
30 コア 60 コア 240 コア
割合
(%) PG940
hash_search_with_hash_value
PinBuffer
slot_deform_tuple
heap_hot_search_buffer
LWLockRelease
LWLockAcquire
s_lock
PostgreSQLのボトルネックは?◆PG940 と PG95devの比較
0
10
20
30
40
50
60
70
80
90
100
30 コア 60 コア 240 コア
割合
(%) PG95dev
hash_search_with_hash_value
PinBuffer
slot_deform_tuple
heap_hot_search_buffer
LWLockRelease
LWLockAcquire
⻑年のボトルネックLWLock(s_lock)が改善された!
LWLock
LWLock
34Copyright©2015 NTT corp. All Rights Reserved.
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.
→共有バッファ取得時のロック削減
35Copyright©2015 NTT corp. All Rights Reserved.
PG95devで s_lock は改善された?◆Increase the number of buffer mapping partitions to 128.
概要共有バッファの管理テーブルの分割数を増やした(NUM_BUFFER_PARTITIONS 9.4まで 16 → 128)
効果ロックの衝突確率の削減(競合低減)・9.4まで
分割数が少ないため、高負荷時に衝突多発。待ちが発⽣しやすい。
・9.5から分割数が増えたため、衝突確率が減少。待ちが軽減。
36Copyright©2015 NTT corp. All Rights Reserved.
◆Increase the number of buffer mapping partitions to 128.
PG95devで s_lock は改善された?
00 11 22 〜〜 1515
ディスクのブロック
共有バッファ上のブロック
16分割
管理テーブル
ロックは16個しか取れなかった00 127
before after
128分割
16 128
ディスクのブロック
共有バッファ上のブロック
並列度向上!競合減少!待ち減少!
37Copyright©2015 NTT corp. All Rights Reserved.
①過去から続くボトルネックLWLockは改善?
②パフォーマンスは向上しているのか?
ここまでを整理すると、
PG95dev s_lock大幅削減に伴い改善した。
スループットはPG935と比較し、PG940 2倍向上 (ピーク:45コア)PG95dev 3倍向上 (ピーク:60コア)
⇒YES
⇒YESgood
38Copyright©2015 NTT corp. All Rights Reserved.
PG95dev 60コア以上を使えなかった理由は?
PostgreSQL・LWLock以外のボトルネック?
OS検証ではRHEL6.5を利用したが、6.6以降や7でメニーコアに効く改善がある模様・・・
HP社のRHEL改善に関する資料(LinuxCon North America 2014)http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-2014-locking-final.pdf
⇒OSのspinlockを改善し性能向上?
39Copyright©2015 NTT corp. All Rights Reserved.
◆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コア
40Copyright©2015 NTT corp. All Rights Reserved.
PostgreSQL• 次なるボトルネック調査• Increase the number of buffer mapping partitions to 128.
128が最適?• プロセスがSleepしている原因
OS• 最適なチューニングパラメータ
DBに最適なパラメータは?RHEL7のプロファイルは?• affinity設定時の性能
プロセス、CPU、メモリを括りつけ、キャッシュヒット率向上
さらにスケールさせるために今後明らかにしたいこと
⇒H/W性能を引き出し、PostgreSQLの適用領域を増やす
41Copyright©2015 NTT corp. All Rights Reserved.
まとめ
大規模なメニーコアのサーバに対しても、PostgreSQLは年々進化しているため、有効活用できる!
過去から言われ続けていたボトルネックLWLockは改善した!
パフォーマンスは向上し続けている!
43Copyright©2015 NTT corp. All Rights Reserved.
NTT OSSセンタは、
これからも PostgreSQL を用いて
付加価値を提供いたします。
みなさんも一緒に使ってみませんか!
コミュニティと共に