狠狠撸

狠狠撸Share a Scribd company logo

PostgreSQL 9.5 CPU Read Scalability

?
?
Ohyama Masanori
Ohyama Masanori

2016/05 第7回 PostgreSQLアンカンファレンス＠東京

1 of 22
Downloaded 17 times
Copyright?2016 NTT corp. All Rights Reserved. PostgreSQL 9.5 Read Scalability 2016/05/28 PostgreSQL アンカンファレンス NTT OSSセンタ 大山真実
2Copyright?2016 NTT corp. All Rights Reserved. Read Scalability とは？ ? どれだけ多くの参照SQLを並列処理できるか。 ? つまり、複数のクライアントからの参照SQLを、複数のCPUコ アでどれだけ並列に処理できるか。 はじめに
3Copyright?2016 NTT corp. All Rights Reserved. 「スケールする」「スケーラビリティがある」は ２つの意味で使われることが多い。 ? クライアント(ユーザ/プロセス)に対するスケーラビリティ ?10クライアントがAサーバに対してSQLを発行した時 ?100クライアントがAサーバに対してSQLを発行した時 を比較すると、10倍のスループットになってほしい。 ->最大スループット時のクライアント数で評価する。 ? CPUコアに対するスケーラビリティ ?10コアのAサーバに対してSQLを発行した時 ?100コアのBサーバに対してSQLを発行した時 を比較すると、10倍のスループットになってほしい。 ->各CPUコア数の最大スループットで評価する。 はじめに
4Copyright?2016 NTT corp. All Rights Reserved. PostgreSQL の Read Scalability は改善され続けている ? 特に9系から大幅な改善 はじめに Dilip Kumar: Scalability And Performance Improvements In PostgreSQL 9.6 (PgDay Asia 2016)
5Copyright?2016 NTT corp. All Rights Reserved. ? データベースサーバ 環境 サーバ型番 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社様からお借りしました。 ありがとうございました！
6Copyright?2016 NTT corp. All Rights Reserved. 環境 測定方針 ? PostgreSQL9.4.5/9.5.0 ? max_connections=1000 ? PostgreSQLコミュニティの測定方法を踏襲 (Read Scalability in PostgreSQL 9.5 http://www.enterprisedb.com /postgres-plus-edb-blog /amit- kapila/read-scalability-postgresql-95) ? pgbenchのSELECTのみ実行(-Sオプション) ? pgbenchのクライアント数(-cオプション)を 変化させスループットが最大になった時のク ライアント数、スループットを比較する ? pg_prewarm()でストレージのデータをメ モリに乗せた後、10~20分予備測定をして から本測定。 ? ハイパースレッドは有効 “SELECT ~” pgbench pgbench pgbench クライアント数 DBサーバ クライアント サーバ postgres postgres postgres サーバプロセス数 クライアント数 ＝サーバプロセス数 ??? ???
7Copyright?2016 NTT corp. All Rights Reserved. 測定結果 測定１ 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 TPS pg94_19GB pg94_38GB pg95_19GB pg95_38GB ?最大スループット時のクライアント数 ? ?shared_buffers = 25GB ?DBサイズ 19GB,32GB ①共有バッファに乗るDBサイズで約1.5倍向上 ②共有バッファを超えるDBサイズで約2倍向上 約80万TPS!
8Copyright?2016 NTT corp. All Rights Reserved. 測定結果 測定２ “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倍 性能向上
9Copyright?2016 NTT corp. All Rights Reserved. 測定結果 測定３ 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 TPS 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の 間でスループット の謎の落ち込み現 象
10Copyright?2016 NTT corp. All Rights Reserved. 測定結果 測定３ 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あたりのTPS(最大TPS/core) 最大TPS 使用core数 最大TPS 最大TPS / core ?36core(OS用コア含め40core)まで効率的にCPUコアを使用可
11Copyright?2016 NTT corp. All Rights Reserved. ? Read only ではあるものの、80万TPSまで出ること を確認 ? PostgreSQL9.5は9.4と比較して、クライアント数が 、共有バッファに乗るDBサイズで1.5倍、共有バッフ ァを超えるDBサイズで2倍までスケールすることを確 認 ? PostgreSQL9.5は40コア程度までスケールすること を確認。CPUを40コア程度まで効率よく使える。 ここまでのまとめ
12Copyright?2016 NTT corp. All Rights Reserved. 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
13Copyright?2016 NTT corp. All Rights Reserved. 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( )
14Copyright?2016 NTT corp. All Rights Reserved. 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並列で処理した場合の処理時間は、
15Copyright?2016 NTT corp. All Rights Reserved. USLによる解析 ? σ, κ ＝０のとき、タスクをN並列で実行した時の実行時間は1/Nに短縮される TN = T1 N （理想的な並列処理） σ, κ ＝０のときのTPS例
16Copyright?2016 NTT corp. All Rights Reserved. USLによる解析 σ ≧ 0, κ ＝0 のときのTPS例 TN =sT1 + 1-s( ) T1 N ? σ > 0, κ ＝ 0 のときは、Amdahl‘s law。 並列可能並列不可能 0 ?s ?1 σ = 0.01
17Copyright?2016 NTT corp. All Rights Reserved. USLによる解析 ？？？ ? σ > 0, κ > 0 のときは、、、 TN =sT1 + 1-s( ) T1 N +kN N -1( ) T1 N σ ≧ 0, κ ≧ 0 のときのTPS例 σ = 0.01 κ = 0.00005
18Copyright?2016 NTT corp. All Rights Reserved. USLによる解析 USLが仮定していること ? Synchronous Queueing ? 全てのクエリが同時に実行されると仮定。 ? 1クエリは処理されるが、N-1クエリは待機している状態。 または、1CPUコアは処理しているが、N-1CPUコアは待機している状態 ? 当然ながら、実際のシステムでは、最初のNクエリが同時に来たとしても 、それ以降のクエリが同時に来ることはない。よって、実際のスループッ トはUSLが想定している値より大きくなる。 ? State-Dependent Service ? M/G/1//Nにおいて Residence Time がシステムの状態に依存すると仮定 ? より物理的な描像では、「CPUコア間での coherency を保つ」など N C2 = N N -1( ) 2 TN =sT1 + 1-s( ) T1 N +kN N -1( ) T1 N ->CPUコアの組合せに比例して処理時間が増加する
19Copyright?2016 NTT corp. All Rights Reserved. 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例
20Copyright?2016 NTT corp. All Rights Reserved. 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 Coefficients: Estimate Std. Error sigma 1.627e-02 3.944e-03 kappa 3.665e-05 1.560e-05 Coefficients: Estimate Std. Error sigma 2.943e-02 4.477e-03 kappa 2.054e-05 1.541e-05 Coefficients: Estimate Std. Error sigma 9.455e-03 6.591e-04 kappa 1.432e-05 2.157e-06
21Copyright?2016 NTT corp. All Rights Reserved. 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
22Copyright?2016 NTT corp. All Rights Reserved. PostgreSQL 9.6 「PostgreSQL Scalability: Towards Millions TPS」 http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-tps/!!!

More Related Content

PostgreSQL 9.5 CPU Read Scalability

  • 1. Copyright?2016 NTT corp. All Rights Reserved. PostgreSQL 9.5 Read Scalability 2016/05/28 PostgreSQL アンカンファレンス NTT OSSセンタ 大山真実
  • 2. 2Copyright?2016 NTT corp. All Rights Reserved. Read Scalability とは？ ? どれだけ多くの参照SQLを並列処理できるか。 ? つまり、複数のクライアントからの参照SQLを、複数のCPUコ アでどれだけ並列に処理できるか。 はじめに
  • 3. 3Copyright?2016 NTT corp. All Rights Reserved. 「スケールする」「スケーラビリティがある」は ２つの意味で使われることが多い。 ? クライアント(ユーザ/プロセス)に対するスケーラビリティ ?10クライアントがAサーバに対してSQLを発行した時 ?100クライアントがAサーバに対してSQLを発行した時 を比較すると、10倍のスループットになってほしい。 ->最大スループット時のクライアント数で評価する。 ? CPUコアに対するスケーラビリティ ?10コアのAサーバに対してSQLを発行した時 ?100コアのBサーバに対してSQLを発行した時 を比較すると、10倍のスループットになってほしい。 ->各CPUコア数の最大スループットで評価する。 はじめに
  • 4. 4Copyright?2016 NTT corp. All Rights Reserved. PostgreSQL の Read Scalability は改善され続けている ? 特に9系から大幅な改善 はじめに Dilip Kumar: Scalability And Performance Improvements In PostgreSQL 9.6 (PgDay Asia 2016)
  • 5. 5Copyright?2016 NTT corp. All Rights Reserved. ? データベースサーバ 環境 サーバ型番 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社様からお借りしました。 ありがとうございました！
  • 6. 6Copyright?2016 NTT corp. All Rights Reserved. 環境 測定方針 ? PostgreSQL9.4.5/9.5.0 ? max_connections=1000 ? PostgreSQLコミュニティの測定方法を踏襲 (Read Scalability in PostgreSQL 9.5 http://www.enterprisedb.com /postgres-plus-edb-blog /amit- kapila/read-scalability-postgresql-95) ? pgbenchのSELECTのみ実行(-Sオプション) ? pgbenchのクライアント数(-cオプション)を 変化させスループットが最大になった時のク ライアント数、スループットを比較する ? pg_prewarm()でストレージのデータをメ モリに乗せた後、10~20分予備測定をして から本測定。 ? ハイパースレッドは有効 “SELECT ~” pgbench pgbench pgbench クライアント数 DBサーバ クライアント サーバ postgres postgres postgres サーバプロセス数 クライアント数 ＝サーバプロセス数 ??? ???
  • 7. 7Copyright?2016 NTT corp. All Rights Reserved. 測定結果 測定１ 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 TPS pg94_19GB pg94_38GB pg95_19GB pg95_38GB ?最大スループット時のクライアント数 ? ?shared_buffers = 25GB ?DBサイズ 19GB,32GB ①共有バッファに乗るDBサイズで約1.5倍向上 ②共有バッファを超えるDBサイズで約2倍向上 約80万TPS!
  • 8. 8Copyright?2016 NTT corp. All Rights Reserved. 測定結果 測定２ “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倍 性能向上
  • 9. 9Copyright?2016 NTT corp. All Rights Reserved. 測定結果 測定３ 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 TPS 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の 間でスループット の謎の落ち込み現 象
  • 10. 10Copyright?2016 NTT corp. All Rights Reserved. 測定結果 測定３ 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あたりのTPS(最大TPS/core) 最大TPS 使用core数 最大TPS 最大TPS / core ?36core(OS用コア含め40core)まで効率的にCPUコアを使用可
  • 11. 11Copyright?2016 NTT corp. All Rights Reserved. ? Read only ではあるものの、80万TPSまで出ること を確認 ? PostgreSQL9.5は9.4と比較して、クライアント数が 、共有バッファに乗るDBサイズで1.5倍、共有バッフ ァを超えるDBサイズで2倍までスケールすることを確 認 ? PostgreSQL9.5は40コア程度までスケールすること を確認。CPUを40コア程度まで効率よく使える。 ここまでのまとめ
  • 12. 12Copyright?2016 NTT corp. All Rights Reserved. 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
  • 13. 13Copyright?2016 NTT corp. All Rights Reserved. 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( )
  • 14. 14Copyright?2016 NTT corp. All Rights Reserved. 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並列で処理した場合の処理時間は、
  • 15. 15Copyright?2016 NTT corp. All Rights Reserved. USLによる解析 ? σ, κ ＝０のとき、タスクをN並列で実行した時の実行時間は1/Nに短縮される TN = T1 N （理想的な並列処理） σ, κ ＝０のときのTPS例
  • 16. 16Copyright?2016 NTT corp. All Rights Reserved. USLによる解析 σ ≧ 0, κ ＝0 のときのTPS例 TN =sT1 + 1-s( ) T1 N ? σ > 0, κ ＝ 0 のときは、Amdahl‘s law。 並列可能並列不可能 0 ?s ?1 σ = 0.01
  • 17. 17Copyright?2016 NTT corp. All Rights Reserved. USLによる解析 ？？？ ? σ > 0, κ > 0 のときは、、、 TN =sT1 + 1-s( ) T1 N +kN N -1( ) T1 N σ ≧ 0, κ ≧ 0 のときのTPS例 σ = 0.01 κ = 0.00005
  • 18. 18Copyright?2016 NTT corp. All Rights Reserved. USLによる解析 USLが仮定していること ? Synchronous Queueing ? 全てのクエリが同時に実行されると仮定。 ? 1クエリは処理されるが、N-1クエリは待機している状態。 または、1CPUコアは処理しているが、N-1CPUコアは待機している状態 ? 当然ながら、実際のシステムでは、最初のNクエリが同時に来たとしても 、それ以降のクエリが同時に来ることはない。よって、実際のスループッ トはUSLが想定している値より大きくなる。 ? State-Dependent Service ? M/G/1//Nにおいて Residence Time がシステムの状態に依存すると仮定 ? より物理的な描像では、「CPUコア間での coherency を保つ」など N C2 = N N -1( ) 2 TN =sT1 + 1-s( ) T1 N +kN N -1( ) T1 N ->CPUコアの組合せに比例して処理時間が増加する
  • 19. 19Copyright?2016 NTT corp. All Rights Reserved. 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例
  • 20. 20Copyright?2016 NTT corp. All Rights Reserved. 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 Coefficients: Estimate Std. Error sigma 1.627e-02 3.944e-03 kappa 3.665e-05 1.560e-05 Coefficients: Estimate Std. Error sigma 2.943e-02 4.477e-03 kappa 2.054e-05 1.541e-05 Coefficients: Estimate Std. Error sigma 9.455e-03 6.591e-04 kappa 1.432e-05 2.157e-06
  • 21. 21Copyright?2016 NTT corp. All Rights Reserved. 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
  • 22. 22Copyright?2016 NTT corp. All Rights Reserved. PostgreSQL 9.6 「PostgreSQL Scalability: Towards Millions TPS」 http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-tps/!!!