首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >当连接到本地主机时,SMO、SSMS对Docker中的Server的管理速度很慢

问当连接到本地主机时,SMO、SSMS对Docker中的Server的管理速度很慢
EN

Database Administration用户
提问于 2018-02-09 14:38:06
回答 1查看 2.8K关注 0票数 9

TL;DR:当通过解析到IPv6环回(::1)的名称连接到我的Server容器时,SMO调用非常慢。当使用127.0.0.1时,它们速度很快。

我正在努力学习如何使用码头形象microsoft/mssql-server-windows-developer。根据Microsoft的文档,此容器只公开端口1433 TCP。

代码语言:javascript
复制
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主机(连接到localhost或“.”)和通过IP连接的mac上使用sqlcmd和SSMS 17.4以及SQL Operations对实例运行查询。在以这种方式运行查询时,我没有发现明显的性能问题。

在SSMS中,我也可以浏览对象资源管理器( object ),但是如果我试图从对象资源管理器中的一个对象的右键菜单中执行一些操作,比如打开实例参数窗口或附加一个数据库,那么SSMS将在大约5-10分钟内不显示响应,此时它会显示我请求的窗口,或者显示此错误消息:

我也在尝试做一些使用断续器对象针对此实例编写PowerShell脚本,并看到同样的行为。PS脚本循环遍历数据库中的对象并将其写入文件,虽然它可以相对较快地收集对象列表,但每个单独的对象需要5-10分钟的时间来编写脚本--太慢了,无法使用。

我有一种预感,单暴露端口是不够的,SMO和SSMS试图以一种类似的方式连接,从而减慢了它们的速度。当连接到本地主机时,这些工具是否也假设存在其他通信通道,而这些通道通常不是防火墙的?我是否可以使用其他连接参数?有人能证实我的假设,即SSMS正在使用SMO或其他东西与Server对话吗?

更新:我还在调查,但似乎可以说,这是一个围绕资源限制的码头问题。这是令人困惑的,因为大多数文档似乎表明Windows容器没有任何默认资源约束(而且这些约束不能在Docker 只适用于Linux容器中设置),但在现实中,运行在Windows 10上的Windows容器的默认内存分配似乎是1GB。我仍在努力研究如何检查正在运行的容器,以查看其RAM和CPU分配情况,但接下来,我必须尝试使用docker run参数从任何缺省值中增加这些内存和CPU分配。

进一步更新:我一直没有得到任何可靠的标准,从码头告诉我,它有什么CPU和内存限制的容器。变研究表示,默认情况下,停靠容器没有内存限制,或者它们有内存限制,而且内存为1GB,但我目前所能验证的是,docker stats表示该容器仅使用750到850 meg,当我试图添加一个run参数将可用内存设置为4GB时,它就出错了。因此,我停止了这条查询线程,进行了一次不同的检查:在正在运行的容器上输入一个交互式powershell会话,然后从容器内部调用上面链接的powershell脚本。

在容器内运行没有问题。它在短短几分钟内就照亮了2780个物体。我认为这证实了问题在于容器/主机边界,所以我将看看是否可以打开UDP端口。更新:打开端口1434 UDP没有帮助。

更多的更新--实现了解决办法,而不是资源约束问题:似乎存在与为windows容器设置大量内存分配有关的问题 --我在3g和2g中收到了类似的错误,但最终能够用1.5g启动容器,而且我确实看到了容器的docker stats存在差异,我(我认为)确认它运行时默认分配为1GB。在默认设置中,PRIV工作集stat (我无法找到任何文档,但我最好的猜测是它是RAM)介于700MiB和850 my之间。在docker run —memory="1.5g"设置下,它大约是1.0GiB。因此,它确实扩大了,但似乎比以前更多地免费分配。我将此(可能是错误的)解释为意味着此服务器(它运行的是绝对没有负载且没有用户数据库)不受内存压力。我检查了最大服务器内存设置,以确认它被设置为默认最大值2 2PiB。

然后事情变得怪怪的。我仍然在通过从不同的位置运行我的powershell脚本来测试一些事情。容器内快,主机慢。然后,我将RDP转到网络上的另一台windows机器上,并从该机器上运行脚本,通过IP连接到我的Windows 10主机。而且速度很快!这似乎支持这样的理论,即当连接到被认为是本地主机的东西时,SMO试图使用端口1433 TCP以外的其他东西连接到SQL Server,该端口等待很长时间才返回到TCP连接。

我决定尝试通过输入一个主机文件条目来验证这一理论,通过一个不是localhost的名称来引用localhost:

代码语言:javascript
复制
        127.0.0.1       dockersucks

我在SSMS中连接到了伪随机主机,而不是localhost或".",很快事情就变得更快了。导航对象资源管理器( object )与往常一样,打开面板(如附加数据库或服务器属性)的速度与正常情况一样快。而且,当我使用这个别名作为服务器名在windows 10主机上运行我的powershell脚本时,它也非常快。

我把这个更新添加到了这个问题中,而不是一个答案,因为我仍然在寻找为什么会发生这种情况,以及是否有一种方法可以用这个名称修复到"localhost“的连接。

EN

回答 1

Database Administration用户

回答已采纳

发布于 2018-02-09 21:14:12

这里的关键区别在于SSMS/SMO是试图连接到IPv4还是IPv6。如果在命令提示符中执行ping localhost,则应该看到它解析为::1,这是IPv6等效的127.0.0.1。连接到.也是一样的。

您的docker run命令仅在127.0.0.1上公开端口1433。您可以通过运行netstat -a来验证这一点,以查看哪些端口可用。

您创建的主机文件别名直接解析到127.0.0.1,但您不需要它,因为您可以在SSMS中直接连接到127.0.0.1并以这种方式解决问题。在您的主机系统上完全关闭IPv6也可能有效,但我不确定这在Windows 10上是否可取。

如果有人能告诉我为什么IPv6会导致这个中断,我会考虑接受另一个答案。

票数 3
EN
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://dba.stackexchange.com/questions/197499

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档