第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ

22,124 views

Published on

3 Comments
85 Likes
Statistics
Notes
No Downloads
Views
Total views
22,124
On SlideShare
0
From Embeds
0
Number of Embeds
6,671
Actions
Shares
0
Downloads
0
Comments
3
Likes
85
Embeds 0
No embeds

No notes for slide

第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ

  1. 1. ioDriveの世界へようこそ 2012/08/27第2回 ioDrive+MySQL勉強会 外道父@GedowFather Copyright © DRECOM Co., Ltd All Rights Reserved. 1
  2. 2. 自己紹介 Copyright © DRECOM Co., Ltd All Rights Reserved. 2
  3. 3. 自己紹介■私は 外道父@GedowFather■所属 ドリコム■職種 インフラエンジニア■ブログ http://blog.father.gedow.net/ Copyright © DRECOM Co., Ltd All Rights Reserved. 3
  4. 4. 目 次 Copyright © DRECOM Co., Ltd All Rights Reserved. 4
  5. 5. 目次 1. ioDriveを使う理由 2. サーバ構成 3. キャパシティの計測 4. IOPSの次の敵 Copyright © DRECOM Co., Ltd All Rights Reserved. 5
  6. 6. WARNING !! この資料にはioDriveを褒め称 える表現が多く含まれています 全て事実に基づくものであり、 ステマの類ではありません Copyright © DRECOM Co., Ltd All Rights Reserved. 6
  7. 7. ioDriveを 使う理由 Copyright © DRECOM Co., Ltd All Rights Reserved. 7
  8. 8. ioDriveの基本性能や運用について ブログに書いてありますhttp://blog.father.gedow.net/category/hardware/iodrive/ Copyright © DRECOM Co., Ltd All Rights Reserved. 8
  9. 9. ioDriveのおさらい 200,000 IOPS Access Latency 26µs 速いめっちゃ 全っ然 write 数TB / Day 壊れない 性能の割に Warranty 数十年 高くない 100~300万円 Copyright © DRECOM Co., Ltd All Rights Reserved. 9
  10. 10. IOPSが凄い! Copyright © DRECOM Co., Ltd All Rights Reserved. 10
  11. 11. IOPSが凄い!速いSAS 15,000 rpm × 6 RAID10 1,000 IOPS ioDrive 200,000 IOPS 以上 Copyright © DRECOM Co., Ltd All Rights Reserved. 11
  12. 12. IOPSが凄い!速い UPDATE1,000 QPS1,000 IOPS 200,000 IOPSiowait 80% iowait 3% Copyright © DRECOM Co., Ltd All Rights Reserved. 12
  13. 13. IOPSが凄い!速い圧倒的パワー IOPS限界を解決することでiowaitを激減! Copyright © DRECOM Co., Ltd All Rights Reserved. 13
  14. 14. Access Latencyが凄い! Copyright © DRECOM Co., Ltd All Rights Reserved. 14
  15. 15. Access Latencyが凄い!速い 3ms その差100 倍 30µs Copyright © DRECOM Co., Ltd All Rights Reserved. 15
  16. 16. Access Latencyが凄い!速い 2,000 QPS3ms 30µsiowait 15% iowait 2%以下 Copyright © DRECOM Co., Ltd All Rights Reserved. 16
  17. 17. Access Latencyが凄い!速い圧倒的スピード CPUとの往復時間を 短くすることで 常時 iowaitを激減! Copyright © DRECOM Co., Ltd All Rights Reserved. 17
  18. 18. 圧倒的パワー 圧倒的スピード ザ・ワールド 世 界ioDriveの世界へ入門 クエリが 止まって見えるぜ Copyright © DRECOM Co., Ltd All Rights Reserved. 18
  19. 19. 耐久年数が凄い! Copyright © DRECOM Co., Ltd All Rights Reserved. 19
  20. 20. 壊れない 耐久年数が凄い! ioDrive160GB SLC書き込み平均75PB まで write 10TB / Day ・・・? 耐久年数 20.5年 Copyright © DRECOM Co., Ltd All Rights Reserved. 20
  21. 21. 壊れない 耐久年数が凄い! 参照 平均 3,000 QPS 更新 平均 300 QPS書き込み平均 10 MB/秒 Copyright © DRECOM Co., Ltd All Rights Reserved. 21
  22. 22. 壊れない 耐久年数が凄い! 書き込み平均 10MB × 86400秒 864GB / 日 耐久年数 75PB ÷ 864GB ÷ 365日 237年 ioDriveは砕けない Copyright © DRECOM Co., Ltd All Rights Reserved. 22
  23. 23. 費用対効果が高い! Copyright © DRECOM Co., Ltd All Rights Reserved. 23
  24. 24. 高くない 費用対効果が高い!SAS 15,000 rpm 300GB RAIDコントローラー 30~40万円 (1,000 IOPS) ioDrive 100~300万円 (200,000 IOPS以上) Copyright © DRECOM Co., Ltd All Rights Reserved. 24
  25. 25. 高くない 費用対効果が高い!30~40万円 価格差 100~300万円 4~5倍1,000 IOPS IOPS差 200,000 IOPS 200倍以上 Copyright © DRECOM Co., Ltd All Rights Reserved. 25
  26. 26. サーバ台数の削減 Copyright © DRECOM Co., Ltd All Rights Reserved. 26
  27. 27. サーバ台数の削減1,000 IOPS IOPS差 200,000 IOPS 200倍以上 といっても、 実際にはどのくらいの サーバ台数を削減できるのか? Copyright © DRECOM Co., Ltd All Rights Reserved. 27
  28. 28. Before Max CPU : 1,600% Max IOPS : 1,000 1台当り CPU : 500% IOPS : 8008台構成 合計 CPU : 4,000% IOPS : 6,400 Copyright © DRECOM Co., Ltd All Rights Reserved. 28
  29. 29. After 必要合計スペック CPU : 4,000% IOPS : 6,400 Max CPU : 1,600% Max IOPS : 200,000CPU視点で必要な台数4000% ÷ 1600% 3台 削IOPS視点で 減6,400 ÷ 200,000 1台 Copyright © DRECOM Co., Ltd All Rights Reserved. 29
  30. 30. After その他の要素 1台当り CPU : 1,300% 3台構成 IOPS : 2,100CPUとIOPSをメインで考えるが、さらに  CPUがギリギリ  記憶デバイスの容量  メモリ容量  可用性/負荷分散 構成などを元に数ヶ月後を見据えた台数にする Copyright © DRECOM Co., Ltd All Rights Reserved. 30
  31. 31. サーバ構成 Copyright © DRECOM Co., Ltd All Rights Reserved. 31
  32. 32. MySQLサーバ MySQL Community Server 5.5.x Percona Server with XtraDB 5.5.x Copyright © DRECOM Co., Ltd All Rights Reserved. 32
  33. 33. Percona Server の特徴 MySQLのForkである 性能面/機能面で劣ることはない マルチコアCPU・同時アクセスI/Oに配慮 効率的なバックアップ/その他周辺機能 本家に1~2ヶ月程度の遅れでリリース マニュアルが整備されている 各種OS用のパッケージを配布 Copyright © DRECOM Co., Ltd All Rights Reserved. 33
  34. 34. Percona Server Percona Server を 使わない理由がない Copyright © DRECOM Co., Ltd All Rights Reserved. 34
  35. 35. 並列処理やI/Oの設定 ~ my.cnf ~ Copyright © DRECOM Co., Ltd All Rights Reserved. 35
  36. 36. XtraDBです  default-storage-engine = InnoDB 表示上は今までどおり InnoDB ですが、 中身は XtraDB になっています。 mysql> SHOW ENGINES ¥G ********************** 9. row ********************** Engine : InnoDB Support : DEFAULT Comment : Percona-XtraDB, Supports transactions, row-level locking, and foreign keys Transactions : YES XA : YES Savepoints : YES  全テーブルをInnoDBにしてPerconaの恩恵を受けましょう  MyISAMがあるとバックアップでロックが入ってしまいます Copyright © DRECOM Co., Ltd All Rights Reserved. 36
  37. 37. よく知られた設定  innodb_flush_method = O_DIRECT OSによるバッファリングを抑制し、MySQLとOSによるダ ブルバッファリング状態を防ぎ無駄を省きます  innodb_flush_log_at_trx_commit = 2  ログファイルへの書き出しをCOMMIT毎、データファイルへ の書き出しを毎秒にすることでフラッシュ効率を上げます  よほど安全にしたいなら 1ですが遅いです  0 はリスクが上がる割に効果が薄いので使いません Copyright © DRECOM Co., Ltd All Rights Reserved. 37
  38. 38. Disk I/O  innodb_io_capacity = 40000  デバイスのIOPS上限を設定できます  実運用では 10,000台がせいぜいですが、上限を設ける理由 もないので、それ以上にします  innodb_read_io_threads = 8  innodb_write_io_threads = 16  読み書きの同時スレッド数  ioDriveの24+1チャネル に合わせたが…  デフォルトはどちらも 4 Copyright © DRECOM Co., Ltd All Rights Reserved. 38
  39. 39. CPUスレッド  innodb_thread_concurrency = 0  並列処理するCPUのスレッド数です  0 は上限なしを意味します  1以上を指定するとそのスレッド数でしか動かないので、1ス レッドは空けておきたい、という時に使えなくもないです  thread_concurrency = 16  Solaris特有のもの  5.6.1で廃止される  innodb_thread_concurrency を使いましょう Copyright © DRECOM Co., Ltd All Rights Reserved. 39
  40. 40. ディスクフラッシュ – チェックポイント innodb_adaptive_flushing = true innodb_adaptive_flushing_method = keep_average 従来のInnoDBの場合、ログファイルからのフラッシュ間隔が 結構長くなります そのため、ある程度まとめてデータを書き込むため瞬間的に高 いIOPSを必要とし、それが原因でiowaitが高騰します keep_average にすると、0.1秒間隔となり、緩やかな iowait になり、デメリットも見受けられません 主にSSDやioDrive用として追加されましたが、HDDでも使っ てみてよいと思います Copyright © DRECOM Co., Ltd All Rights Reserved. 40
  41. 41. ディスクフラッシュ – 隣接ページ  innodb_flush_neighbor_pages = none  デフォルトのareaの場合、フラッシュしようとするページの 隣接したページもある程度まとめて書き込もうとします  HDDの場合は効率が上がる可能性があります  ランダムアクセスのコストが小さいioDriveでは余計な機能と なり、外したほうが効率が上がる可能性があります Copyright © DRECOM Co., Ltd All Rights Reserved. 41
  42. 42. ログファイル  innodb_log_block_size = 4096  ioDriveを、MySQLにおいてパフォーマンスが良いとさ れる4Kbyteでフォーマットした場合、合わせることで 性能が若干向上します  ただし雀の涙程度なので、途中から変えるほどではなく、 最初からできるならしておこう、程度です Copyright © DRECOM Co., Ltd All Rights Reserved. 42
  43. 43. Atomic Write Copyright © DRECOM Co., Ltd All Rights Reserved. 43
  44. 44. Atomic Write  新機能  絶賛開発中  Double Write の代替  2度書き込む必要が無いようにioDrive側で保証する  アクセス速度の向上、ioDrive寿命が倍 (参考資料) Tuning For Speed: Percona Server and Fusion-io http://www.slideshare.net/fusionio/tuning-for-speed-percona-server-and-fusionio Copyright © DRECOM Co., Ltd All Rights Reserved. 44
  45. 45. バックアップ Copyright © DRECOM Co., Ltd All Rights Reserved. 45
  46. 46. XtraBackupでバックアップ  別途パッケージでインストール  クエリベースではなくデータファイル丸ごとの形 デメリット メリット  InnoDBのみの場合、  mysqldumpよりバッ ロックを必要としない クアップ容量が大きい  差分バックアップや  mysqldumpより取得 tarストリーミング出 に時間がかかる 力など多機能  リストアが速い Copyright © DRECOM Co., Ltd All Rights Reserved. 46
  47. 47. レプリケーション Copyright © DRECOM Co., Ltd All Rights Reserved. 47
  48. 48. Semi-Synchronous Replication SLAVEでの relay-log 保存を CLIENT 確定してからCOMMIT完了と する例のアレ ack MASTER SLAVE log 目的  信頼度の高いバックアップ  可用性担保のフェイルオーバー用 Copyright © DRECOM Co., Ltd All Rights Reserved. 48
  49. 49. Semi-Syncが遅くなる理由  MASTER ⇔ SLAVE のネットワーク往復  SLAVEでのログ保存 Disk I/O  IO_THREAD と SQL_THREAD の非分離  非同期の場合は別スレッドで動作する  Semi-Syncの場合は1スレッドで両方動作する SLAVE I/O CPU SQL CPU 40% 100% 非同期 (Thread A) (Thread B) 30% 70% Semi-Sync (Thread A) (Thread A) Copyright © DRECOM Co., Ltd All Rights Reserved. 49
  50. 50. Semi-Syncを採用できる理由 更新QPSは確実に低下するが・・・ ベンチマーク例 非同期 : 更新 12,000 QPS Semi-Sync : 更新 7,000 QPS 約40%の性能低下 は問題ではない 更新 7,000 QPS が足りていればOK Copyright © DRECOM Co., Ltd All Rights Reserved. 50
  51. 51. クラスタ構成 Copyright © DRECOM Co., Ltd All Rights Reserved. 51
  52. 52. turntable ① User01 User02 User03 Other01 ioDrive ioDrive ioDrive ・・・ SAS ・・・ Active MASTER MASTER MASTER ・・・ MASTER ・・・② Standby SLAVE SLAVE SLAVE ・・・ SLAVE ・・・③ 予備 ioDrive SAS ① 垂直/水平分割へ接続 ② MASTER障害時にSLAVEが自動昇格 ③ SLAVE不在時に自動的にSLAVE化 Copyright © DRECOM Co., Ltd All Rights Reserved. 52
  53. 53. ① turntableで垂直/水平分割へ接続  Gussan  ドリコム所属  activerecord-turntable 製作者 (参考URL) Github https://github.com/drecom/activerecord-turntable SlideShare http://www.slideshare.net/drecom/activerecordturntable  Ruby on Rails の Active Record で利用できる Shardingプラグイン  テーブルの垂直分割だけでなく、行条件での水平分散 ができる Copyright © DRECOM Co., Ltd All Rights Reserved. 53
  54. 54. ② MASTER障害時にSLAVEが自動昇格 VIP MASTER MASTER VIP SLAVE MASTER MASTERのVIPに影響あるほどの障害  VIPが移動して接続先が ローカル監視で障害と判断したら自動的 切り替わる にVIPを放棄  フェイルバックは抑制 Copyright © DRECOM Co., Ltd All Rights Reserved. 54
  55. 55. ③ SLAVE不在時に自動的にSLAVE化 VIP VIP MASTER MASTER ioDrive SLAVE MASTERが自身にSLAVEが無  予備機がバックアップファイル いことを確認する からリストアする 予備機に対してSLAVE化を要請  MASTER に START SLAVE ※1クラスタに1予備機は無駄なので、ioDrive/SASそれぞれ1台ずつ用意 Copyright © DRECOM Co., Ltd All Rights Reserved. 55
  56. 56. その他の検討構成 Copyright © DRECOM Co., Ltd All Rights Reserved. 56
  57. 57. その他の検討構成 MySQL SPIDER 要件によっては間違いなく便利だが、当時は効率を考えた時にいく つか不安になった  更新クエリのたびに全台にXAトランザクションが発行される  集約関数は一度行データを集めてから数えるので非効率MySQL Cluster 期待した性能は出なかった 構築も運用も難しいため、エンジニア全員が 身に付けるには敷居が高い MySQL Proxy  自動MASTER昇格や正しい参照分散ができる LUAスクリプトを書いて楽しかった  小規模では有用だが・・・ Copyright © DRECOM Co., Ltd All Rights Reserved. 57
  58. 58. キャパシティの計測 Copyright © DRECOM Co., Ltd All Rights Reserved. 58
  59. 59. 計測条件MySQLのベンチマークにおいて重要なこと  クエリの種類(参照/更新)  データの容量とメモリの容量  データの性質 4つの計測条件 参照クエリ データ容量 ≦ メモリ容量 更新クエリ データ容量 ≧ メモリ容量 本番データ/本番クエリだからとやみくもにベンチマークをとっても、 真のキャパシティは計測できません Copyright © DRECOM Co., Ltd All Rights Reserved. 59
  60. 60. CPUとIOPS Copyright © DRECOM Co., Ltd All Rights Reserved. 60
  61. 61. 参照/更新クエリの必要性能 データ容量 ≦ メモリ容量 全データがメモリに収まる状況において 参照クエリ : CPU 更新クエリ : IOPS  参照はIOPSを必要としない  更新はWEBアプリだと主キー更新 主体のためCPUは微量 Copyright © DRECOM Co., Ltd All Rights Reserved. 61
  62. 62. 先行するボトルネックを見極めるキャパシティ MAX My Limit CPU 1,600% 800% 増設納期を IOPS 1,000 500 考慮して半分 比較 現在値 ピークタイム あと何倍 CPU 200% 4倍 先に到達 IOPS 100 5倍 リクエストがあと4倍に増えたら増設手続きに 入るという判断 ioDriveの場合はIOPSの判断がほぼ不要になる Copyright © DRECOM Co., Ltd All Rights Reserved. 62
  63. 63. メモリとデータ容量 Copyright © DRECOM Co., Ltd All Rights Reserved. 63
  64. 64. メモリの重要性 innodb_buffer_pool_size write IOPS しか発生しないデータ 100 GBメモリ 128 GB 参照 : 全てメモリから読み込まれる 更新 : フラッシュのみwrite IOPSが発生する 通常の write IOPS に加えて大量の read IOPS が発生データ 200 GBメモリ 128 GB 72 GB 不足 参照 : 72GB分はread IOPSが発生する 更新 : 同上+フラッシュ時にwrite IOPS Copyright © DRECOM Co., Ltd All Rights Reserved. 64
  65. 65. LRUによるバッファプール管理 innodb_buffer_pool_size よくアクセスするデータ メモリ破棄予備軍 YOUNG OLD 62% (5/8) 38% (3/8) アクセスされると戻る DISK 破棄 メモリになければ読み込まれ read IOPS が発生する Copyright © DRECOM Co., Ltd All Rights Reserved. 65
  66. 66. メモリとデータ容量にみる read IOPS アクセス頻度が高いデータ アクセス頻度が低いデータSAFE : 全データがメモリに格納されており read IOPS は発生しない young old disk dataWARNING : デバイスに read IOPS が発生し始める young old disk dataCRITICAL : デバイスに頻繁な read IOPS が発生し始める young old disk data Copyright © DRECOM Co., Ltd All Rights Reserved. 66
  67. 67. データの性質とは アクセス頻度が高いデータテーブルごとに考えてみる アクセス頻度が低いデータ User Item History例)アイテム数カウント 例)履歴データ何年経過しても全データが対象 最新数十件しか必要ないデータ全体で考えてみる頻繁に利用されるデータの割合が多いのか disk data古い不要データによって総容量が増加しているだけなのか disk data 後者ならばメモリ不足が許容されるが、 この度合いを確実に知る術は無い Copyright © DRECOM Co., Ltd All Rights Reserved. 67
  68. 68. メモリ管理とデバイスごとの対応 メモリからはみ出たデータの IOPS を 確実には読めなく、被害大の可能性がある メモリの増設やサーバ分割により 常にメモリに収めるのが確実 メモリからはみ出たデータへのアクセスも アプリに影響ない程度の速度で動作をする 場合が多い  それなりに放置しても大丈夫  メモリ管理の知識や緊張が薄くなる  酷いクエリ/インデックスでも動く『ioDriveは甘え』の所以 Copyright © DRECOM Co., Ltd All Rights Reserved. 68
  69. 69. 暖機運転MySQLの起動直後はいっさいメモリに載っていないためメモリに載るまでレスポンスが遅くなる young old disk data 最初は全てdiskから HTTPを再開する前に 主要テーブルに全参照をかけて 暖機運転をする必要がある diskアクセスでもHTTPが許容範囲で 動作するほど速いため暖機運転は必要ない 『ioDriveの恩恵』でOK Copyright © DRECOM Co., Ltd All Rights Reserved. 69
  70. 70. SQLの質 Copyright © DRECOM Co., Ltd All Rights Reserved. 70
  71. 71. ioDriveは甘え  IOPS限界が無い  read I/O が発生しても致命傷にならない  スキーマの質 確実に全て下がる  インデックスの質  クエリの質 開発力の低下 必要  開発ルールの整備 堕  自動的な質のチェック 落 Copyright © DRECOM Co., Ltd All Rights Reserved. 71
  72. 72. Generalistによる質の定量化  外道父が書いた1枚のPHPスクリプト  参照クエリ/更新クエリ/インデックスの 質を数値化  悪い順に並べたTSVデータ出力しエクセル で閲覧したり、snmpd用値を出力  1時間に1度実行しておく  general.log を採取  クエリのユニーク化  SHOW や EXPLAIN で色々取得  外道父ルールで勝手に質を数値化 Copyright © DRECOM Co., Ltd All Rights Reserved. 72
  73. 73. Generalist の 参照クエリ診断  DQP(Dirty Query Points)が悪い順に解 決していけばOK  実際のクエリとEXPLAIN結果  悪いと評価した項目とその度合い Copyright © DRECOM Co., Ltd All Rights Reserved. 73
  74. 74. Generalist の 更新クエリ診断  DUP(Dirty Update Points)が悪い順に 解決していけばOK  更新行数や更新カラムの対象となるイン デックス数などから診断 Copyright © DRECOM Co., Ltd All Rights Reserved. 74
  75. 75. Generalist の インデックス診断  DIP(Dirty Index Points)が悪い順に 解決していけばOK  複合インデックスのCardinality効率など から診断 Copyright © DRECOM Co., Ltd All Rights Reserved. 75
  76. 76. IOPSの次の敵 Copyright © DRECOM Co., Ltd All Rights Reserved. 76
  77. 77. IOPSの次の問題は? IOPSioDriveの出現による 新時代の幕開け CPU Network Software Copyright © DRECOM Co., Ltd All Rights Reserved. 77
  78. 78. IPMI Copyright © DRECOM Co., Ltd All Rights Reserved. 78
  79. 79. ioDriveは暴れん坊? ioDrive搭載サーバで、サーバ起動時から 何もしていないのにSystemCPUが50% 50% 新しく入れたioDriveを疑うのだ! ioDriveが悪いに決まってる!! Copyright © DRECOM Co., Ltd All Rights Reserved. 79
  80. 80. 犯人はIPMIでした ipmitool パッケージの ipmiモジュールを 削除したら解決しました(テヘペロ ioDriveが悪いわけないじゃない まだまだ信心が足りないわ! Copyright © DRECOM Co., Ltd All Rights Reserved. 80
  81. 81. NUMA Copyright © DRECOM Co., Ltd All Rights Reserved. 81
  82. 82. ioDriveは気まぐれ屋? ioDrive搭載サーバで、iowaitが急増したり グラフが虫食いになるほどの状態になる 20~80% 新しく入れたioDriveを疑うのだ! ioDriveが悪いに決まってる!! Copyright © DRECOM Co., Ltd All Rights Reserved. 82
  83. 83. あらゆる調査を行った aio vmstat io_schedule iostat strace pidstat mpstat top lsof netstat sysctl ipcs meminfo slabinfo sar ulimit nsswitch.conf resolv.conf nscd ldap ・・・問題発生時は Disk I/O だけでなくメモリも遅いぞ!? Copyright © DRECOM Co., Ltd All Rights Reserved. 83
  84. 84. 犯人はNUMAでした NUMAを無効にしたら 全てが正常に動作しました(ゲッソリ sysctl -w vm.zone_reclaim_mode=0NUMAとは多量マルチプロセッサにおいて効率的なメモリアクセスを試みるアーキテクチャ ※kenerl >= v2.6.29  iowait には Disk I/O だけじゃなく Memory I/O も含むのは常識よ!  せいぜいデュアルCPUのくせに NUMAが有効なんておこがましいわ! Copyright © DRECOM Co., Ltd All Rights Reserved. 84
  85. 85. query_cache Copyright © DRECOM Co., Ltd All Rights Reserved. 85
  86. 86. ioDriveの副作用? ioDrive入れたからベンチマークとってみたけど 全然性能でないし、なんかCPU詰まってる! キャパシティ : 1600% ベンチマーク : 350% まで 新しく入れたioDriveを疑うのだ! ioDriveが悪いに決まってる!! Copyright © DRECOM Co., Ltd All Rights Reserved. 86
  87. 87. 犯人はquery_cacheでした query_cacheを無効にしたら 最大までCPUが稼働しました query_cache_type=0 ※query_cache_size=0 だけじゃダメキャッシュONで高負荷をかけると mutex lock の増加によって Software Interrupt や Context Switch が増加してCPU利用率が上がらなくなる  キャッシュは効いてた方が良いなんて 人間の傲慢だわ  場合によりけりといってもOFFにし た方が安定稼働が望めるよ Copyright © DRECOM Co., Ltd All Rights Reserved. 87
  88. 88. その他の注意点 Copyright © DRECOM Co., Ltd All Rights Reserved. 88
  89. 89. 経験の少ない領域へ何年も悩んできたIOPS周りあまりにその問題に注力してきたために ioDriveの導入によって 未経験の問題が襲い掛かることでしょう MySQL OS ハードウェア CPUmy.cnf ファイル メモリトランザクション メモリ データ容量レプリケーション ネットワーク ネットワーク Copyright © DRECOM Co., Ltd All Rights Reserved. 89
  90. 90. 導入後もioDriveに甘えず精進せよ! fin Copyright © DRECOM Co., Ltd All Rights Reserved. 90

×