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.
和牛をおいしく食べるには
小澤 真之 (@Masayuki_Ozawa)

このスライドはこちらから→ http://sdrv.ms/17IJSHj
自己紹介
• SQL Server を全力でぶん回すのが
好きな DB 屋さんです。
• ブログ : SE の雑記
– http://engineermemo.wordpress.com

• Twitter : @Masayuki_Ozawa...
みんな大好き和牛!!
• 和牛 = A6 や A7 サイズのメモリ集中型インスタンス

ここのおいしい
調理方法って??

※元の画像 : https://twitter.com/naoto_matsumoto/status/372270113...
調理の際には気を付けましょう
• 調理中にお手紙をいただきました

たしかに、VHD を 2 回ぐらいアップロードしました…。
4
和牛の基本スペック
• XL と A7 は 2 NUMA ノードの
構成
– CPU

XL と A7 でメモリ以外の
スペックは同等

• 1 NUMA ノード : 4 コア
• Max Worker Count(Thread) : 576
...
ちなみに NUMA なのでこんな情報とれます

6
レシピ
• Azure VM で SQL Server を実行する際の参考情報は以下
に公開されています
– Performance Guidance for SQL Server in Windows Azure Virtual
Machin...
調理のポイント
• ディスクの構成に注意!!

– SQL Server では Write Cache は無効
– Read Cache が有効なデータディスクは最大で 4 本まで (OS のディスクを含めると 5 本)

– ジオレプリケーシ...
ディスクの性能 (SQLIO)
• 500 IOPS = キャッシュ無効時のディスク性能
ディスク × 1

ディスク × 16

8KB

8KB

Sequential
Read
IOPS
MB/sec

Write

497.03 491...
調理方法
• 5 分 / 1GB のログ書き込み
– 最大 5,000 Batch / sec (平均 2,200)
– 最大 1,500 Transaction / sec (平均 360)

• これを以下のパターンで実施するとどうなるか…...
結果 その 1
ログ書き込みとディスク読み込みの待ちの比較

誤差の範囲

wait_time_ms

wait_time_ms

wait_time_ms

①

②

③

WRITELOG

PAGEIOLATCH_SH

①データディス...
結果 その 2
バッチ実行数の比較

同じぐらい
さばけている

①

②

③

※ 負荷かけ端末の性能には余裕があります。
①データディスク 8 (キャッシュなし) / ログディスク 8
②データディスク 4 (読み取りキャッシュあり) /...
原因
• (たぶん) データの母数が少なくて排他ロックが邪魔をして、I/O が伸びない
– データをリストアする時間の関係で 20GB のデータしか作れませんでした
(20GB の DB をリストアするのに 1 時間ぐらいかかるので。)

1,...
おいしく食べるには
• 適切なディスク I/O をかけられるようにする
– 今回の場合はデータの母数が少なくて排他ロックの競合が影響
して、うまく更新がかかれられていませんでしたが…。
– 複数のディスクをストライピングして効率の良いディスクア...
最後に今回の予算
17,000 – 13,486 = 3,514
小出しにシャットダウンしたり、
サイズを XL に変更して作業したり
する低予算で和牛を食べることが
できます!!

15
Upcoming SlideShare
Loading in …5
×

和牛をおいしく食べるには

728 views

Published on

  • Be the first to comment

  • Be the first to like this

和牛をおいしく食べるには

  1. 1. 和牛をおいしく食べるには 小澤 真之 (@Masayuki_Ozawa) このスライドはこちらから→ http://sdrv.ms/17IJSHj
  2. 2. 自己紹介 • SQL Server を全力でぶん回すのが 好きな DB 屋さんです。 • ブログ : SE の雑記 – http://engineermemo.wordpress.com • Twitter : @Masayuki_Ozawa • Facebook : Masayuki.Ozawa 2
  3. 3. みんな大好き和牛!! • 和牛 = A6 や A7 サイズのメモリ集中型インスタンス ここのおいしい 調理方法って?? ※元の画像 : https://twitter.com/naoto_matsumoto/status/372270113279311873/photo/1 3
  4. 4. 調理の際には気を付けましょう • 調理中にお手紙をいただきました たしかに、VHD を 2 回ぐらいアップロードしました…。 4
  5. 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
  6. 6. ちなみに NUMA なのでこんな情報とれます 6
  7. 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. 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. 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. 10. 調理方法 • 5 分 / 1GB のログ書き込み – 最大 5,000 Batch / sec (平均 2,200) – 最大 1,500 Transaction / sec (平均 360) • これを以下のパターンで実施するとどうなるか…。 – データディスク 8 (キャッシュなし) / ログディスク 8 – データディスク 4 (読み取りキャッシュあり) / ログディスク 12 – データディスク 15 (キャッシュなし) / ログディスク 1 すみません!! 時間がなくてうまく説明できるデータが取れませんでした m(_ _)m 10
  11. 11. 結果 その 1 ログ書き込みとディスク読み込みの待ちの比較 誤差の範囲 wait_time_ms wait_time_ms wait_time_ms ① ② ③ WRITELOG PAGEIOLATCH_SH ①データディスク 8 (キャッシュなし) / ログディスク 8 ②データディスク 4 (読み取りキャッシュあり) / ログディスク 12 ③データディスク 15 (キャッシュなし) / ログディスク 1 11
  12. 12. 結果 その 2 バッチ実行数の比較 同じぐらい さばけている ① ② ③ ※ 負荷かけ端末の性能には余裕があります。 ①データディスク 8 (キャッシュなし) / ログディスク 8 ②データディスク 4 (読み取りキャッシュあり) / ログディスク 12 ③データディスク 15 (キャッシュなし) / ログディスク 1 12
  13. 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. 14. おいしく食べるには • 適切なディスク I/O をかけられるようにする – 今回の場合はデータの母数が少なくて排他ロックの競合が影響 して、うまく更新がかかれられていませんでしたが…。 – 複数のディスクをストライピングして効率の良いディスクアク セスを。 うまいデータが取れなかったので説得力ないですよね…。 14
  15. 15. 最後に今回の予算 17,000 – 13,486 = 3,514 小出しにシャットダウンしたり、 サイズを XL に変更して作業したり する低予算で和牛を食べることが できます!! 15

×