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.

MySQLの運用でありがちなこと

13,982 views

Published on

社内の主に若手向けに喋ってきた。
すでにMySQLの運用テクニックは多くのTipsが出回っているので、考え方を中心に喋ってきた。

Published in: Internet
  • Be the first to comment

MySQLの運用でありがちなこと

  1. 1. MySQLの運用でありがちなこと 2014/09/09 Hiroaki Sano
  2. 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. 3. 内容 • 運用中にありがちなこと – MySQLの負荷が高い – MySQLのレプリケーションが遅延する
  4. 4. MySQLの負荷が高い
  5. 5. 負荷とはなんなのか? Application MySQL Query MySQL OS Hardware(CPU, memory, disk, NW) Network • 負荷とは、システムのどこかに存在するボトルネックのこと – アプリケーションロジック, クエリ, MySQL, OS, CPU, Memory, Disk, Network…などなど • ボトルネックを特定して、それを解消するのが負荷対策の基本。
  6. 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. 7. ボトルネックを特定する • ソフトウェア層 – SQL – MySQLの設定 – OS • ハードウェア層 – CPU – memory – Disk – Network
  8. 8. SQL • 最も重要 • ダメなSQLを治したら負荷が劇的に改善されたとかよくある • ダメなSQLの特定 – スロークエリログを見る – innotop, pt-query-digest, newrelicなどのツールを活用する – Explainで実行計画を見る • 対応 – インデックスを貼りなおす – SQLの修正を行う – テーブル構造を変える – そもそも無駄なクエリは発行しない
  9. 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. 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. 11. MySQLの設定 • MySQLの設定そのもので劇的に性能が良くなる 事はほとんどない(強いて言うなら innodb_buffer_pool_size)。 • たとえばinnodb_io_capacityを10000, 20000, 40000…と大きくしていっても性能が倍々になる わけではない。 • SQLやハードウェアリソース(後述)の方が負荷の 原因として支配的になりやすい。 • 設定の勘所を抑えて、my.cnfが整備されている 前提でチューニングを行うと良い。
  12. 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. 13. OS • 次の箇所を抑える – ファイルシステム – IOスケジューラ – カーネルパラメータ • vm.swappiness
  14. 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. 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. 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. 17. ハードウェア • CPU, メモリ, Disk IO, Network IOに注目する – 一昔前はDisk IOが問題になりがちだった – 最近は大容量RAMの低価格化とFlashストレージ のコモディティ化(AWSなどはデフォルトでSSDが選 択される)により、CPUが詰まることもしばしば。 – HDDを使う場合はライトキャッシュ付きのRAIDコン トローラを用いる。 – sar, vmstat, mpstat, dstat, top, iostatなどよく知ら れたLinux系コマンドでプロファイリングできる。
  18. 18. ハードウェア • 負荷の箇所とアクセスパターンに応じて対策を行う。 • 参照系の対策はハードウェアの増設/増強で対応できるので比較的楽。 • 更新系の対策はマスタ分割が必要。メモリ増設やフラッシュの活用で なんとかなる場合もあるが、分割しないとレプリケーション遅延の原因 にもなる。 • マスタ分割は参照系負荷の改善にも寄与する。 • マスタ分割する場合はトランザクション境界や、管理台数が増加する ことなどを考慮する必要がある。 参照系負荷が支配的更新系負荷が支配的 CPU(user) ・スレーブを増設する・マスタ分割 Disk IO ・メモリを増やす-> innodb_buffer_pool_sizeを増やす ・フラッシュの活用 ・マスタ分割 ・参照分割 ・メモリを増やす-> innodb_buffer_pool_sizeを増やす ・フラッシュの活用 ・マスタ分割 Network ・Application <-> MySQL間で巨大すぎるデータのやりとりをしていないか? ・高速な回線の利用
  19. 19. キャッシュの活用 • キャッシュの有効活用は負荷対策として非常に効果がある • 更新系が多い場合はキャッシュは効きづらい • キャッシュを使用した時点で一貫性は崩れるので、アプリケーショ ン側で整合性を意識する Application cache MySQL Reverse Proxy Varnish, apache(mod_cache), nginx(proxy_cache)…etc Application cache Memcached, Redis…etc
  20. 20. 負荷対策まとめ • SQLのチューニング大事。 • まずは負荷の箇所(ボトルネック)を特定する。 • 特定した上で適切な対策を施す。 • キャッシュは偉大なソリューションだが、一貫 性に注意する。
  21. 21. レプリケーションが遅延する
  22. 22. MySQLのレプリケーションの仕組み Master 書き込み 更新系クエリスレッド Data Data IOスレッド Slave Binary log Relay log SQLスレッド • レプリケーションの処理を行うのはIOスレッドとSQLスレッド
  23. 23. 遅延の原因として考えられること 1. SQLスレッドが追いつかない 2. トランザクションが巨大すぎる 3. スレーブのDisk IO 4. スレーブのCPU(user)負荷 5. Master – Slave間のネットワーク的な問題
  24. 24. SQLスレッドが追いつかない • 更新系クエリが多すぎる。 • マスタはアプリケーションが発行する更新系 クエリを並列に処理できるが、SQL スレッドは 1スレッドで動く。 • マスタ分割を行うことで対応する。
  25. 25. トランザクションが巨大すぎる • 巨大テーブルにalter tableしたとき – オンラインスキーマチェンジの活用 – MySQL5.6〜ではオンラインでのalterが可能 • 大量のレコードを一度に更新したとき – バッチなどでたまに見かける – トランザクションをこまめに分割する • たとえば… • ×: 100000レコードを更新-> コミット • ○: 1000レコードを更新-> コミットを100回繰り返す
  26. 26. スレーブのDisk IO • スレーブのストレージのDisk IOがボトルネック • フラッシュストレージを活用してIO待ちを減ら す。 • それでもダメならマスタ分割して更新系クエリ を散らす
  27. 27. スレーブのCPU(user)負荷 • スレーブのCPU負荷が高くてレプリケーション の処理が邪魔されるケース • スレーブを増設してCPU負荷を散らす
  28. 28. Master – Slave間のネットワーク • あまり発生しないが原因にはなりうる • 日本– 海外でレプリケーションを組んでいる 場合など • スレーブが多すぎてbinlogの転送がNW帯域 を圧迫してしまっている場合は孫スレーブを 作る事を検討する。
  29. 29. 遅延対策まとめ • 負荷対策と同じく、まずはどこがボトルネック なのかを見極める。
  30. 30. 全体的なまとめ • 何度も言うけど、とにもかくにもボトルネックの 特定を行う。 • これができれば負荷対策はほぼ完了したよう なもの。 • 「とりあえずサーバ増やしましょう」とかすると ドツボにはまる。

×