Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1

NW遅延環境(Paas)での
チューニングTips
河原 翔

※Linux環境に基づいた内容です
PostgreSQLアンカンファレンス@東京 (7/13)
2

NW遅延とは?
ネットワーク遅延とは、データを送信してから通信相手に届くまで
の時間と、その応答を通信相手が送信してから送信元に届くまでの合
計時間を指す。
つまりデータを入れたパケットが伝送経路を通過するのにかかる時
間(伝搬遅延)と、...
3

実際にどれくらいの影響があるのか?
• 無料で利用できる「Heroku Postgres」を利用
▫ 「Heroku Postgres」の詳細は割愛
4

実際にどれくらいの影響があるのか?
• 約170msのNW遅延がある状態で、接続→SQL発行→切断の
時間を測定する

NW遅延

約170ms

さくらのVPS
大阪リージョン

$ psql "dbname=xxx-1.amazona...
5

実際にどれくらいの影響があるのか?
• クライアントがサーバ にTCPSYNパケットを送出してから
クライアントがサーバからRSTACKパケットを受信するまでの
時間は約1400msとなった

SSLセッション確立のための
時間が大半を占...
6

実際にどれくらいの影響があるのか?
• クエリ発行前の各種コネクション確立のための時間が大半を
占めるため、初回確立後であれば、(ACK待ちが発生しなければ)
NW遅延1回分の影響のみで済む
$ psql "dbname=xxx-1.am...
7

【対応策】
• コネクションプーリングを利用する
▫ 初回接続時の各種コネクション確立のコストを
抑えるため
 プロセス生成と終了のコストを抑えるためではない
 各種コネクション確立後であれば、ACK待ちが発生しなければ
NW遅延1回...
8

【対応策】
• クエリの発行回数を抑える
▫ ストアドプロシージャを利用する
 とあるOSSのブログシステムでは、画面遷移の度にクエリが
20回以上発行されることも…

▫ 一度のクエリで送受信するデータ量を増やす
 一度のINSER...
9

ACK待ちとは?
TCPでは、ACKの応答確認により信頼確保されているが、パケットを送
信する度にACKを送信していてはさすがに通信速度が遅くなってしまい
ます。そこでTCPヘッダにあるウィンドウサイズを利用することにより
この問題を解決...
10

ACK待ちを考慮する必要は?
• 1クエリでのデータ送信量が数十KB以上あるような
ケースでなければACK待ちが発生する可能性は低い
▫ 新しめのLinux Kernelは初期ウィンドウサイズが
10と大きめに設定されているため、ACK...
11

【要点】
• コネクションプーリングを利用する
▫ 初回接続時の各種コネクション確立のコストを抑える
 プロセス生成と終了のコストを抑えるためではない

• クエリの発行回数を抑える
▫ ストアドプロシージャを利用する
▫ 一度のクエ...
Upcoming SlideShare
Loading in …5
×

NW遅延環境(Paas)でのPostgreSQLの利用について

1,378 views

Published on

  • Be the first to comment

