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

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

Embed Size (px)

Citation preview

Copyright©2015 NTT corp. All Rights Reserved.

最新PostgreSQLはパフォーマンスが飛躍的に向上する!?- PostgreSQLのCPUスケーラビリティについて -

2015年6月10日NTT OSSセンタ

山田 達朗

2Copyright©2015 NTT corp. All Rights Reserved.

1.はじめに2.検証概要3.検証結果4.おわりに

アジェンダ

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は改善した!

パフォーマンスは向上し続けている!

42Copyright©2015 NTT corp. All Rights Reserved.

1.はじめに2.検証概要3.検証結果4.おわりに

43Copyright©2015 NTT corp. All Rights Reserved.

NTT OSSセンタは、

これからも PostgreSQL を用いて

付加価値を提供いたします。

みなさんも一緒に使ってみませんか!

コミュニティと共に

44Copyright©2015 NTT corp. All Rights Reserved.

ご清聴ありがとうございました。

"elephants beach walk" by Senorhorst Jahnsen is licensed under CC BY 2.0