MySQLの運用でありがちなこと
Download as PPTX, PDF31 likes19,964 views
社内の主に若手向けに喋ってきた。 すでにMySQLの運用テクニックは多くのTipsが出回っているので、考え方を中心に喋ってきた。
MySQLの運用でありがちなこと
- 2. 自己紹介 • NEC soft: 2006/04〜2011/02 – Java, WebLogic, Apache, Oracle, HP-UX, RHEL • CyberAgent: 2011/03〜 – Apache, MySQL, Some NoSQLs, Intra Automation, Hardware Provisioning, CentOS • WebSite：https://hiroakis.com/
- 3. 内容 • 運用中にありがちなこと – MySQLの負荷が高い – MySQLのレプリケーションが遅延する
- 4. MySQLの負荷が高い
- 5. 負荷とはなんなのか？ Application MySQL Query MySQL OS Hardware(CPU, memory, disk, NW) Network • 負荷とは、システムのどこかに存在するボトルネックのこと – アプリケーションロジック, クエリ, MySQL, OS, CPU, Memory, Disk, Network…などなど • ボトルネックを特定して、それを解消するのが負荷対策の基本。
- 6. ボトルネックを特定する • Tools – slow log、explain、show engine innodb status, pt-query-digest, innotop…etc – munin, cacti, newrelic…etc – top, sar, dstat, vmstat, mpstat, iostat…etc
- 7. ボトルネックを特定する • ソフトウェア層 – SQL – MySQLの設定 – OS • ハードウェア層 – CPU – memory – Disk – Network
- 8. SQL • 最も重要 • ダメなSQLを治したら負荷が劇的に改善されたとかよくある • ダメなSQLの特定 – スロークエリログを見る – innotop, pt-query-digest, newrelicなどのツールを活用する – Explainで実行計画を見る • 対応 – インデックスを貼りなおす – SQLの修正を行う – テーブル構造を変える – そもそも無駄なクエリは発行しない
- 9. SQL • SQL自体は問題ないが突然ストールする場合がある • ロックの確認 – show engine innodb status – Innotop – ロック競合の解析手順 • 参考：http://d.hatena.ne.jp/sh2/20090618 • Information_schema.innodb_trx, Information_schema.innodb_locks, Information_schema.innodb_lock_waits • 対応 – アプリケーションロジックの変更も考慮する – ストレージが遅くて待たされている可能性もある
- 10. ちょっと寄り道：JOINは遅いのか？ • Nested loop joinアルゴリズム – http://dev.mysql.com/doc/refman/5.6/en/nested-loop-joins.html for each row in t1 matching range { for each row in t2 matching reference key { for each row in t3 { if row satisfies join conditions, send to client } } } • t1でフェッチされるレコード数×t2でフェッチされるレコード数×t3でフェッチされ るレコード数のループになる • 逆に言えばそれぞれのテーブルでフェッチされるレコード数が少なければJOINは 遅くはない • JOINは適切に使えば有用 • DB分割に対応しにくくなる、つまりスケーラビリティの確保の面からWeb業界では JOIN禁止というところもある
- 11. MySQLの設定 • MySQLの設定そのもので劇的に性能が良くなる 事はほとんどない(強いて言うなら innodb_buffer_pool_size)。 • たとえばinnodb_io_capacityを10000, 20000, 40000…と大きくしていっても性能が倍々になる わけではない。 • SQLやハードウェアリソース(後述)の方が負荷の 原因として支配的になりやすい。 • 設定の勘所を抑えて、my.cnfが整備されている 前提でチューニングを行うと良い。
- 12. MySQLの設定 • 性能に効いてくる箇所は下記の表のあたり • システム要件に応じて適切に設定する(信頼性を犠牲にして性能を向上させるもの もあるので注意) • MyISAMは別の設定が効いてくるが今回は割愛 • ★マークをつけたinnodb_buffer_pool_sizeとinnodb_flush_methodは最も重要 • innodb_buffer_pool_sizeは物理メモリの7〜8割にする • innodb_flush_methodはO_DIRECTにする max_connections table_open_cache sort_buffer_size join_buffer_size thread_cache_size thread_concurrency sync_binlog innodb_buffer_pool_size(★) innodb_log_file_size innodb_flush_method(★) innodb_thread_concurrency innodb_flush_log_at_trx_commit innodb_doublewrite innodb_support_xa innodb_read_io_threads innodb_write_io_threads innodb_io_capacity
- 13. OS • 次の箇所を抑える – ファイルシステム – IOスケジューラ – カーネルパラメータ • vm.swappiness
- 14. OS • ファイルシステム/IOスケジューラ – ファイルシステム • xfs or ext4 – ファイルシステムのオプション • nobarrier, noatime – IOスケジューラ(/sys/block/xxx/queue/scheduler) • deadline or noop – キューサイズ(/sys/block/xxx/queue/nr_requests) • MyISAMでは効いてくる
- 15. OS • IOスケジューラの違いによる性能評価の例 • 接続数が増えると、IOスケジューラのデフォルトであるcfqでは性能が劣化する – ツール：sysbench – CPU: Intel(R) Xeon(R) CPU E5620 2.40GHz – memory: 8G – SAS×4(RAID10) – MySQL 5.5.24 InnoDB ext4(noatime, nobarrier) xfs(noatime, nobarrier)
- 16. OS • カーネルパラメータ – vm.swappinessを適切にセットしてswapを防ぐ。 – vm.swappiness=0をセットする事でswapの発生を 抑えられる。 – 新しいカーネル(2.6.32-303〜)ではvm.swappiness の挙動が変わっているので0 はやめる。 – 1〜10あたりの、0以外の小さい値にしとくと良い。 – 参考： http://www.percona.com/blog/2014/04/28/oom-relation- vm-swappiness0-new-kernel/
- 17. ハードウェア • CPU, メモリ, Disk IO, Network IOに注目する – 一昔前はDisk IOが問題になりがちだった – 最近は大容量RAMの低価格化とFlashストレージ のコモディティ化(AWSなどはデフォルトでSSDが選 択される)により、CPUが詰まることもしばしば。 – HDDを使う場合はライトキャッシュ付きのRAIDコン トローラを用いる。 – sar, vmstat, mpstat, dstat, top, iostatなどよく知ら れたLinux系コマンドでプロファイリングできる。
- 18. ハードウェア • 負荷の箇所とアクセスパターンに応じて対策を行う。 • 参照系の対策はハードウェアの増設/増強で対応できるので比較的楽。 • 更新系の対策はマスタ分割が必要。メモリ増設やフラッシュの活用で なんとかなる場合もあるが、分割しないとレプリケーション遅延の原因 にもなる。 • マスタ分割は参照系負荷の改善にも寄与する。 • マスタ分割する場合はトランザクション境界や、管理台数が増加する ことなどを考慮する必要がある。 参照系負荷が支配的更新系負荷が支配的 CPU(user) ・スレーブを増設する・マスタ分割 Disk IO ・メモリを増やす-> innodb_buffer_pool_sizeを増やす ・フラッシュの活用 ・マスタ分割 ・参照分割 ・メモリを増やす-> innodb_buffer_pool_sizeを増やす ・フラッシュの活用 ・マスタ分割 Network ・Application <-> MySQL間で巨大すぎるデータのやりとりをしていないか？ ・高速な回線の利用
- 19. キャッシュの活用 • キャッシュの有効活用は負荷対策として非常に効果がある • 更新系が多い場合はキャッシュは効きづらい • キャッシュを使用した時点で一貫性は崩れるので、アプリケーショ ン側で整合性を意識する Application cache MySQL Reverse Proxy Varnish, apache(mod_cache), nginx(proxy_cache)…etc Application cache Memcached, Redis…etc
- 20. 負荷対策まとめ • SQLのチューニング大事。 • まずは負荷の箇所(ボトルネック)を特定する。 • 特定した上で適切な対策を施す。 • キャッシュは偉大なソリューションだが、一貫 性に注意する。
- 21. レプリケーションが遅延する
- 22. MySQLのレプリケーションの仕組み Master 書き込み 更新系クエリスレッド Data Data IOスレッド Slave Binary log Relay log SQLスレッド • レプリケーションの処理を行うのはIOスレッドとSQLスレッド
- 23. 遅延の原因として考えられること 1. SQLスレッドが追いつかない 2. トランザクションが巨大すぎる 3. スレーブのDisk IO 4. スレーブのCPU(user)負荷 5. Master – Slave間のネットワーク的な問題
- 24. SQLスレッドが追いつかない • 更新系クエリが多すぎる。 • マスタはアプリケーションが発行する更新系 クエリを並列に処理できるが、SQL スレッドは 1スレッドで動く。 • マスタ分割を行うことで対応する。
- 25. トランザクションが巨大すぎる • 巨大テーブルにalter tableしたとき – オンラインスキーマチェンジの活用 – MySQL5.6〜ではオンラインでのalterが可能 • 大量のレコードを一度に更新したとき – バッチなどでたまに見かける – トランザクションをこまめに分割する • たとえば… • ×: 100000レコードを更新-> コミット • ○: 1000レコードを更新-> コミットを100回繰り返す
- 26. スレーブのDisk IO • スレーブのストレージのDisk IOがボトルネック • フラッシュストレージを活用してIO待ちを減ら す。 • それでもダメならマスタ分割して更新系クエリ を散らす
- 27. スレーブのCPU(user)負荷 • スレーブのCPU負荷が高くてレプリケーション の処理が邪魔されるケース • スレーブを増設してCPU負荷を散らす
- 28. Master – Slave間のネットワーク • あまり発生しないが原因にはなりうる • 日本– 海外でレプリケーションを組んでいる 場合など • スレーブが多すぎてbinlogの転送がNW帯域 を圧迫してしまっている場合は孫スレーブを 作る事を検討する。
- 29. 遅延対策まとめ • 負荷対策と同じく、まずはどこがボトルネック なのかを見極める。
- 30. 全体的なまとめ • 何度も言うけど、とにもかくにもボトルネックの 特定を行う。 • これができれば負荷対策はほぼ完了したよう なもの。 • 「とりあえずサーバ増やしましょう」とかすると ドツボにはまる。