postgresql 9.5 cpu read scalability

Copyright©2016 NTT corp. All Rights Reserved.

PostgreSQL 9.5 Read Scalability

2016/05/28 PostgreSQL アンカンファレンス

NTT OSSセンタ大山真実

2 Copyright©2016 NTT corp. All Rights Reserved.

Read Scalability とは？

• どれだけ多くの参照SQLを並列処理できるか。

• つまり、複数のクライアントからの参照SQLを、複数のCPUコアでどれだけ並列に処理できるか。

はじめに


「スケールする」「スケーラビリティがある」は

２つの意味で使われることが多い。

• クライアント(ユーザ/プロセス)に対するスケーラビリティ

10クライアントがAサーバに対してSQLを発行した時

100クライアントがAサーバに対してSQLを発行した時

を比較すると、10倍のスループットになってほしい。

->最大スループット時のクライアント数で評価する。

• CPUコアに対するスケーラビリティ

10コアのAサーバに対してSQLを発行した時

100コアのBサーバに対してSQLを発行した時

を比較すると、10倍のスループットになってほしい。

->各CPUコア数の最大スループットで評価する。

はじめに


PostgreSQL の Read Scalability は改善され続けている

• 特に9系から大幅な改善

はじめに

Dilip Kumar: Scalability And Performance Improvements In PostgreSQL 9.6 (PgDay Asia 2016)


•データベースサーバ

環境

サーバ型番 ProLiant DL580 Gen9

core 72core (72/HT144) E7-8890 v3 2.5/3.3 GHz

Memory 2048GB

•クライアント ProLiant DL360 Gen9 ×３

ハードウェア情報

・４ノード NUMAサーバ・１ノードあたり、 - 36core(18/HT36) - 512GB memory

HP社様からお借りしました。ありがとうございました！


環境

測定方針 • PostgreSQL9.4.5/9.5.0

• max_connections=1000

