连接到本地主机时，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上的Studio。这样运行查询时，我看不到任何明显的性能问题。 在SSMS中，我也可以浏览对象资源管理器，但是如果尝试从对象资源管理器中的对象的右键菜单上执行某些操作，例如打开实例参数窗口或附加数据库，则SSMS不会显示约5的响应-10分钟，此时它要么显示我要的窗口，要么显示以下错误消息： 我还尝试使用SMO Scripter对象针对此实例进行一些PowerShell脚本编写，并看到相同的行为。PS脚本循环遍历数据库中的对象并将其脚本化为文件，并且可以相对较快地收集对象列表，但是每个单独的对象需要5-10分钟的时间来编写脚本-太慢了，无法使用。 我有一个预感，即单个暴露的端口还不够，SMO和SSMS试图以类似的方式进行连接，这会使它们变慢。难道是当连接到本地主机时，这些工具是否假定存在其他通常不会进行防火墙保护的通信通道？我可以使用其他任何连接参数吗？谁能验证我关于SSMS正在使用SMO或其他与SQL Server通信的假设？ 更新：我仍在调查，但这似乎是围绕资源限制的Docker问题。这很令人困惑，因为大多数文档似乎都表明Windows容器没有任何默认资源限制（并且不能在Docker for Windows GUI中设置这些默认资源限制- 仅对于Linux容器），但是实际上，Windows在Windows 10上运行的容器的默认RAM分配为1GB。我仍在尝试找出如何检查正在运行的容器以查看其RAM和CPU分配的方法，但是接下来我必须尝试使用docker run参数从默认值中增加这些值。 进一步更新：我一直无法从docker获得任何可靠的指标，该指标可以告诉我该容器对CPU和内存的限制。各种研究表明，docker容器默认没有内存限制，或者它们有1GB，但是我目前只能验证的是，docker stats该SQL容器仅使用 750到850兆之间，何时我尝试添加一个运行参数来将可用内存设置为4 GB，但出现错误。因此，我不再关注该查询线程，而是进行了另一项肠道检查：在正在运行的容器上进入交互式Powershell会话，然后从容器内部调用上面链接的Powershell脚本。 在容器内运行没有问题。它在短短几分钟内就烧穿了2780个物体。我认为这可以确认问题出在容器/主机边界上，因此我将看看是否可以打开该UDP端口。更新：打开端口1434 UDP没有帮助。 更多更新-已解决，而不是资源约束问题：似乎与为Windows容器设置大的内存分配有关的问题 -我在3g和2g上收到类似的错误，但最终能够从1.5g启动该容器，并且我发现docker stats容器的差异（我认为）证实了容器运行时的默认分配为1GB。在默认设置下，PRIV WORKING SET stat（我找不到任何文档，但我最大的猜测是它的RAM）在700MiB和850MiB之间。用docker run —memory="1.5g"设置，大约是1.0GiB。因此，它的确扩大了，但似乎腾出了比以前更多的分配空间。我将此解释（可能是错误地）是指该服务器（绝对没有负载运行并且没有用户数据库）没有内存压力。我检查了最大服务器内存设置，以确认它设置为默认的最大2PiB。 …