(cache) チューニング話が盛りだくさんの 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 を 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 日本ヒューレット・パッカード株式会社テクノロジーコンサルティング事業統括高橋智雄さん

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台でおｋ
- データ量が多くメモリのみではサーバ数が多くなりすぎるケースに良い

まとめ

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

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

奥野さん無双な QA タイム！
公開質問状より

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 の中にはそういう処理があるよね)

MySQL Cluster構築・運用バイブル　～仕組みからわかる基礎と実践のノウハウ

posted with ヨメレバ

奥野幹也技術評論社 2012-04-10

Amazon

Kindle

楽天ブックス

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

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

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

#garagekidztweetz

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