SMO、SSMSは、ローカルホストに接続するときにDockerでのSQL Serverの管理に時間がかかる
TL; DR：IPv6ループバック（::1）に解決される名前でSQL Server Dockerコンテナーに接続すると、SMO呼び出しが本当に遅くなります。 127.0.0.1を使用すると、高速になります。
Dockerイメージ Microsoft/mssql-server-windows-developer の使用方法を学習しようとしています。 Microsoftのドキュメントによると、このコンテナはポート1433 TCPのみを公開しています。
docker run -d -p 1433:1433 -e sa_password=Passw0rd! -e ACCEPT_EULA=Y -v C:\dockerdb:C:\dockerdb Microsoft/mssql-server-windows-developer
私はWindows 10でコンテナーを実行していますが、コンテナーの起動、SQL Server認証による認証、WindowsホストでのsqlcmdおよびSSMS 17.4を使用したインスタンスに対するクエリの実行（localhostまたは「。」に接続）、およびSQL操作に成功しています。 IPで接続する隣のMacのスタジオ。この方法でクエリを実行しても、目立ったパフォーマンスの問題はありません。
SSMSでは、オブジェクトエクスプローラーも参照できますが、インスタンスエクスプローラーウィンドウを開いたり、データベースを接続したりするなど、オブジェクトエクスプローラーのオブジェクトを右クリックメニューから何かしようとすると、SSMSは約5秒間応答を表示しません-10分。この時点で、要求したウィンドウが表示されるか、次のエラーメッセージが表示されます。
私もいくつかしようとしています SMO Scripterオブジェクトを使用してこのインスタンスに対してPowerShellスクリプト を実行して、同じ種類の動作を確認します。 PSスクリプトは、データベース内のオブジェクトをループしてスクリプトでファイルに保存し、オブジェクトのリストを比較的迅速に収集しますが、個々のオブジェクトのスクリプト作成には5〜10分かかり、使用するには遅すぎます。
公開された単一のポートでは不十分であり、SMOとSSMSが同様の方法で接続しようとすると、速度が低下するという予感があります。また、localhostに接続するときに、これらのツールは、通常はファイアウォールで保護されない他の通信チャネルが存在すると想定しているのでしょうか。使用できる追加の接続パラメーターはありますか？ SSMSがSMOまたは何か他のものを使用してSQL Serverと通信しているという私の仮定を誰かが検証できますか？
UPDATE：まだ調査中ですが、これがリソースの制約に関するDockerの問題であると考えられます。ほとんどのドキュメントは、Windowsコンテナにデフォルトのリソース制約がないことを示しているようであり、これらはDockerで設定できない Windows GUIの場合— Linuxコンテナの場合のみ ）ですが、実際には、Windows 10で実行されているWindowsコンテナは、デフォルトのRAM 1GBの割り当てを取得します。実行中のコンテナーを検査してそのRAMとCPU割り当てを確認する方法を理解しようとしていますが、次にdocker runパラメーターを使用して、デフォルトの値からそれらを増やしてみます。
追加の更新：Dockerから信頼性の高いメトリックを取得できず、DockerにどのCPUとメモリの制限が設定されているかがわかりますコンテナ。 Varying research は、Dockerコンテナにデフォルトでメモリ制限がないか、またはメモリ制限があり、1 GBであることを示していますが、現時点で確認できるのは、docker statsがSQLコンテナのみであるusing750〜850 meg、実行パラメーターを追加して使用可能なメモリを4 GBに設定しようとすると、エラーが発生します。だから私はその問い合わせのスレッドに従うのをやめ、別の腸チェックに行きました：実行中のコンテナーでインタラクティブなPowerShellセッションを入力してから、コンテナーのinsideから上記のリンクのPowerShellスクリプトを呼び出します。
コンテナ内で実行しても問題はありませんでした。それはほんの数分で2780オブジェクトを突破しました。これは問題がコンテナー/ホスト境界にあることを確認していると思うので、そのUDPを開くことができるかどうかを確認します港。 UPDATE：ポート1434 UDPを開くことは役に立ちませんでした。
更なる更新—回避策は達成されましたが、リソース制約の問題ではありません：issues がWindowsに大きなメモリ割り当てを設定することに関連しているようですコンテナ— 3gと2gで同様のエラーを受け取りましたが、最終的に1.5gでコンテナを開始でき、私はDIDコンテナのdocker statsに違いがあることを確認します（そう思う）デフォルトの割り当てである1GBで実行していたことを確認します。デフォルト設定では、PRIV WORKING SET統計（ドキュメントは見つかりませんが、RAMだと思われます）は700MiBから850MiBの間です。docker run —memory="1.5g"セットでは、約1.0GiBです。拡張されましたが、以前よりも多くの割り当てを解放しているようです。これは（おそらく誤って）解釈され、このサーバー（まったく負荷がなく、ユーザーデータベースもありません）がメモリ不足ではありません。サーバーの最大メモリ設定をチェックして、デフォルトの2PiBに設定されていることを確認しました。
それから物事は奇妙になりました。私はまださまざまな場所から私のpowershellスクリプトを実行して物事をテストしています。コンテナ内は高速、ホストは低速。次に、ネットワーク上の別のWindowsマシンにRDPを実行し、そのマシンからスクリプトを実行して、IPでWindows 10ホストに接続しました。 これは高速でした！これは、localhostであるはずの何かに接続するときに、SMOが何かを使用してSQL Serverに接続しようとしているという理論をサポートしているようですポート1433 TCP以外は、非常に長いタイムアウトを待ってから、TCP接続にフォールバックします。
私は、localhost以外の名前でlocalhostを参照するようにホストファイルエントリを入力して、この理論を検証することにしました。
127.0.0.1 dockersucks
SSMSでlocalhostまたは "。"の代わりにdockersucksに接続しましたが、すぐに高速になりました。オブジェクトエクスプローラーの操作は通常どおりで、データベースやサーバーのプロパティのアタッチなどのパネルを開く操作は、通常と同じくらい迅速に行われました。また、このエイリアスをサーバー名として使用して、Windows 10ホストからpowershellスクリプトを実行したところ、高速でした。
なぜこの問題が発生しているのか、その名前で「localhost」への接続を修正する方法があるかどうかの説明をまだ探しているので、回答の代わりにこの更新を質問に追加しました。
ここでの主な違いは、SSMS/SMOがIPv4またはIPv6のどちらで接続しようとしているのかです。コマンドプロンプトでping localhostを実行すると、::1に解決されることがわかります。これは127.0.0.1と同等のIPv6です。 .への接続も同じです。
docker runコマンドは、127.0.0.1のポート1433のみを公開します。これを確認するには、netstat -aを実行して、使用可能なポートを確認します。
作成したホストファイルエイリアスは127.0.0.1に直接解決されますが、SSMSで127.0.0.1に直接接続して問題をその方法で解決できるため、必要ありません。ホストシステムでIPv6を完全にオフにすることもおそらく機能しますが、これがWindows 10でどの程度推奨されるかはわかりません。
IPv6が原因でこの問題が発生する理由を誰かが教えてくれた場合は、別の回答を受け入れることを検討します。
これはおそらくRAMの飢餓問題です。
確認すること：
コンテナには4 GBのRAMが割り当てられていますか？チェック この答え 。コンテナー内のSQL Serverの最大サーバーメモリ設定を構成しましたか？コンテナでRAM SQL Serverが認識できる量に応じて、これは1 GB〜3.25 GBのいずれかに設定される場合があります。ホストのRAMが使い果たされていますか？Dockerがディスクにページングしている可能性はありますか？無関係なアプリケーションをすべて閉じます（WebブラウザーはRAMを大量に消費します）。 SSMSを使用するには、約1 GBのRAMが必要です。再起動後の方が速いですか？
私がこれを自分で行っている場合は、Docker Community Edition for Windows Dockerストアから をインストールし、次に SQL Server Dockerイメージ をインストールします。
インターネット接続が十分に高速であれば、5分未満で稼働し、はるかに簡単な方法でリソースを割り当てることができます。
編集：ああ、ネットワーキング。