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

小澤真之 (@Masayuki_Ozawa)

このスライドはこちらから→ http://sdrv.ms/17IJSHj

自己紹介

• SQL Server を全力でぶん回すのが好きな DB 屋さんです。

• ブログ : SE の雑記

– http://engineermemo.wordpress.com

• Twitter : @Masayuki_Ozawa

• Facebook : Masayuki.Ozawa

2

みんな大好き和牛！！

• 和牛 = A6 や A7 サイズのメモリ集中型インスタンス

3

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

※元の画像 : https://twitter.com/naoto_matsumoto/status/372270113279311873/photo/1

• 調理中にお手紙をいただきました

調理の際には気を付けましょう

4

たしかに、VHD を 2 回ぐらいアップロードしました…。

和牛の基本スペック

※ 以前は、XL (800Mbps) と A7 (2,000 Mbps) のネットワーク帯域も違ったはずなのですが今の公開情報からは消えていました。

5

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

• XL と A7 は 2 NUMA ノードの構成– CPU

• 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 にスケールアップするのが課金的におすすめ

ちなみに NUMA なのでこんな情報とれます

6

レシピ

• Azure VM で SQL Server を実行する際の参考情報は以下に公開されています

– Performance Guidance for SQL Server in Windows Azure Virtual

Machineshttp://msdn.microsoft.com/en-us/library/windowsazure/dn248436.aspx

7

調理のポイント

• ディスクの構成に注意!!– 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 tabhttp://social.technet.microsoft.com/Forums/windowsserver/en-US/13a7b824-40e8-4c6d-b5a1-52bc9de9c9d3/physical-disks-showing-up-in-disks-in-storage-but-not-in-primordial-pool-on-the-storage-pools-tab

8

ディスクの性能 (SQLIO)

• 500 IOPS = キャッシュ無効時のディスク性能

9

ディスク × 1

8KB

Sequential Random

Read Write Read Write

IOPS 497.03 491.73 496.70 494.75

MB/sec 3.88 3.84 3.88 3.86

64KB

Sequential Random

Read Write Read Write

IOPS 179.23 486.81 497.02 481.64

MB/sec 11.20 30.42 31.06 30.10

ディスク × 16

8KB

Sequential Random

Read Write Read Write

IOPS 7939.17 5041.05 7864.28 4603.51

MB/sec 62.02 35.45 61.43 35.96

64KB

Sequential Random

Read Write Read Write

IOPS 2332.43 3489.93 2140.70 3529.15

MB/sec 145.77 218.12 133.79 220.57

16 倍

調理方法

• 5 分 / 1GB のログ書き込み– 最大 5,000 Batch / sec (平均 2,200)

– 最大 1,500 Transaction / sec (平均 360)

• これを以下のパターンで実施するとどうなるか…。– データディスク 8 (キャッシュなし) / ログディスク 8

– データディスク 4 (読み取りキャッシュあり) / ログディスク 12

– データディスク 15 (キャッシュなし) / ログディスク 1

10

すみません!!時間がなくてうまく説明できるデータが取れませんでした

m(_ _)m

結果その 1

11

①データディスク 8 (キャッシュなし) / ログディスク 8

②データディスク 4 (読み取りキャッシュあり) / ログディスク 12

③データディスク 15 (キャッシュなし) / ログディスク 1

wait_time_ms wait_time_ms wait_time_ms

① ② ③

ログ書き込みとディスク読み込みの待ちの比較

WRITELOG PAGEIOLATCH_SH

誤差の範囲

結果その 2

12

バッチ実行数の比較

① ② ③

①データディスク 8 (キャッシュなし) / ログディスク 8

②データディスク 4 (読み取りキャッシュあり) / ログディスク 12

③データディスク 15 (キャッシュなし) / ログディスク 1

※ 負荷かけ端末の性能には余裕があります。

同じぐらいさばけている

原因

• (たぶん) データの母数が少なくて排他ロックが邪魔をして、I/O が伸びない– データをリストアする時間の関係で 20GB のデータしか作れませんでした

(20GB の DB をリストアするのに 1 時間ぐらいかかるので。)

13

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 577,271

PAGEIOLATCH_SH 346,570 60,003,573 7,951 78,556

1,000 ユーザー / データファイル × 1 / ログファイル × 15

WRITELOG 5,124,585 230,800,427 2,830 31,392,317

LCK_M_X 471,690 110,697,068 84,686 550,808

PAGEIOLATCH_SH 346,988 50,147,703 35,920 79,740

おいしく食べるには

• 適切なディスク I/O をかけられるようにする

–今回の場合はデータの母数が少なくて排他ロックの競合が影響して、うまく更新がかかれられていませんでしたが…。

–複数のディスクをストライピングして効率の良いディスクアクセスを。

14

うまいデータが取れなかったので説得力ないですよね…。

最後に今回の予算

15

17,000 – 13,486 = 3,514

小出しにシャットダウンしたり、サイズを XL に変更して作業したりする低予算で和牛を食べることができます!!