• PostgreSQLコミュニティの測定方法を踏襲 (Read Scalabil ity in PostgreSQL 9.5 http://www.enterprisedb.com/postgres-plus-edb-blog /amit-kapila /read-scalabil ity-postgresql-95)

• pgbenchのSELECTのみ実行(-Sオプション)

• pgbenchのクライアント数(-cオプション)を変化させスループットが最大になった時のクライアント数、スループットを比較する

• pg_prewarm()でストレージのデータをメモリに乗せた後、10~20分予備測定をしてから本測定。

• ハイパースレッドは有効

“SELECT ~”

pgben

ch

pgben

ch

pgben

ch

クライアント数

DBサーバ

クライアントサーバ

postg

res

postg

res

postg

res

サーバプロセス数

クライアント数＝サーバプロセス数

・・・

・・・

http://www.enterprisedb.com/postgres-plus-edb-blog/amit-kapila/read-scalability-postgresql-95
















測定結果

測定１

PostgreSQL9.4/9.5のリードスケーラビリティ比較

0 32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 512 544 576

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

550000

600000

650000

700000

750000

800000

Client

TP

S

pg94_19GB pg94_38GB

pg95_19GB pg95_38GB

・最大スループット時のクライアント数

?

・shared_buffers = 25GB ・DBサイズ 19GB,32GB

①共有バッファに乗るDBサイズで約1.5倍向上 ②共有バッファを超えるDBサイズで約2倍向上

約80万TPS!


測定結果

測定２

“interleave=all”設定の有無によるスループット・shared_buffers = 255GB ・DBサイズ 200GB~1200GBまで変化させる

0 32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 512 544 576

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

550000

600000

650000

700000

750000

800000

200GB 200GB_all 500GB 500GB_all

700GB 700GB_all 1200GB 1200GB_all

・共有バッファに収まる範囲のDBサイズで“interleave=all”設定は有効・次の測定ではこの設定を有効にした状態で測定する

約1.3倍性能向上


測定結果

測定３

PG95における使用core数とスループットの関係

0 18 36 54 72 90 108 126 144 162 180 198 216 234 252 270 288

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

Client

TP

S

9core 18core 27core 36core 48core 54core

63core 72core 90core 108core 126core 144core

・shared_buffers = 255GB ・DBサイズ 500GB ・OS用に0-3番のcoreは動作させる（つまり9coreの場合13個のcoreを使用）

48core以降スループットはあまり上昇せず

36～64clientの間でスループットの謎の落ち込み現象


測定結果

測定３

PG95における使用core数とスループットの関係赤：各core数における最大スループット青：１coreあたりのスループット

0

2000

4000

6000

8000

10000

12000

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

0 18 36 54 72 90 108 126 144 １coreあたりの

TP

S (最大

TP

S/core

)

最大

TP

S

使用core数

最大TPS

最大TPS / core

・36core(OS用コア含め40core)まで効率的にCPUコアを使用可


• Read only ではあるものの、80万TPSまで出ることを確認

• PostgreSQL9.5は9.4と比較して、クライアント数が、共有バッファに乗るDBサイズで1.5倍、共有バッファを超えるDBサイズで2倍までスケールすることを確認

• PostgreSQL9.5は40コア程度までスケールすることを確認。CPUを40コア程度まで効率よく使える。

ここまでのまとめ


USLによる解析

The Universal Scalability Law (USL) とは？

•コンピューターシステムのスケーラビリティをモデル化、定量化

•特定のシステムに依らず適応可能

•ハードウェア、ソフトウェアに関わらずスケーラビリティを評価可能

詳しくはこちらを見て下さい。 [Gun08] Neil J. Gunther. A general theory of computational scalability based on rationalfunctions.

CoRR, abs/0808.1431, 2008. http://arxiv.org/pdf/0808.1431v2.pdf


USLによる解析

• Universal Scalability Law

• Relative Capacity

X(N)：NクライアントまたはN個のCPUコア時のスループット X(1)：１クライアントまたは１CPUコア時のスループット T：処理時間 n：処理するタスクの数 S(N)：Speedup

C N( ) =N

1+s N -1( ) +kN N -1( )

C N( ) =X(N )

X(1)=n

TN

T1

n=T1

TN= S N( )


USLによる解析

• クエリの実行実行時間とσ,κパラメータの関係

上記の式をごにょごにょすると

C N( ) =N

1+s N -1( ) +kN N -1( )

C N( ) =T1

TN=

T1

sT1 + 1-s( )T1

N+kN N -1( )

T1

N

TN =sT1 + 1-s( )T1

N+kN N -1( )

T1

N

よって、クライアントからのクエリをN並列で処理した場合の処理時間は、


USLによる解析

• σ, κ ＝０のとき、タスクをN並列で実行した時の実行時間は1/Nに短縮される

TN =T1

N（理想的な並列処理）

σ, κ ＝０のときのTPS例


USLによる解析

σ ≧ 0, κ ＝0 のときのTPS例

TN =sT1 + 1-s( )T1

N

• σ > 0, κ ＝ 0 のときは、Amdahl‘s law。

並列可能並列不可能

0 £s £1

σ = 0.01


USLによる解析

？？？

• σ > 0, κ > 0 のときは、、、

TN =sT1 + 1-s( )T1

N+kN N -1( )

T1

N

σ ≧ 0, κ ≧ 0 のときのTPS例

σ = 0.01 κ = 0.00005


USLによる解析

USLが仮定していること

• Synchronous Queueing • 全てのクエリが同時に実行されると仮定。 • 1クエリは処理されるが、N-1クエリは待機している状態。

または、1CPUコアは処理しているが、N-1CPUコアは待機している状態 • 当然ながら、実際のシステムでは、最初のNクエリが同時に来たとしても

、それ以降のクエリが同時に来ることはない。よって、実際のスループットはUSLが想定している値より大きくなる。

• State-Dependent Service • M/G/1//Nにおいて Residence Time がシステムの状態に依存すると仮定 • より物理的な描像では、「CPUコア間での coherency を保つ」など

NC2 =N N -1( )

2

TN =sT1 + 1-s( )T1

N+kN N -1( )

T1

N

->CPUコアの組合せに比例して処理時間が増加する


USLによる解析

USL と σ, κ の意味

C N( ) =N

1+s N -1( ) +kN N -1( )

A. Ideal concurrency σ, κ ＝０ A. Contention-limited σ > 0, κ ＝ 0

B. Coherency-limited σ = 0, κ > 0

C. Worst case σ > 0, κ > 0

σ ≧ 0, κ ≧ 0 のときのTPS例


USLによる解析

• USLによる解析結果

PG95 19GB PG95 38GB

PG94 19GB PG94 38GB

Coefficients: Estimate Std. Error sigma 1.080e-03 1.415e-03 kappa 3.459e-05 6.092e-06





USLによる解析

PostgreSQL 9.5 と 9.4 における、σ, κ の比較

共有メモリに乗るDBサイズ、共有メモリに乗らないDBサイズ共に、競合によるスループットの低減が大きく減少しているかも？ -> LWLockの改善

共有メモリに乗らないDBサイズで、コヒーレンシによるスループットの低減が多少減少しているかも？共有メモリに乗るDBサイズでは改善があまりみられない

0.E+00

1.E-02

2.E-02

3.E-02

4.E-02

pg95_19GB pg94_19GB pg95_38GB pg94_38GB

σ：Contention Effect

0.E+00

1.E-05

2.E-05

3.E-05

4.E-05

pg95_19GB pg94_19GB pg95_38GB pg94_38GB

κ：Coherency Effect


PostgreSQL 9.6

「PostgreSQL Scalability: Towards Millions TPS」 http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-tps/ !!!

postgresql 9.5 cpu read scalability

Technology