[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.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


9.1(2011/9)

9.0(2010/9)

8.4(2009/7)

8.28.1

8.3(2008/2)

【黎明期】小中規模構成をターゲット商用DBMSと同等の機能・性能向上


2012

2006

2013

2005

2014

2008

20112010

2007

2009

OSSｾﾝﾀ設⽴

NTT参画

�PostgreSQLのエンタープライズ適用に向けた進化をOSSセンタの活動状況と合わせてご紹介

�Step2. 信頼性/可用性、移⾏性の向上�Step1. 追いつけ！商用DBMS

【発展期】大規模構成、適用領域拡大に向けた・機能性向上・商用DBMSからの移⾏性向上

•同期/非同期レプリケーション•移⾏ツール（db_syntax_diff）


9.4(2014/12)

9.1(2011/9)

9.0(2010/9)

8.4(2009/7)

8.28.1

8.3(2008/2)

【黎明期】小中規模構成をターゲット商用DBMSと同等の機能・性能向上


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システム適用

・レプリケーション・外部データラッパー


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 SwitchHP 5900AF-48XGT-4QSFP

Clientサーバ（負荷サーバ）HP ProLiant DL360 Gen9





Boot用ストレージHP 3PAR StoreServ 7400

FC SwitchHP SN3000B

DBサーバHP Superdome X

FiberChannel 16Gb10GBASE-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.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


測定結果

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の性能は向上している！


測定結果

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


実⾏計画や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

実⾏計画や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コア時に注目すると、実質的なコア数に違いがある


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

実⾏計画やOSリソースを⾒る(2/3)◆実質的なコアあたりのスループットを計算すると、

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

スル

ープ

ット

(BT

/sec.

)

コア数

PG935 PG940 PG95dev


実⾏計画や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に対応

※

※


実⾏計画や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はどうなった？


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が足を引っ張っている！


PostgreSQLのボトルネックは？◆PG95dev内の時間が掛かっていた関数を調査した

s_lock大幅減少

Perf結果 PG95dev

0

10

20

30

40

50

60

70

80

90

100

30 コア 60 コア 240 コア

割合

(%)


PinBuffer

slot_deform_tuple


LWLockRelease

LWLockAcquireLWLock

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

PostgreSQLのボトルネックは？◆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.

→共有バッファ取得時のロック削減


PG95devで s_lock は改善された？◆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.

PG95devで s_lock は改善された？

00 11 22 〜〜 1515

ディスクのブロック

共有バッファ上のブロック

16分割

管理テーブル

ロックは16個しか取れなかった00 127

before after

128分割

16 128

ディスクのブロック

共有バッファ上のブロック

並列度向上！競合減少！待ち減少！


①過去から続くボトルネックLWLockは改善？

②パフォーマンスは向上しているのか？

ここまでを整理すると、

PG95dev s_lock大幅削減に伴い改善した。

スループットはPG935と比較し、PG940 ２倍向上（ピーク：４５コア）PG95dev ３倍向上（ピーク：６０コア）

⇒YES

⇒YESgood


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を改善し性能向上？


◆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

Technology

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