SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Author Archive

ETG2-SHV16N のアグリゲーションを試してみる

leave a comment

私の検証環境は、ETG2-SHV16N という L2 スイッチングハブを使っています。
このスイッチングハブですが、サポート対象外ではありますが Aggregation機能 がついています。
image

リンクアグリゲーションができますのでスイッチ間を接続する際に複数のポートを束ねて一つの論理ポートとして扱うことが可能になります。
image

私はネットワーク関係はものすごい疎いので、いろいろと試行錯誤しながらこの辺の事を調べてみました。
# いろいろなところに間違いがあってきっと突っ込みどころ満載な気がしますがご容赦を…。

今回、スイッチ間をリンクアグリゲーションで接続しようとして、以下の環境を作ってみました。image
この環境で、ファイルサーバーから GT110b にファイルをコピーする際にアグリゲーションあり / なしでどのように速度が変わるのかな~というのを検証してみようとしました。

で、この環境にしたところ、CG-SW08GTXB に接続している、GT110b に接続ができなくなりました…。
というより、ETG2-SHV16N に接続しているサーバーにメイン PC から接続ができなくなりました…。
GT110b からインターネットや対向のスイッチに接続しているサーバー / インターネットに接続することもできず。
ネットワークがダウンした状態になりました。

CG-SW08GTXB ですが、リンクアグリゲーション (ポートトランキング) には対応していない普通のギガビットのスイッチングハブになります。
そういうものなのかな~と Twitter でつぶやいたところ、 IEEE 803.ad 規格に対応していないと通信できない、エラーになってポートが落ちるのでと教えていただくことができました。

なるほどと思って、ちょっと IEEE 803.ad を調べていました。

IEEE 803.ad で、LACP (Link Aggregation Control Protocol) というプロトコルが標準化されており、LACP リンクアグリゲーション (動的リンクアグリゲーション) ではこのプロトコルが使用されているようです。
他にも、スタティックリンクアグリゲーション (SLA) というものもあるようですね。

スイッチ間をアグリゲーションを設定したポートで接続する場合はに対向のスイッチでもアグリゲーションに対応していないと通信を行うことができないようですね。

 

家にはネットワーク機器がこれ以上ないので、とりあえず構成を以下のようにしてみました。
image

GT110b の NIC はチーミングをしているのですが、「静的リンクアグリゲーション」として設定をしています。
image

[IEE 802.3ad 動的リンク アグリゲーション] も設定ができるのですが、この設定では内部 / 外部ともに通信ができなくなりました。

 

今回は静的リンクアグリゲーションでチーミングした NIC をアグリゲーションしたポートに接続して速度のどの程度の影響が出るのかを試してみたいと思います。
10GB 程度のファイルをファイルサーバーからコピーしてネットワークの使用状況を確認してみました。
単一 NIC の場合は以下のようなネットワークの使用状況になります。
image

チーミング + アグリゲーションをした環境で取得したデータが以下になります。
# NIC2 は全く使われていないわけではないのですが、低い値を推移しています。
ETG2-SHV16N ではアグリゲーションで xor / smac / dmac の 3 種類の設定があります。
xor だとコピーの最後で送信バイトが瞬間的に上がるのですが、 smac / dmac では平均的な値を示していました。
# smac / dmac ともに似たようなトレンドを示していました。

image
image

チーミングのみ設定した場合はこちら。
NIC が交互に使われていました。
image

ポート側でアグリゲーションをしても効率よく両方の NIC が使われるような設定というのがうまく設定できませんでした…。

ネットワークはよくわかっていないことがたくさんあるのでもっと勉強しないと駄目ですね。

Written by Masayuki.Ozawa

12月 12th, 2010 at 11:01 pm

Posted in Windows Server

Tagged with ,

Exchange 2010 と m-FILTER を使用したメール環境の構築

leave a comment

デジタルアーツ株式会社さんが発売しているソフトで [m-FILTER] というものがあります。
m-FILTER

この m-FILTER ですが、電子メールのフィルタリング / アーカイブ / アンチスパ対策をすることが可能です。
メールサーバーにインストールするのではなく、メールサーバーの上位にリレーとして配置することにより実装する製品となります。
# 30 日間評価版が提供されているため、実際にインストールをして検証することも可能です。

メールリレーとして配置すれば動作しますので、Exchange Server 2010 とも連携することが可能です。
リレーとして配置する製品なので、単純に考えると、構成は以下のようになると思いますよね。
image

評価環境を作成してみましたので、m-FILTER について簡単に検証してました。
今回は Windows Server 2008 R2 上にインストールを行っています。
m-FILTER は 32bit アプリケーションのため、Windows Server 2008 R2 では WOW64 での動作となります。
image

m-FILTER ですが、インストールはとても簡単でセットアップを実行しシリアル番号をいれてユーザー登録をするだけで使用できるのですが、ユーザー登録時にインターネットへの接続できる必要がありますので注意が必要です。
image

■m-FILTER のデフォルトの SMTP ポート

m-FILTER のデフォルトの SMTP ポートですが、 [14025] で設定がされています。
# 勘の良い方だとこの時点で、「上の構成図で問題ないの?」と思われるかもしれないですね。
image

Exchange の送信コネクタはデフォルトではポート [25] を使用して、スマートホスト (上位メールサーバー) に接続を行います。
そのため、Exchange からメールを送るためには m-FILTER のポートを変更するか送信コネクタがスマートホストに接続をする際に使用するポートを変更する必要があります。

EMC (Exchange Management Console) では、スマートホストに接続する際のポートは変更できません。
image

スマートホストに接続する際のポート番号は、EMS (Exchange Management Shell) で [Get-SendConnector] を実行することで確認することが可能です。

PS>Get-SendConnector -Identity "Internet" | fl

