#garagekidztweetz

読者です 読者をやめる 読者になる 読者になる

#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

チューニング話が盛りだくさんの MySQL Cluster Casual Talks #2 にいってきた! #mysql_jp

スポンサーリンク

f:id:garage-kid:20140625234250p:plain

前回 の第一回目がとてもためになったので、二回目も参加してきました。

まず、アジェンダは以下のような感じでした。

アジェンダ

  • 19:00 - 19:05 会場に関する注意とステマ by 運営
  • 19:05 - 19:15 じゃんけん大会でノベルティー配るらしい) by @MikumoConoHa
  • 19:15 - 19:45 運用8カ月の四方山話的な予定 by いとうさん
  • 19:50 - 20:20 Mac Miniで作るMySQL Cluster MCCTバージョン by 室田さん
  • 20:25 - 20:55 【検証結果発表】MySQL Clusterでもフラッシュドライブを活用してみる by 日本ヒューレット・パッカード株式会社 テクノロジーコンサルティング事業統括 高橋 智雄さん
  • 21:00 - 21:30 実際に使っている人に聞く怒涛のQAタイム by 登壇者のみなさん featuring @nippondanji さん

今回、個人的に一番高まるゥゥだったのは @MikumoConoHa ちゃんに写真とらせてもらったことですが(っておい、、、)、ちゃんとメモはとってきたので、今日もメモを公開しておこうと思います。
※ブログ書くまでが勉強会ですからね( ー`дー´)キリッ
MySQL Cluster Casual Talks #2 にConoHaがきたはなしの裏側 - mysql | GMOメディア エンジニアブログがUpされていたのでこちらにもリンクを貼らせていただきました。 -2014-06-30 9:50

さらにちなみに、今回は実際に MySQL Cluster を Production で使って 10 ヶ月の四方山的な話をはじめ、チューニング系の話が聞けたタメになる会でしたよ。
※あとで自分のためにトゥギャったりしようかな、と。 -> というわけで トゥギャりました - 2014-06-26 0:37

では以降からがわたしのメモです。

19:00 - 19:05 会場に関する注意とステマ by 運営

  • 今回の提供は GMO メディア株式会社
    • 多謝!!!
  • ハッシュタグ:#mysql_jp
  • QA タイム公開質問状 github

19:05 - 19:15 じゃんけん大会でノベルティー配るらしい) by @MikumoConoHa

  • しょっぱなで負けた orz

19:15 - 19:45 運用8カ月の四方山話的な予定 by いとうさん

  • MySQL Cluster をつかいはじめて 10 ヶ月間

MySQL CLuster きっかけ

  • お客様がもともとつかっていた
    • VPS で ndbd のほうを使っていた
    • ndbmtd が動かなかった
    • 性能もあまりでていなかった
    • 物理サーバを使いたいらしい

構成

  • LVS
  • Web, SQL, Admin node (2)
  • Data node (3 or 4)
  • この構成だと Oracle のサポートは受けれない

パラメタ検討

  • HW に適したパラメータは? Innodb みたいなお約束のパラメータはあるのか?
  • 奥野さんの本を読んだりした
    • 若干情報が古くなっている
    • マニュアルを読んだほうがいい
  • Data node
    • MaxNoofExecutionThreads
      • ndbmtd のみのパラメタ
      • 主要な動作スレッドの同左スレッド数
      • 7.3 系では max 36, 物理 CPU 数と合わせる
    • ThreadConfig
      • より詳細な動作スレッドを設定可能
      • 各スレッドがどの CPU コアで動作するか固定される
      • スピーカーは利用してない (設定しなくても問題なく動いてるから)
      • ndbmtd に任せている
    • Numa
      • NUMA 環境なら Swap Insanity 対策のためにも
    • ODirect (default 0)
      • innodb_flush_method と同様
    • TransactionDeadlockDetectionTimeout (default 1200)
      • tc がクエリ実行を待てる時間
      • 大きすぎると deadlock 待ちが滞留する
    • MaxNoOfConcurrentScans (max 500)
      • スキャンクエリの最大並列実行数
      • DN 単位で持つ
      • 瞬間的に大量アクセスがくると Too many access scans
    • MaxNoOfConcurrentTransactions (default 4096)
      • DN 単位
      • マニュアルに計算式が載っている
    • NoOfFragmentLogFiles (default 16)
    • FragmentLogFileSize (default 16MB)
  • SQL Node
    • あまり設定するものがない
    • ndb-cluster-connection-pool
      • 増やすと接続数が増えるので付加状況次第で性能向上
    • query_cache_type, query_cache_size
      • MySQL Cluster 環境では無効にする

サービスインから発生した障害と対応

  • 障害1
    • SQL Node
      • Too many active scans
      • そもそも受け切れないなら Apache の Maxclient さげる
  • 障害2
    • DN
      • out of long signal memory....
      • LongMessageBuffer を増やす
  • 障害3
    • ndbd 3 x 2 を ndbmtd 3 x 1 にするときに発生
    • mysqldump してリストア
      • しかし失敗
      • Redolog 大きく (NoOfFragmentLogFiles)
    • TimeBetweenLocalCheckpoints を 6 以下に
      • ndbmtd 再起動が必要でメンテ時間は延長した
  • 障害4
    • daily crontab で ndbmtd が落ちる
    • Forced node shutdown ....
    • IO 負荷の高いであろう cron (updatedb 実行)を停止
      • スワップとの兼ね合いで TimeBetweenWatchDogCheck に引っかかって停止したと考えられたため
      • vm.swappiness=0 にした (CentOS 5 系)

監視について

  • DN
    • CPU コアごとの使用率を監視したほうがいい
      • LA 監視や CPU 使用率はあまり役にたたない
      • ldm スレッドが一番 CPU 使う
    • NW Traffic
      • DN の特徴として負荷がない状態でも NW Traffic が発生している
      • 100Kbps は発生する
      • 10Mbps 以下ならアラートとか
    • DataMemory, IndexMemory の使用率監視
  • SQL Node
    • 接続監視
      • DN との疎通ができているかまで確認する
        • 参照更新ができることを確認
    • CPU 使用率はむしろ SQL Node のほうが使う
  • Misc.
    • OS まわり
      • NIC のリングバッファは最大に
      • DN でスワップ発生は致命的
        • vm.swappiness=0に設定しつつメモリに余裕があるか安定するまでは気を配る
    • バージョン
      • 最新バージョンをできるだけ使ったほうが恩恵が大きい
        • Join 性能が 7.2 系より 7.3 系のほうが 30 倍くらい速い

おわりに

  • MySQL Cluster
    • レンジ系、セカンダリインデックスを使用したクエリが苦手
    • 一台停止してもサービス継続するので楽
    • 主キーに対する const な select はひたすら速い
    • クエリによる向き不向きの差が大きい (通常の MySQL のほうが良いケースもあるのでよくよく検討を)

19:50 - 20:20 Mac Miniで作るMySQL Cluster MCCTバージョン by 室田さん

OpenPNE の開発をされている方

インフラ系が好きで自宅兼事務所に 42U ラックがある (それも 3 つ)

  • 月の電気代 20 万円...
  • そんな Infra でやってしまったことの共有

SAMSUNG の SSD を大量購入

  • EVO に最近変えました
  • 32 個購入
    • Write:Read=800MB/s:900MB/s
    • Thunderbolt 接続で
      • 1240MB/s:1000MB/s に

そんなインフラの上に Virtual box で MySQL Cluster 環境構築

  • Oracle VM Virtual Box に Ubuntu

今はそれを使って何をしてるか?

  • WordPress やってる
    • MySQL Cluster 上に WordPress 用の DB, User
    • Web Server 上に WP 日本語版
    • ...
  • 各テーブルを ndbcluster engine に変更
    • ここ重要
    • 11 個の WP 用のテーブルを変換 (alter table hogehoge engine=ndb;)
  • SQL Node での動作確認
  • これで WP がどれだけさばけるようになったのか?
    • 一ヶ月自動書き込み、 100 万記事更新しても問題なく動作した
    • WP の DB を MySQL Cluster にすることでよりサクサクに

OpenPNE でも可能であることを確認

  • MySQL Cluster を使った SNS の運用等も議論していきたい

ATTO という製品の紹介

  • Mac mini に FusionIO を付けれるようになる?

20:25 - 20:55 【検証結果発表】MySQL Clusterでもフラッシュドライブを活用してみる by 日本ヒューレット・パッカード株式会社 テクノロジーコンサルティング事業統括 高橋 智雄さん

資料はこちら

- 2014-06-27 16:34 追記

HP ProLiant BL 460c Gen8 上で MySQL Cluster 7.3 をうごかした検証

検証環境

  • BL460c Gen8 x 6
    • Admin x 2
    • DN x 2
    • SQL Node x 2
  • MySQL Cluster 7.3.3

検証内容

  • パラメータチューニングによる効果測定
  • フラッシュドライブを使用した場合のディスクテーブルの性能検証
    • ディスクテーブルはメモリテーブルに比較して遅いと言われている
    • ディスクテーブル用のストレージにフラシュドライブである IO アクセラレータを使ったらどうなるか
  • 測定方法
    • sysbench の complex mode で
    • Admin Node 上で
    • サーバリソースは sar で監視

メモリテーブルにおけるチューニング効果

  • 全データをメモリ上に配置して sysbench
    • Datamemory 230MB
    • Indexmemory 15MB
  • ほぼ Default
    • 3,000 TPS くらいで条件ちがっても差は大きくなし
      • DN ボトルネック? ndbmtd スレッド数がデフォなので CPU があまり使われていない
  • MaxNoOfExecutionThreads を 16 に
    • 5,000 TPS くらいまでスケール
    • 全体的に 1.5 倍に
  • ThreadConfig を設定するとさらにスケール
    • SQL Node を 2 倍に増やすと 2 倍に
  • ここまでで、 DN は CPU が平均して使用されるようになった (CPU 使用率 40% くらい)
    • SQL Node は sysbench のスレッド数の増加に伴い、使用する CPU がふえている. sys の比率が高い。
  • ndb-cluster-connection-pool を 8 にした
    • 13,500 TPS くらいまで最大伸びた
    • DN の CPU 使用率も 60% くらいまで使えるように
    • SQL Node も sys の割合が減った
  • チューニングによる応答時間の変化
    • デフォと比べると 1/4 に短縮

ディスクテーブルにおける IO アクセラレータの効果

  • HP IO アクセラレータの紹介
    • PCIe 直結お NAND フラッシュストレージ
  • データをメモリテーブルに配置したケースとディスクテーブルに配置したケースで sysbench 比較
  • 結果
    • IO アクセラレータをメモリと比較するとスループットが 1/3
    • 応答時間は 1.5 倍程度 (HDD は比較にならないくらい「遅い」)
    • IO アクセラレータ使用時は CPU の iowait が発生しなかった
      • HDD の場合は iowait 大量発生
    • IOA は HDD の 20 倍の READ 性能 (DN の場合)
  • IOA が効果的なケース
    • それほど性能欲求が高くないシステムでデータ量が 1TB なら
      • 必要メモリ 2TB + alpha
      • IOA なら DN 2台でおk
    • データ量が多くメモリのみではサーバ数が多くなりすぎるケースに良い

まとめ

  • パラメタチューニング
    • DN
      • ndbmtd を使用する
      • MaxNoOfExecutionThreads, ThreadConfig
    • SQL Node
      • db-cluster-connection-pool
    • IOA
      • メモリテーブルの 1/3 のスループット、 1.5 倍の応答時間でおさまった

21:00 - 21:30 実際に使っている人に聞く怒涛のQAタイム by 登壇者のみなさん featuring @nippondanji さん

SHOW ENGINE NDBの見方を知りたい(そもそも使う?)

  • トランザクションの ID が進んでいるかどうか
  • 生きてるノード数をみる
  • レアモノですよ、これ

Point In Time Recoveryってやったことあれば感想(?)を聞きたい。

  • できますよ
  • ふつーの MySQL とおなじようにうごくよ

EXPLAINはMySQL Serverと同じくらい役に立つ?

  • 一応役には立つと思う
  • Extra にフツーの MySQL とは違う内容がでてくる
  • 最初はこれはいいのか悪いのかわからなかった
  • 慣れたら分かる、、、、、よ?
  • Innodb とは別物とおもったほうがいいよ

60GBのデータベースを乗っけるのに、48GB(か64GB)のメモリーを積んだデータノードを2つ並べるのと32GB(か48GB)のデータノードを4つ並べるならどちらがよさげ?

  • どっちがいいかはアプリの特性に依存する
  • ノード数が増えることによる問題がないなら、安い方でいいのではないか
  • どこにそのデータがあるか特定できるような場合はスケールするものはいい
  • スキャン系はスケールしない
  • フルスキャンに近いようなものならスケールする
  • 結局は性能特性次第

NDB memcached Engineに心惹かれるんですが実績とかあれば。

  • 使ったことはあるらしいけど、あんま速くなくてやめた
  • 使い方の問題だとは思うけれども

CREATE TAMPORARY TABLE Engine= MyISAM AS SELECT .. って邪道ですか?

  • Innodb では邪道とはしってるけど
  • ローカルのテンポラリテーブルとしてやる分にはいいのでは?
  • ひまな SQL Node でやる分にはいいのでは?

SQLノード、データノードのH/Wを選定する上でのポイントを知りたい(SQLノード向きのH/W、データノード向きのH/Wスペックが知りたい)

  • Mac Mini 以外で
  • スキャンが多いなら DN にメモリいっぱい
  • バージョンによっても
  • NW ならボンディングとか
  • NUMA になってると Swap insanity とかおきてしまう
  • CPU コアは正義

DN を増やしたにもかかわらずスループットが落ちたのは?

  • 細かいスキャンがおきるとオーバーヘッドがその分増える (sysbench の中にはそういう処理があるよね)

今回も奥野さんの本が紹介されまくりでしたね。
バージョンが少し古くなっているので、そのへんの改訂がはいることを期待しつつ、今回はこんなところで。

GMO さんありがとう、な、お・ま・け

#mysql_jp に @MikumoConoHa きてた!ビッグバンカワユス! via #iphone5s

あわせて読まれたい