NW遅延環境(Paas)でのPostgreSQLの利用について

  1. 1. 1 NW遅延環境(Paas)での チューニングTips 河原 翔 ※Linux環境に基づいた内容です PostgreSQLアンカンファレンス@東京 (7/13)
  2. 2. 2 NW遅延とは? ネットワーク遅延とは、データを送信してから通信相手に届くまで の時間と、その応答を通信相手が送信してから送信元に届くまでの合 計時間を指す。 つまりデータを入れたパケットが伝送経路を通過するのにかかる時 間(伝搬遅延)と、経路上のルーターなどの機器が処理する時間(処 理遅延)などを足し合わせたものだ。 LAN内であれば、ネットワーク遅延は1ミリ~3ミリ秒程度。しかし社 外にある国内のデータセンターとのやり取りでは十数ミリ秒、海外の データセンターでは100ミリ秒を超えることもある。 ITproより引用 http://itpro.nikkeibp.co.jp/article/COLUMN/20121005/428005/ • 国外の会社が運営しているPaasのデータセンタは海外に あることが多いため、NW遅延の影響を受ける可能性が高い (Amazon等の大手は日本国内にもデータセンタがある)
  3. 3. 3 実際にどれくらいの影響があるのか? • 無料で利用できる「Heroku Postgres」を利用 ▫ 「Heroku Postgres」の詳細は割愛
  4. 4. 4 実際にどれくらいの影響があるのか? • 約170msのNW遅延がある状態で、接続→SQL発行→切断の 時間を測定する NW遅延 約170ms さくらのVPS 大阪リージョン $ psql "dbname=xxx-1.amazonaws.com / user=yyy password=zzz port=5432 / sslmode=require" / -c 'select * from test' > /dev/null Heroku Postgres => table test; val ----x (1 row)
  5. 5. 5 実際にどれくらいの影響があるのか? • クライアントがサーバ にTCPSYNパケットを送出してから クライアントがサーバからRSTACKパケットを受信するまでの 時間は約1400msとなった SSLセッション確立のための 時間が大半を占める
  6. 6. 6 実際にどれくらいの影響があるのか? • クエリ発行前の各種コネクション確立のための時間が大半を 占めるため、初回確立後であれば、(ACK待ちが発生しなければ) NW遅延1回分の影響のみで済む $ psql "dbname=xxx-1.amazonaws.com user=yyy password=zzz port=5432 sslmode=require" => explain analyze table test; QUERY PLAN --------------------------------------------------------------------------Seq Scan on test (cost=0.00..1.00 rows=1 width=32) (actual time=0.021..0.022 rows=1 loops=1) Total runtime: 0.103 ms (2 rows) => ¥timing Timing is on. => table test; val -------x (1 row) Time: 183.563 ms => explainではデータ転送時間は含まれない模様 ※auto_explainの対象にならない ¥timingではデータ転送時間も含まれる模様
  7. 7. 7 【対応策】 • コネクションプーリングを利用する ▫ 初回接続時の各種コネクション確立のコストを 抑えるため  プロセス生成と終了のコストを抑えるためではない  各種コネクション確立後であれば、ACK待ちが発生しなければ NW遅延1回分の影響のみで済む ▫ pgpoolはVer2.3.2からSSLをサポート ▫ PgBounserはSSLは不可?
  8. 8. 8 【対応策】 • クエリの発行回数を抑える ▫ ストアドプロシージャを利用する  とあるOSSのブログシステムでは、画面遷移の度にクエリが 20回以上発行されることも… ▫ 一度のクエリで送受信するデータ量を増やす  一度のINSERT文で複数レコード挿入可能なことを知らない エンジニアも結構いるかと…  ただし、ACK待ちは発生させないように考慮すること
  9. 9. 9 ACK待ちとは? TCPでは、ACKの応答確認により信頼確保されているが、パケットを送 信する度にACKを送信していてはさすがに通信速度が遅くなってしまい ます。そこでTCPヘッダにあるウィンドウサイズを利用することにより この問題を解決しています。ウィンドウサイズとは、ACKを待たずに一 度に送信できるデータ量のことです。 例えば、3900バイトのデータを3回に分けて送信する場合、1300バイ トのデータを送るたびにACKを待っていると通信速度は遅いですが、 ウィンドウサイズが「3900」であることを相手側のホストに伝えた場合、 送信側はACKを待つことなく3900バイトのデータを送信することができ ます。これにより通信速度が速まる。 ※ ちなみに、Windows XPの受信ウィンドウサイズはデフォルトで 「65535」バイトとなります。ウィンドウサイズはOSにより異なります。 しかし、これではウィンドウサイズ分のデータを送信した後、ACKを 受信するまでの間、待ち時間が発生する。 「ネットワークエンジニアとして」より引用 http://www.infraexpert.com/study/tcpip11.html
  10. 10. 10 ACK待ちを考慮する必要は? • 1クエリでのデータ送信量が数十KB以上あるような ケースでなければACK待ちが発生する可能性は低い ▫ 新しめのLinux Kernelは初期ウィンドウサイズが 10と大きめに設定されているため、ACK待ちは発生し 難くなっている ▫ デフォルトでsslcompressionはONであるため、 SSL接続でのデータ転送は自動的に圧縮される  ACK待ちが発生するかを事前に計算して 正確に推測することは困難 ▫ TCPのチューニングが可能であることは意識すべき  tcp_slow_start_after_idleはoffにするとか…
  11. 11. 11 【要点】 • コネクションプーリングを利用する ▫ 初回接続時の各種コネクション確立のコストを抑える  プロセス生成と終了のコストを抑えるためではない • クエリの発行回数を抑える ▫ ストアドプロシージャを利用する ▫ 一度のクエリで送受信するデータ量を増やす • ACK待ちの影響を最小限にする ▫ 1クエリでのデータ送信量を、ACKを受信せずに 一度に送信できるデータ量以下に収めるようにする ▫ TCP初期ウィンドウサイズの大きいKernelを採用する

×