AddressSpaces                : {SMTP:*;1}
AuthenticationCredential     :
Comment                      :
ConnectedDomains             : {}
ConnectionInactivityTimeOut  : 00:10:00
DNSRoutingEnabled            : False
DomainSecureEnabled          : False
Enabled                      : True
ForceHELO                    : False
Fqdn                         :
HomeMTA                      : Microsoft MTA
HomeMtaServerId              : EX-2010
Identity                     : Internet
IgnoreSTARTTLS               : False
IsScopedConnector            : False
IsSmtpConnector              : True
LinkedReceiveConnector       :
MaxMessageSize               : 10 MB (10,485,760 bytes)
Name                         : Internet
Port                         : 25
ProtocolLoggingLevel         : None
RequireTLS                   : False
SmartHostAuthMechanism       : None
SmartHosts                   : {[xxx.xxx.xxx.xxx]}
SmartHostsString             : [xxx.xxx.xxx.xxx]
SmtpMaxMessagesPerConnection : 20
SourceIPAddress              : 0.0.0.0
SourceRoutingGroup           : Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers       : {EX-2010}
UseExternalDNSServersEnabled : False

Port は [25] になっていることが確認できますね。

変更するためには、[Set-SendConnector] を使用します。

Get-SendConnector -Identity "Internet" | Set-SendConnector -Port 14025

変更後に再度、確認をしてみます。

PS>Get-SendConnector -Identity "Internet" | fl

AddressSpaces                : {SMTP:*;1}
AuthenticationCredential     :
Comment                      :
ConnectedDomains             : {}
ConnectionInactivityTimeOut  : 00:10:00
DNSRoutingEnabled            : False
DomainSecureEnabled          : False
Enabled                      : True
ForceHELO                    : False
Fqdn                         :
HomeMTA                      : Microsoft MTA
HomeMtaServerId              : EX-2010
Identity                     : Internet
IgnoreSTARTTLS               : False
IsScopedConnector            : False
IsSmtpConnector              : True
LinkedReceiveConnector       :
MaxMessageSize               : 10 MB (10,485,760 bytes)
Name                         : Internet
Port                         : 14025
ProtocolLoggingLevel         : None
RequireTLS                   : False
SmartHostAuthMechanism       : None
SmartHosts                   : {[xxx.xxx.xxx.xxx]}
SmartHostsString             : [xxx.xxx.xxx.xxx]
SmtpMaxMessagesPerConnection : 20
SourceIPAddress              : 0.0.0.0
SourceRoutingGroup           : Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers       : {EX-2010}
UseExternalDNSServersEnabled : False

これで、Exchange から、m-FILTER の 14025 のポートを使用してメールを送信する設定ができました。

インストール直後の状態では、m-FILTER サーバーのファイアウォールで 14025 はブロックされていますので、m-FILTER サーバーに Inboud のルールを追加します。

netsh advfirewall firewall add rule name="m-FILTER SMTP" dir=in protocol=tcp localport=14025 action=allow

これで、Exchange ? m-FILTER 間で接続することが可能となります。
この状態で Telnet で m-FILTER に接続をして Exchange 2010 にメールを送ろうとすると、[541 Relay prohibition] となり、メールを送信することはできません。

m-FILTER から Exchange 2010 にメールを送信する経路を作成するためには、m-FILTER の管理コンソールから [メール送信サーバー] の設定を行う必要があります。

■メール送信サーバーの設定

m-FILTER からのメールを Exchange 2010 に送るための経路設定を行います。
m-FILTER の設定はすべて Web ベースの管理コンソールから行います。
image

[オプション] → [メール送信サーバー] からメールの経路設定を行います。
ドメイン名単位でメールのリレーサーバーを決定することができます。

今回は、自ドメインのメールは Exchange 2010 にリレーする必要がありますので、以下のような設定を追加します。
# ドメイン名とアドレスは Exchange で使用するドメインとハブトランスポートの IP アドレスを設定します。
image

この設定をすることで、m-FILTER で受け取ったメールを Exchange 2010 にリレーすることが可能となります。

あとは、Exchange 2010 からのメールはオープンリレーとして許可するように設定するために、[オプション] → [オープンリレー許可] の設定も行っておきます。
# ここに Exchange 2010 の IP アドレスを設定しておくことで、Exchange 2010 からのメールはオープンリレーとして許可されます。(外部にメールが送れます)
image

この状態では外部にメールを送る設定はできていません。
外部にメールを送るためにはドメインを [*] にした設定を追加する必要があります。

 

■外部メール送信用の設定

続いて外部メール送信用の設定を行います。
外部メールなのでドメイン名は [*] で設定を行います。
外部サーバーを標準のリレーサーバーとしても設定しておきます。(設定しなくても大丈夫かもしれませんが。)
image

この設定で、DNS の MX レコードを使用して外部にメールを送信してくれればよいのですが、
image

アドレスとポート番号は必須なのですよね…。
試しに自分自身の SMTP ポートを使用して外部にメールを送信するように設定してみます。
image

自分自身 (127.0.0.1) についてもオープンリレーを許可して外部にメールを送信してみます。
下の画像は SMTP のアクセスログなのですが、自分自身に対してメールを送信しているのをリレーしますので、メールループが発生していますね…。
image
この設定ではメールの経路はこのようになってしまっています。
image
そのため、外部へのメールを自分自身に送信し続けてしまっています。

m-FILTER を使用する際には上位に MTA をはさむ必要があります。

そのため、構成としては以下のようになります。image

■IIS の SMTP サービスを使用して MTA にする

m-FILTER からは直接外部にメールを送信することはできないため、外部にメールを送信 (受信) するための MTA を準備する必要があります。
Exchange 2010 に m-FILTER をインストールすることで、一台型で構成することも可能なのですが、今回は m-FILTER サーバーに IIS の SMTP サービスをインストールして MTA にしてしまいたいと思います。
# Edge Transport でも可能ですね。

