search

gcpug / nouhau

Google Cloud Platformのノウハウを共有するRepository
https://gcpug.jp
MIT License
653 stars 23 forks source link

WRITEの負荷が高い状態で、フルスキャンするクエリを投げた時のmonitoringを追加 #68

Closed sinmetal closed 5 years ago

apstndb commented 5 years ago

これの query って全部 strong read ですよね。 staleness は別の検証する感じです？

sinmetal commented 5 years ago

たまたま、クエリ投げただけだから、特に何も考えてなかったね。

sinmetal commented 5 years ago

gcloud spanner では staleness queryは投げられないか・・・？ ちょっと適当にコード書いて試してみようか。

apstndb commented 5 years ago

なるほど Go の中から叩いているのかと思ったけど gcloud とか Web UI からじゃ無理ですね。面倒。

sinmetal commented 5 years ago

WRITEはGoから投げてたんだけど、これは今Table何件あるんだろう？と思って、Consoleからぽいっとクエリをなんとなく投げたって時のもの。

sinmetal commented 5 years ago

適当にクエリを投げるもの作ってみた https://github.com/sinmetal/screwdriver

sinmetal commented 5 years ago

ExactStalenessQueryで15secを指定してみたけど、strongと同じように、がくっとWRITEの性能が下がってるね。

image

apstndb commented 5 years ago

なるほど、 read-only tx がそれぞれのスプリットでどのレプリカ使ったかでも違う結果になりそうですね。仮説としては全部リーダーを避けた場合が最適だろうけど、マルチリージョンじゃないと狙えないし外部からは観測できないか。

sinmetal commented 5 years ago

マルチリージョンにしないとRead Only Replicaが登場しないから、Writeに影響を与えないようにReadのクエリを投げるのは難しそうだねー。 https://cloud.google.com/spanner/docs/replication?hl=en#read-only

apstndb commented 5 years ago

ゾーン障害時以外は全部のレプリカでクォーラム取ろうとするから、リーダーが少し仕事が多いとはいえリーダー以外の負荷もレイテンシに影響するとかそんなかんじですかね

sinmetal commented 5 years ago

nam3, nam-eur-asia1 でも同じようなことしてみれば、何か面白い結果になったりするかな？

https://cloud.google.com/spanner/docs/instances#multi-region_configurations

apstndb commented 5 years ago

少なくともマルチリージョンの方だと staleness を使うのはベストプラクティスに沿っているからだいぶ性能影響があるでしょうね。

https://cloud.google.com/spanner/docs/instances?hl=ja#multi-region-best-practices

デフォルトのリーダー リージョン外で最適な読み取りパフォーマンスを得るには、15 秒以上のステイルネスを使用します。

何が起こるのかというと、 https://cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes?hl=ja#strong_read_multi-node

API レイヤが、スプリット 0、スプリット 1、スプリット 2 の一部のレプリカに読み取りリクエストを送信します。また、前のステップで選択した読み取りタイムスタンプも含まれます。この時点で、次の 3 つ状態が考えられます。

の中の

a. 多くの場合、それぞれのレプリカは読み取り可能な状態であることを自身の内部状態と TrueTime から認識し、処理を実行します。

となって

b. レプリカが最新のデータかどうかわからない場合もあります。この場合、リーダーに RPC を実行し、読み取り実行に必要な最新トランザクションのタイムスタンプを取得します。トランザクションが適用されると、読み取りが実行されます。

の必要がなくなり、通信やトランザクションの適用待ちがなくなるという理解ですかね。

現時点の理解でとりあえず予想