和牛をおいしく食べるには
- 1. 和牛をおいしく食べるには 小澤 真之 (@Masayuki_Ozawa) このスライドはこちらから→ http://sdrv.ms/17IJSHj
- 2. 自己紹介 • SQL Server を全力でぶん回すのが 好きな DB 屋さんです。 • ブログ : SE の雑記 – http://engineermemo.wordpress.com • Twitter : @Masayuki_Ozawa • Facebook : Masayuki.Ozawa 2
- 3. みんな大好き和牛！！ • 和牛 = A6 や A7 サイズのメモリ集中型インスタンス ここのおいしい 調理方法って?? ※元の画像 : https://twitter.com/naoto_matsumoto/status/372270113279311873/photo/1 3
- 4. 調理の際には気を付けましょう • 調理中にお手紙をいただきました たしかに、VHD を 2 回ぐらいアップロードしました…。 4
- 5. 和牛の基本スペック • XL と A7 は 2 NUMA ノードの 構成 – CPU XL と A7 でメモリ以外の スペックは同等 • 1 NUMA ノード : 4 コア • Max Worker Count(Thread) : 576 (8 コアの自動設定) – メモリ • XL : 1 ノード 7GB (2 ノード 14GB) • A7 : 1 ノード 28 GB (2 ノード 56 GB) – Large / A6 は 1 NUMA ノード • XL でテストをしてから A7 にス ケールアップするのが課金的に おすすめ ※ 以前は、XL (800Mbps) と A7 (2,000 Mbps) のネットワーク帯域も違ったはずなのですが 今の公開情報からは消えていました。 5
- 7. レシピ • Azure VM で SQL Server を実行する際の参考情報は以下 に公開されています – Performance Guidance for SQL Server in Windows Azure Virtual Machines http://msdn.microsoft.com/en-us/library/windowsazure/dn248436.aspx 7
- 8. 調理のポイント • ディスクの構成に注意!! – SQL Server では Write Cache は無効 – Read Cache が有効なデータディスクは最大で 4 本まで (OS のディスクを含めると 5 本) – ジオレプリケーションの有効化は注意 • 同一のディスクにデータファイルとログファイルを配置し、単一ディスク内でデータベースが完結している場合 にのみ有効化 • Windows Server 2012 の記憶域プールでディスクをストライピングする場合は PowerShell で!! – 現状、GUI (サーバーマネージャー) からはディスクが 1 本しか見えないため、PowerShell で 追加する必要がある – Physical Disks showing up in Disks in Storage but not in Primordial pool on the storage pools tab http://social.technet.microsoft.com/Forums/windowsserver/en-US/13a7b824-40e8-4c6d-b5a1-52bc9de9c9d3/physical-disks-showing-up-in-disks-in-storage-butnot-in-primordial-pool-on-the-storage-pools-tab 8
- 9. ディスクの性能 (SQLIO) • 500 IOPS = キャッシュ無効時のディスク性能 ディスク × 1 ディスク × 16 8KB 8KB Sequential Read IOPS MB/sec Write 497.03 491.73 3.88 Sequential Random Write 16 倍 496.70 494.75 Read Read 3.84 3.88 3.86 IOPS MB/sec Write Read Write 7939.17 5041.05 7864.28 4603.51 62.02 35.45 61.43 35.96 64KB 64KB Sequential Read IOPS MB/sec Write 179.23 486.81 11.20 30.42 Random Sequential Random Read 31.06 Read Write 497.02 481.64 30.10 Random IOPS MB/sec Write Read Write 2332.43 3489.93 2140.70 3529.15 145.77 218.12 133.79 220.57 9
- 10. 調理方法 • 5 分 / 1GB のログ書き込み – 最大 5,000 Batch / sec (平均 2,200) – 最大 1,500 Transaction / sec (平均 360) • これを以下のパターンで実施するとどうなるか…。 – データディスク 8 (キャッシュなし) / ログディスク 8 – データディスク 4 (読み取りキャッシュあり) / ログディスク 12 – データディスク 15 (キャッシュなし) / ログディスク 1 すみません!! 時間がなくてうまく説明できるデータが取れませんでした m(_ _)m 10
- 11. 結果 その 1 ログ書き込みとディスク読み込みの待ちの比較 誤差の範囲 wait_time_ms wait_time_ms wait_time_ms ① ② ③ WRITELOG PAGEIOLATCH_SH ①データディスク 8 (キャッシュなし) / ログディスク 8 ②データディスク 4 (読み取りキャッシュあり) / ログディスク 12 ③データディスク 15 (キャッシュなし) / ログディスク 1 11
- 12. 結果 その 2 バッチ実行数の比較 同じぐらい さばけている ① ② ③ ※ 負荷かけ端末の性能には余裕があります。 ①データディスク 8 (キャッシュなし) / ログディスク 8 ②データディスク 4 (読み取りキャッシュあり) / ログディスク 12 ③データディスク 15 (キャッシュなし) / ログディスク 1 12
- 13. 原因 • (たぶん) データの母数が少なくて排他ロックが邪魔をして、I/O が伸びない – データをリストアする時間の関係で 20GB のデータしか作れませんでした (20GB の DB をリストアするのに 1 時間ぐらいかかるので。) 1,000 ユーザー / データファイル × 15 / ログファイル × 1 WRITELOG 5,108,787 261,600,685 1,226 39,596,268 LCK_M_X 460,560 95,709,946 30,888 PAGEIOLATCH_SH 346,570 60,003,573 7,951 1,000 ユーザー / データファイル × 1 / ログファイル × 15 WRITELOG LCK_M_X PAGEIOLATCH_SH 5,124,585 230,800,427 471,690 110,697,068 346,988 50,147,703 577,271 78,556 2,830 31,392,317 84,686 550,808 35,920 79,740 13
- 14. おいしく食べるには • 適切なディスク I/O をかけられるようにする – 今回の場合はデータの母数が少なくて排他ロックの競合が影響 して、うまく更新がかかれられていませんでしたが…。 – 複数のディスクをストライピングして効率の良いディスクアク セスを。 うまいデータが取れなかったので説得力ないですよね…。 14
- 15. 最後に今回の予算 17,000 – 13,486 = 3,514 小出しにシャットダウンしたり、 サイズを XL に変更して作業したり する低予算で和牛を食べることが できます!! 15