機能の追加で [SMTP サーバー] をインストールすることで、IIS に含まれている SMTP サービスの機能を使用することが可能になります。
image

SMTP サーバーをインストールすると、インストールしたタイミングで TCP 25 の受信規則が設定されますので、ファイアウォールを手動で設定する必要はありません。
SMTP サーバーのインストールが終了したら、外部ドメインへの送信に使用するポートを [25] に変更します。
image

デフォルトの設定では外部にメールを送信しようとすると、[530 5.7.1 Client was not authenticated ] となります。

外部にリレーををするためには、[中継の制限] の設定を変更する必要があります。

中継の制限の設定を変更するためには、IIS の管理コンソールを開いて [SMTP Virtual Server #1] のプロパティを開きます。
image

[アクセス] タブに、[中継] ボタンがありこのボタンを押して、[127.0.0.1] からメールを中継できるように設定します。
image

これで、m-FILTER を経由してメールを送ることが可能となります。

 

■m-FILTER 経由でメールを受信

ここまでで送信はできるようになりましたが、受信に関してはまだ設定をする必要があります。
まずは、SMTP サービスで受信したメールを m-FILTER (14025) に転送する必要があります。
[SMTP VIrtual Server] のプロパティを開いて、[配信] タブをクリックします。
image

[送信先接続] をクリックすると、送信時の TCP ポートを選択することができます。
ここで、[14025] を設定します。
image

あとは [詳細設定] をクリックして、スマートホストとして [127.0.0.1] を設定します。
# [] は必須です。
image

この状態だけでは、550 のエラーとなりメールをリレーすることはできません。
メールをリレーするためには、リモートドメインを設定する必要があります。
ドメインを右クリックして、[新規作成] → [ドメイン] からリモートドメインを作成することができます。
image

[リモート] を選択して、
image

ドメイン名を入力します。
image

作成したリモートドメインをダブルクリックして、[このドメインへ受信メールを中継する] を有効にして、スマートホストとして [127.0.0.1] を設定します。
image

これで m-FILTER にメールをリレーすることが可能となります。
ただし、この状態では [530 5.7.1 Client was not authenticated] となりメールを送信することができません。
Exchange 2010 の TCP 25 の受信コネクタのデフォルトの設定では、[匿名ユーザー] による接続が許可されていません。

m-FILTER から Exchange 2010 に接続する際には、匿名ユーザーで接続がされますので、受信コネクタの許可グループで [匿名ユーザー] の接続を許可します。
image

以上で、m-FILTER と Exchange の連携は完了です。

ただし、この設定ですと、外部のメール送信にも 14025 を使ってしまうので、受信の設定をしてしまうと外部に送信ができなくなってしまうのですよね…。

Exchange の Edge トランスポートを使うと結構簡単に設定ができるのですが、IIS の SMTP だと受信も送信も行うのは難しいのかもしれないですね。

ちょっと中途半端な投稿になってしまいましたが、ここまでで調べられた内容を投稿してみました。

Written by Masayuki.Ozawa

12月 12th, 2010 at 12:14 am

Posted in Exchange

Tagged with ,

SQL Server で WOW64 その 2

one comment

前回の投稿でパフォーマンスモニタのログが取得できるようになりましたので、WOW64 のメモリの使用状況を確認していきたいと思います。

WOW64 を使用していない環境 (32bit 環境) では SQL Server のメモリ使用状況は以下のようになります。

■/3GB なし
image

■/3GB あり
image

/3GB なしで 1.6GB ,/3GB ありで 2.6GB のメモリが使用できています。

 

それでは、WOW64 で動作している SQL Server 2008 R2 / Denali で同様の情報を取得してみます。

■SQL Server 2008 R2
image

■Denali
image

WOW64 のアプリケーションの場合、ユーザーモードの領域は 4GB 使用することができます。
そのため、32bit の SQL Server ではありますが、2GB 以上のメモリを使用することが可能です。
# 64bit の OS のため、/3GB スイッチも設定はないですし。

SQL Server 2008 R2 と Denali の WOW64 のメモリ使用状況を比較すると、プランキャッシュの上限に少し差が出ているようでした。
SQL Server 2008 R2 では、プランキャッシュが 1.5GB 程確保できているのですが、Denali では、1GB で頭打ちとなっています。
データとプランで使用しているメモリ合計については両バージョン共に 3.5GB となっているので、WOW64 で使用できるメモリの上限は共に同じになっていることが確認できます。
# 32bit / 64bit 共に、ユーザーモードのメモリ空間をフルには使えないみたいですね。32bit の場合は、1.6GB ぐらいで頭打ちになりますし。この辺はどうしてこのようになるのかをきちんと勉強したいと思います。

参考ではありますが、WOW64 を使用した場合のメモリについては以下の技術情報に記載がされています。
メモリ アーキテクチャ

 

WOW64 で AWE を有効にした場合どうなるかも合わせて試してみました。

■SQL Server 2008 R2 (AWE)
image

■Denali (AWE)
image

WOW64 + AWE を使用すると、4GB をフルに使用することができていますね。
# WOW64 + AWE で動作させても変わらないんだろうな~と思っていたので、ちょっと意外でした。
ただし、AWE を使用しても 4GB 以上のメモリを使用することはできていません。
また、AWE を使用することで、設定前と比較して400MB 程度使用可能なメモリが増えているのですが、この増加分はデータベースキャッシュに割り当てられており、プランキャッシュに関しては、1.5GB から変化していません。
このあたりの動きは通常の AWE と同様になるようですね。

現状、Denali では、AWE はサポートしていませんので、AWE を有効にしてもメモリのトレンドは変わりません。

AWE と WOW64 について、数回に分けて投稿してきましたがその検証で取得した値を表にしてみました。
# 数値は SQL Server 2008 R2 のものとなっており、() 内は Denali の値になります。

  データベースキャッシュ(最大) プランキャッシュ (最大) 利用メモリ (メモリ6 GB 搭載時)
/3GB なし 1.0 GB (1.0 GB) 900 MB (700 MB) 1.6 GB (1.5GB)
/3GB あり 1.5 GB (1.5 GB) 1.5 GB (1.2GB) 2.6 GB (2.5 GB)
AWE 4.1 GB (1.0 GB) 850 MB (700 MB) 4.2 GB (1.5GB)
AWE + /3GB 4.0 GB (1.5 GB) 1.4 GB (1.2GB) 4.1 GB (2.5 GB)
WOW64 3.0 GB (3.0 GB) 1.6 GB (1.0 GB) 3.5 GB (3.5 GB)
WOW64 + /3GB 4.0 GB  (3.0 GB) 1.6 GB(1.0 GB) 4.0 GB (3.5 GB)

# これらの値はあくまでも参考値ですので、環境によって変化します。

SQL Server のエンジニアの端くれなので、診断で環境を見たことはあるのですが自分でデータをとってまとめるという機会がなかったので、今回の投稿はよい機会でした~。

Written by Masayuki.Ozawa

12月 11th, 2010 at 2:37 pm

Posted in SQL Server

Tagged with , ,

SQL Server で WOW64 その 1

leave a comment

SQL Server を WOW64 で動かした時のメモリの使用状況について少しまとめていきたいと思います。
パフォーマンス モニタでメモリの情報を取得しようとして結構はまったので、その 1 として WOW64 で SQL Server を実行した場合の情報取得につて書いていきたいと思います。
64bit OS では SQL Server を WOW64 (Windows 32-bit on Windows 64-bit) でインストールすることが可能です。
64bit OS で SQL Server をインストールしようとすると通常は 64bit の SQL Server がインストールされます。
インストール時に [Options] から [Processor Type] を [x86] に設定することで WOW64 で SQL Server をインストールすることができます。
image
WOW64 の SQL Server のインストールではインストールする機能の選択画面では、両方の [Program Files] が表示されますが、
image
データベースのルートディレクトリの選択では、[Instance root directory] が [Program Files (x86)] に設定がされます。
image
後のインストールは x64 の SQL Server と同じです。
タスクマネージャーを確認すると [*32] となっていますので、WOW64 で実行されているのが確認できます。
image
それではパフォーマンスモニタでメモリの情報を取得してみたいと思います。
image
MSSQL~ のカウンターが無いですね…。
Process では、[sqlservr.exe] の情報を取得することが可能なのですが。
image
WOW64 の SQL Server の場合は、32bit のパフォーマンスモニタを起動して情報を取得します。
32bit のパフォーマンスモニタを起動するためには、[C:WindowsSysWOW64perfmon.exe] を実行します。
# [mmc /32 perfmon.msc] でも起動することが可能です。
32bit のパフォーマンスモニタを起動すると SQL Server のカウンターを取得することができます。
image
それでは、WOW64 上の SQL Server のメモリ情報を取得してみたいと思います。
まずは SQL Server 2008 R2 で試してみました。
image
取得したログに SQL Server のカウンターが無いですね…。
ログの取得対象として SQL Server のカウンターは設定されています。
image
[Relog] コマンドを使って、取得したパフォーマンスモニタのログからカウンターを取得してみたいと思います。
Relog コマンドには [-q] オプションがあり、このオプションを使用するとログに含まれるカウンターの情報を取得することが可能です。

>relog c:PerfLogsAdminPerformanceWIN-KLC3RJ46I7R_20101208-000007DataCollector01.blg -q
入力
—————-
ファイル:
???? c:PerfLogsAdminPerformanceWIN-KLC3RJ46I7R_20101208-000007DataCollector
01.blg (バイナリ)
開始:?????????? 2010/12/8 7:48:09
終了:?????????? 2010/12/8 7:52:24
サンプル:?????? 251
\WIN-KLC3RJ46I7RMemoryAvailable KBytes
コマンドは、正しく完了しました。

ログから追加できるカウンターに表示されていないという事ではなく、ログ自体に含まれていない (取得されていない) ことが確認できます。
WOW64 のパフォーマンスモニタのログ取得について調べていたところ、SQL Server でとても参考になるサイトが二つ見つかりました。
SQL Server Wow64 Perfmon Issues
How It Works: Almost Everything You Wanted To Know About The SQL Server (2005, 2008) Performance Counter Collection Components
最初のブログは WIndows Server 2003 がベースとなっています。
Performance Log and Alerts のサービスで使用する exe を レジストリを変更してWOW64 のものに差し替えて取得するという方法が紹介されています。
image
image
2008 以降はパフォーマンスモニタのサービスは [svchost.exe] 経由になっているのですが、これを [SysWow64] のものにすれば取得できるというわけでもないので残念ながらこの方法では取得できず…。
image
2 つめのサイトでは 64bit の SQL Server のカウンターのライブラリ DLL を [system32] にコピーするという方法が紹介されています。
SQL Server のパフォーマンスモニタのカウンターですがサービス毎に、ライブラリの DLL が個別に設定されています。
# 使用している DLL 名は HKLM のサービスのレジストリの [Library] から確認することができます。
image
同一バージョンの 64bit の SQL Server から、カウンターのライブラリ DLL をコピーし、ファイル名を上記で確認した DLL 名と同一にして、[C:WindowsSystem32] にコピーをして再度ログの取得を試してみました。
image

>relog c:PerfLogsAdminPerformanceWIN-KLC3RJ46I7R_20101209-000009DataCollector01.blg -q
入力
—————-
ファイル:
???? c:PerfLogsAdminPerformanceWIN-KLC3RJ46I7R_20101209-000009DataCollector
01.blg (バイナリ)
開始:?????????? 2010/12/9 22:28:06
終了:?????????? 2010/12/9 22:28:44
サンプル:?????? 39
\WIN-KLC3RJ46I7RMSSQL$DENALIX86:Plan Cache(_Total)Cache Pages
\WIN-KLC3RJ46I7RMSSQL$DENALIX86:Buffer ManagerDatabase pages
\WIN-KLC3RJ46I7RMSSQL$SQL2008R2X86:Plan Cache(_Total)Cache Pages
\WIN-KLC3RJ46I7RMSSQL$SQL2008R2X86:Buffer ManagerDatabase pages
\WIN-KLC3RJ46I7RMemoryAvailable KBytes
コマンドは、正しく完了しました。

?
2008R2 と Denali の情報を取得してみたのですが両方ともログが取れていますね。
パフォーマンスモニタのログも取得できています。
image
この方法でログを取得することができるのですが [非サポート] になるようですので注意が必要です。
非サポートではありますがひとまず、ログの取得はできました。
WOW64 で SQL Server を実行した際のメモリ利用については次の投稿でまとめたいと思います。

Written by Masayuki.Ozawa

12月 8th, 2010 at 12:27 am

Posted in SQL Server

Tagged with ,

あらためて SQL Server と AWE その 6

leave a comment

あらためて SQL Server と AWE の最後の投稿として、AWE を有効にしている場合のメモリ情報の取得についてまとめていきたいと思います。

今まで、DBCC MEMORYSTATUS やパフォーマンスモニタでメモリの情報を取得してきました。
特定のアプリケーションのメモリを取得する際には、タスクマネージャやパフォーマンスモニタの Process でワーキングセットを取得する方法もあるかと思います。

AWE を有効にした状態でタスクマネージャーの [sqlserver.exe] のプライベートワーキングセットを確認してみます。
image

92 MB となっていますね。
パフォーマンスモニタで [sqlserver.exe] の [Working Set] を確認してみます。
image

平均が [116,969,472] Byte となっています。

DBCC MEMORYSTATUS で SQL Server から使用しているメモリを確認してみます。
image
AWE Allocated は [4,235,376] KB となっていますので、4GB 程度のメモリが使用されています。

AWE が有効になっている環境でのメモリ取得に関して、技術文書に以下の記載があります。
SQL Server での AWE メモリの有効化

SQL Server のパフォーマンス モニターの Total Server Memory (KB) カウンターを使用して、AWE モードで実行されている SQL Server のインスタンスによって割り当てられたメモリ量を特定するか、sysperfinfo からメモリの使用量を選択します。

AWE を有効にしている場合はプロセスからではなく、SQL Server のパフォーマンスモニタから情報を取得します。

SQL Server が使用しているメモリの合計は、

  • Buffer ManagerTotal pages
  • Memory ManagerTotal Server Memry (KB)

の何れかで取得することが可能です。

以下の画像が情報を取得したものになります。

image

Total pages は 8KB ページの数が表示されますので、サイズにするためには
540,672 ページ × 8KB = 4,325,376 KB となります。

Total Server Memory (KB) に関しては KB 表示そのままですね。
両方とも同じ値となりますのでどちらから値を取得しても問題はありません。

SQL Server の現状を見るときには基本的に SQL Server 用のカウンタから追っていくことになります。
現状のメモリ使用状況だけを軽く見たいといった時でも SQL Server のカウンタを使うことで正確な値を取得することができます。

 

6 回に分けて AWE についてまとめてみました。
64bit 化が進んでいる中で、32bit の SQL Server を使用する機会はそれほどないかとは思いますが、SQL Server のメモリの使用状況を勉強するということではいい機会だったと思います。

次の投稿では WOW64 の SQL Server についてまとめてみたいと思います。

Written by Masayuki.Ozawa

12月 5th, 2010 at 8:08 pm

Posted in SQL Server

Tagged with ,

あらためて SQL Server と AWE その 5

leave a comment

今回は Denali の AWE についてまとめていきたいと思います。

32bit の Denali でも AWE を設定することができます。
image

DBCC MEMORYSTATUS で Memory Manager を確認すると AWE Allocated によるメモリ割り当てがされていることが確認できます。
image

それでは、どれくらいのメモリが割り当てられるかを試してみたいと思います。
# /3GB スイッチは無効にしてあります。
image

このグラフの情報は AWE を有効にしている状態で取得をしているのですが、メモリが 1.4GB 程度で頭打ちになっています。

AWE について SQL Server 2008 R2 の BOL で確認をしてみました。
awe enabled オプション

この機能は、Microsoft SQL Server の次のバージョンで削除されます。
新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションはできるだけ早く修正してください

 

SQL Server 2008 R2 の段階で、AWE は次バージョンで削除されることになっています。
# SQL Server 2008 ではこの記載はありませんでしたので、2008 R2 になって明記されたものになります。

SQL Server で実行されているクエリのトレースを取得できるツール、SQL Server Prolifer には [Deprecation] というイベント カテゴリが用意されており、このカテゴリに含まれるイベント クラスを取得すると実行されている SQL が次バージョンでサポートされるかを確認することができます。
Deprecation イベント カテゴリ

それでは、SQL Server 2008 R2 で [awe enabled] を有効にするクエリを実行してイベントを取得してみたいと思います。
image
[sp_configure] で [awe enabled] を設定しようとすると、[Deprecation Announcement] イベントが発生しているのが確認できます。
メッセージンは以下の内容が表示されています。

sp_configure ‘awe enabled’ は、今後のバージョンの SQL Server では削除される予定です。
新しい開発作業ではこの機能の使用を避け、現在この機能を使用しているアプリケーションでは変更を検討してください。

SQL Server Plofiler からも、[awe enabled] に関しては削除対象となっていることが確認できます。

それでは、Denali で [awe enabled] を設定するとイベントが発生するかを確認してみたいと思います。
image

sp_configure ‘awe enabled’ will be removed in a future version of SQL Server.
Avoid using this feature in new development work, and plan to modify applications that currently use it.

Denali でも 、[Deprecation Announcement] が発生しています。
sp_configure で awe enabled は設定ができているので、構文が使用できるかどうかで見るとこのイベントの発生で正常だと思います。

ただし、メモリが使えるかというと簡単に試したところ、通常のユーザーモードの空間内のメモリしか使えていないようですね…。
/3GB スイッチに関しては想定通りの動きとなり、2GB 以上のメモリ空間の利用が可能となります。

現在は CTP 版なので設定できているのかもしれませんが、SQL Server 2008 R2 の BOL に削除されていると記載されている以上、Denali で AWE が使えると思えるのは危険な気がしますね。

検証した感じでは、32bit の Denali のメモリ割り当ては以下のようになりそうです。image

ここまでの投稿で、メモリの情報を取得しながら AWE の動作を簡単に確認してきました。
次の投稿では、AWE 有効時のメモリの使用状況の取得についてまとめたいと思います。

Written by Masayuki.Ozawa

12月 5th, 2010 at 5:08 pm

Posted in SQL Server

Tagged with , ,

あらためて SQL Server と AWE その 4

leave a comment

前回の投稿で、プランキャッシュの上限について少しまとめてみました。
AWE を有効にしても、プランキャッシュはユーザーモードの中に確保がされますので使用できるメモリは増えません。
image
image

プランキャッシュの上限を増やすためには AWE ではなく、/3GB スイッチを利用します。

/3GB スイッチを使用した場合のプランキャッシュの利用状況は以下のようになります。
image

/3GB スイッチを設定する前は、900 MB 程度だったメモリが、スイッチを設定することにより、1,400 MB 程度まで増加しています。

プランキャッシュですが、Visible ターゲットメモリのサイズに応じて上限が設定されます。
Visible ターゲットメモリは通常のメモリ割り当て (AWE 設定なしで割り当てられるユーザーモード空間) の上限になります。
32bit の場合は 2GB または、3GB が上限となります。

/3GB スイッチを設定しても 3GB のプランキャッシュが設定できるわけではないので注意が必要です。
# いろいろと試してみたのですが、2GB:900 MB / 3GB : 1.4 GB 程度が上限になりそうでしたが、。情報を見ている限りは 75% 取れそうな気もするのですが、これは64bit だけなのかもしれないですね。

/3GB スイッチと AWE を併用した場合のメモリ使用状況はこのようになります。
image

image

/3GB スイッチを設定していない場合と比較すると、プランキャッシュの使用状況が増加していることが確認できます。

/3GB スイッチの注意ですが、このスイッチは 16GB を超えるメモリでは使用することができない点です。
AWE の使用

コンピューターに 16 GB を超える使用可能な物理メモリがある場合、オペレーティング システムで 2 GB の仮想アドレス空間がシステム用に必要になるため、サポートできるユーザー モード仮想アドレス空間は 2 GB だけになります。
オペレーティング システムで 16 GB を超えるメモリ範囲を使用するには、Boot.ini ファイルから /3gb パラメーターを削除する必要があります。
このパラメーターがあると、システムで 16 GB を超える物理メモリを使用できません。

プランキャッシュの上限を考えるとできるだけ 64bit のSQL Server を使用したいところですね。

今回は SQL Server 2008 R2 で検証をしていました。
Denali でも 32bit の SQL Server は引き続き提供されます。

次の投稿では、Denali で AWE を有効にした際の動作をまとめていきたいと思います。

Written by Masayuki.Ozawa

12月 5th, 2010 at 2:09 pm

Posted in SQL Server

Tagged with ,

あらためて SQL Server と AWE その 3

leave a comment

AWE を使用すると AWE によってマッピングされたユーザーモード (2GB) を超える領域はデータキャッシュでしか使用されないということを聞くことがあるかと思います。

今回はデータキャッシュとプラン (クエリ) キャッシュについてまとめていきたいと思います。

AWE を使用すると以下のようにメモリを使用することが可能となります。
image

SQL Server のパフォーマンスモニタでは以下のメモリの情報を取得することが可能です。

以下は Denali で取得できる情報になります。
# SQL Server のバージョンによっては項目が違うのですが、似たような情報は他の項目から取得することができます。

  • Connection Memory
  • Database Cache Memory (Database pages)
  • Free Memory
  • Granted Workspace Memory
  • Lock Memory
  • Optimizer Memory
  • SQL Cache Memory (Cache Pages)

これと上の図をマッチングしてみます。

image

ユーザーモードの領域を超えて割り当てが可能なのは [Database Cache Memory] となります。

それではこのあたりの動きを確認していきたいと思います。
まずはデータベースキャッシュメモリを確認してみます。

今回は SQL Server 2008 R2 の環境を使用しています。
# Denali を使用していないのには理由があるのですが、これは別の機会にまとめる予定です。

■AWE を設定していない状態のデータベースキャッシュメモリの使用状況

まずは AWE を設定していない状態でのデータベースキャッシュメモリの使用状況を確認してみます。
データベースキャッシュメモリはデータをキャッシュするために使用されます。

今回は 17 GB 近いデータが格納されているテーブルを用意しました。

image

このテーブルに対して SELECT を実行して、データベースキャッシュの状態を確認していきたいと思います。
SELECT は SSMS で実行しているのですが、SSMS のプロセスで余計なメモリを消費されないように実行結果はファイルとして出力しています。
# グリッドやテキストで SSMS 上に結果を表示すると SSMS でメモリを消費してしまいますので。

以下のグラフはサーバーの空きメモリとデータベースキャッシュの状態をグラフにしたものです。
image

AWE を有効にしていないため、メモリを最大限使用できていないことが確認できます。

それでは、AWE を有効にして同様のデータを取得してみます。

■AWE を設定しいる状態のデータベースキャッシュメモリの使用状況

AWE を設定している状態では以下のようなメモリ使用状態となります。
image

先ほどと比較して、データベースキャッシュに使用できるサイズが増加していることが確認できます。
AWE が有効に働いていますね。

 

それでは、同様の情報をプランキャッシュでも取得してみたいと思います。

■AWE を設定していない状態のプランキャッシュメモリの使用状況

今回は大量のアドホッククエリを動的に生成して EXEC するクエリを実行して、プランキャッシュにアドホッククエリを大量にキャッシュするようにしてテストをしています。

image

AWE は設定していないので、プランキャッシュとしては 900 MB 程度が上限となっています。

それでは、AWE を設定して情報を取得してみます。

■AWE を設定している状態のプランキャッシュメモリの使用状況

プランキャッシュに関しては AWE の恩恵が受けられない領域となります。
そのため AWE の設定有無によるメモリ使用量の変更はありません。

image

AWE を設定してもプランキャッシュは通常のユーザーモードのメモリ空間の中でしか確保ができませんので、AWEの有効有無による差が発生しません。

最後に AWE を有効にした状態で、データベースキャッシュとプランキャッシュを最大限使われるようにした際の情報を取得してみたいと思います。

データベースキャッシュが増加した後にプランキャッシュを増やすようにしています。
# サーバーのスペック的に両方を同時に増加させようとすると結構時間がかかりそうだったもので。

image

途中からプランキャッシュが増えるようにしていますので、プランキャッシュの増加に合わせてデータベースキャッシュのメモリが減っていります。

AWE を有効にしてもプランキャッシュの上限は変わりません。
プランキャッシュの上限を増やすためには、/3GB スイッチを利用します。

次の投稿では、AWE と /3GB スイッチの併用についてまとめていきたいと思います。

Written by Masayuki.Ozawa

12月 5th, 2010 at 12:55 pm

Posted in SQL Server

Tagged with ,

あらためて SQL Server と AWE その 2

leave a comment

前回の投稿では AWE の設定と設定後の確認について投稿しました。

今回は [動的メモリ] についてまとめていきたいと思います。

SQL Server では [min server memory] と [max server memory] を使用した動的なメモリ割り当てを行うことができます。
この 2 つの値設定することで、SQL Server がどの範囲でメモリを使用するかを指定することができます。
# min server memory はメモリ割り当て後の解放をどの程度まで許容するかの設定で、起動時に確実に確保する設定ではありませんが。

AWE の動的なメモリ割り当てについてですが、以下の技術情報が掲載されています。
SQL Server での AWE メモリの有効化

この中に、以下の記載があります。

Windows 2000 オペレーティング システム上で実行される SQL Server では、AWE マップ メモリの動的割り当てがサポートされていないため、インスタンスごとに max server memory オプションを設定することをお勧めします。

Windows Server 2003 上の SQL Server では、AWE メモリの動的割り当てがサポートされます。

AWE の動的メモリ割り当てに関しては、OS によってサポートの有無が変わってきます。

Windows 2000 Server では動的メモリがサポートされていないため、SQL Server が起動時に可能な限りのメモリを Committed にします。
そのため、[max server memory] を指定することで SQL Server が使用するメモリの条件を設定しておきます。

Windows Server 2003 では動的メモリがサポートされ、SQL Server の起動時には、必要最小限のメモリのみを Committed にして、後は必要に応じて動的にメモリを割り当てます。
動的メモリがサポートされていますので、[min server memory] と [max server memory] を指定しなくても最小限のメモリから必要となるメモリのみを確保していく設定となります。
動的メモリがサポートされていても、サーバー上で稼働しているアプリケーションに影響を及ぼさないように [max server memory] は設定をしていた方が良いとは思います。

書籍によっては、[min server memory] と [max server memory] を同一値に設定して、固定メモリ設定とすると書かれているものがありますので、固定メモリ化するのが良いのかもしれないですね。

 

それでは、AWE の動的メモリ設定についてみていきたいと思います。
今回は SQL Server のバージョンではなく、OS のバージョンによって差が出るということを確認したいため、Windows 2000 Server と Windows Server 2008 上に SQL Server 2005 SP3 の環境を構築しています。
どちらの SQL Server も min server memory = 0 / max server memory =4096 に設定しています。

■Windows 2000 Server の AWE

 

まずは、Windows 2000 Server の AWE 有効時のメモリ割り当てについて見ていきたいと思います。
SQL Server 2005 でも DBCC MEMORYSTATUS は使用できますので AWE Allocated の値を確認してみます。

image

起動直後の状態なのですが、3,326,920 KB のメモリが割り当てられているのが確認できます。
今回の環境ではメモリは 4GB 割り当てています。
# 物理メモリ 4GB に対して、SQL Server の割り当てメモリが 4GB なのでこのような割り当て状況になっています。

この環境では、AWE を使用しても 3GB と少しが SQL Server のメモリ割り当ての上限のようですね。
この状態では、物理メモリを確保していますが SQL Server 上では大半のメモリは [Free Pages] として認識されています。

以下の画像はパフォーマンスモニタで [Buffer ManagerFree Pages] を取得した内容になります。
image

平均して [414,107] ページの空きがあります。
414,107 ページ = 414,107 × 8 KB = 3,312,856 KB
となりますので、メモリを確保していても大半が Free Page として認識されています。

■ Windows Server 2008 の AWE

それでは、Windows Server 2008 の SQL Server 2005 でも同様の確認をしてみたいと思います。

image

Windows Server 2008 の場合は、Windows Server 2003 と同様に動的メモリがサポートされています。
そのため、SQL Server の起動時には必要最小限のメモリのみを確保した状態で起動がされます。

Windows 2000 Server と同様に、Free Page の状態を確認してみます。
image

Free Page のサイズは、
73 ページ = 73 × 8 KB = 592 KB
となりますので、確保しているメモリの大半は Free Page ではなく起動に必要な領域となっていることが確認できます。

 

■SQL Server 2000 で AWE を確認

先ほどは AWE を SQL Server 2005 で確認をしてみましたが SQL Server 2000 SP4 (8.00.2039) でも確認をしてみたいと思います。

SQL Server 2000 でも DBCC MEMORY STATUS は使用できます。
表示形式が SQL Server 2005 とは異なるのですが、[Buffer Distribution] からメモリを確認することができます。
今回は Windows 2000 Server 上に SQL Server 2000 をインストールしていますので、サービスの起動時は可能な限りのメモリが割り当てられます。
image

SQL Server 2000 の場合は KB ではなく、ページ数で表示がされます。
250,755 ページ = 250.755 × 8KB = 2,006,040 KB
となります。

SQL Serve 2000 では、Free Pages からはうまく値を取得できなかったので、[Memory ManagerTotal Server Memory (KB)] から情報を取得しています。
image

平均して、[2,021,680 KB] となっています。

4 GB のメモリを搭載した環境で、AWE を有効にして 2GB のメモリ割り当てというのは少し気になりますよね。
SQL Server 2000 SP4 用に以下の修正プログラムが提供されています。
[FIX] 32 ビット版の SQL Server 2000 SP4 を実行するコンピュータで AWE を有効にすると使用できないメモリ領域がある

SP4 では AWE を有効にしても物理メモリの半分までしかメモリが使用できないという不具合があります。
修正プログラムを実行して再度メモリの使用状況を確認してみます。
image

421,092 ページ = 421,092 × 8KB = 3,368,736
になりますので、先ほどの SQL Server 2005 の時と同程度のメモリが割り当てられています。

修正プログラムを適用すると Free Page の状況も正常に取得することができました。
image

421,083 ページ = 421,083 ページ × 8 KB = 3,368,664 KB
になりますので、大半が Free Page となっているのが修正プログラムを適用すると確認ができます。

 

AWE を有効にすると AWE によってマッピングされた 2GB を超える領域はデータキャッシュのみで使用でき、クエリキャッシュはユーザーモードの空間 (2GB の空間)  でしか使用できないという話をよく聞くことがあると思います。

次の投稿では AWE で有効にしたメモリの使用状況についてまとめたいと思います。

Written by Masayuki.Ozawa

12月 4th, 2010 at 11:09 pm

Posted in SQL Server

Tagged with ,

あらためて SQL Server と AWE その 1

leave a comment

32 ビットの SQL Server で大容量のメモリ割り当ての手法として AWE (Address Windowing Extensions) という設定があります。

これから数回に分けて AWE についてまとめていきたいと思います。

■SQL Server の最大メモリ

32 ビットの SQL Server 2008 R2 の最大メモリは以下のようになります。
SQL Server 2008 R2 のインストールに必要なハードウェアおよびソフトウェア

エディション 最大メモリ
Datacenter オペレーティング システムの最大容量
Enterprise オペレーティング システムの最大容量
Standard 64 GB

 

32 ビットの SQL Server ではユーザーモードの VAS (仮想アドレス空間) は 2GB または 3GB となり、それ以上のメモリを使用するためには AWE を使用する必要があります。
image

AWE に関しては以下の技術情報の絵がわかり易いと思います。
プロセス アドレス空間

AWE を使用することでユーザーモードの VAS の一部を使用して、利用できるメモリの領域を拡張することが可能となります。
image

■AWE を使用するための必須となる前提設定

AWE の使用有無に関しては、SQL Server で設定をするのですが、使用するためには必須となる設定があります。

それが [ローカル セキュリティ ポリシー] の設定です。

ローカル セキュリティ ポリシーで、[メモリ内のページのロック] という権限を SQL Server のサービス起動アカウントに付与する必要があります。
# 英語では、[Lock Pages in Memory] と呼ばれているものになります。
Lock Pages in Memory オプションを有効にする方法 (Windows)

image
image

初期設定ではこのポリシーにはどのユーザー / グループも設定はされていません。
SQL Server をローカルシステムで実行していると、ポリシーを設定していなくても AWE を使用することが出来たりするのですが、サービスの専用ユーザーを作成して SQL Server を実行している場合は、このポリシーにサービス用のユーザーを設定する必要があります。

AWE が正常に有効化されていると以下の SQL Server のログに以下のメッセージが表示されます。

Using locked pages in the memory manager.

image

AWE が有効になっていない場合は以下のメッセージとなります。

Using conventional memory in the memory manager.

image

 

■ログ以外で AWE が有効になっているかを確認

先ほどはログから AWE が有効になっているかを確認しましたが、他の方法でも確認することができます。
[DBCC MEMORY STATUS] を実行することで、AWE によりメモリが割り当ての情報を取得できます。
[Memory Manager] や他のセクションの情報から [AWE Allocated] を確認することで AWE によるメモリ割り当てが行われているかを確認することができます。

以下が、AWE が正常に動作しているときの情報になります。
image

[AWE Allocated] に情報が出力されていますね。

AWE が有効になっていない、メモリ内のページのロックが有効になっていない場合は以下のような情報となります。
image

AWE が使われておらず、通常のメモリ割り当てが行われていますので、[VM Committed] としてメモリが割り当てられているのが確認できます。

ログから見ると実際に使われているかが不安になることがありますので、DBCC MEMORYSTATUS を実行して数値として確認をした方が安心かと思います。

ここまでの設定で AWE を知っている方ですと、[max server memory] と [m
in server memory] の設定は? と思われるかもしれません。

次の投稿でこの辺の設定が影響する、[動的メモリ] についてまとめていきたいと思います。

Written by Masayuki.Ozawa

12月 4th, 2010 at 9:06 pm

Posted in SQL Server

Tagged with