Questions tagged «docker»

我想问一个有关本文档中描述的最佳实践的问题： http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf 使用多个查询路由器。使用跨多个服务器的多个mongos进程。常见的部署是将mongos进程共定位在应用程序服务器上，从而允许应用程序和mongos进程之间进行本地通信。mongos进程的适当数量将取决于应用程序和部署的性质。 有关我们的部署的背景知识。我们有很多应用服务器节点。它们每个都使用无状态RESTful WS运行一个基于JVM的进程。正如最佳实践所建议的那样，每个单个应用程序服务器节点都运行自己的mongos进程，这意味着JVM进程的数量始终等于进程的数量mongos。 所有mongos进程都连接到3台配置服务器和几个mongo分片（每个分片内都有副本集）。即使我们使用分片部署，也没有真正分片集合。实际上，我们有大量的数据库，这些数据库在创建时就分布在所有分片上（这是目前分片的主要用例）。 由于最佳实践还表明“适当的mongos进程数量将取决于应用程序和部署的性质”，我开始怀疑我们的用法mongos实际上是否合适，或者让我们拥有几个专用mongos节点是否更好？我们的应用服务器无需mongos本地运行即可连接到它们。 您对决定mongos与应用程序服务器实例数量或MongoDB集群大小相关的多少个实例合适的最佳方法有何看法？ 最近，我们开始研究无状态Web服务的集群管理，我的意思是指诸如Docker，Apache Mesos和Kubernetes之类的工具。如果我们使用的是Docker，那么通常不建议在容器内运行多个进程。考虑到这一事实，要确保应用程序服务器容器和mongos容器始终位于同一物理节点上并具有相同数量的进程，将变得非常困难。这使我想知道这种最佳实践是否仍然适用于我刚刚描述的集群体系结构。如果没有，您能否建议mongos在这种体系结构中定位和部署流程的更好方法是什么？

12 mongodb  best-practices  sharding  deployment  docker 

我有以下配置： 运行三个Docker容器的主机： MongoDB 雷迪斯 一个使用前两个容器存储数据的程序 Redis和MongoDB都用于存储大量数据。我知道Redis需要将其所有数据保留在RAM中，对此我很好。不幸的是，发生的事情是mongo开始占用大量RAM，并且一旦主机RAM已满（我们在这里谈论32GB），mongo或Redis就会崩溃。 我已阅读以下有关此问题的问题： 限制MongoDB RAM的使用：显然，大多数RAM被WiredTiger缓存用尽 MongoDB限制内存：显然这里的问题是日志数据 限制MongoDB中的RAM内存使用量：在这里，他们建议限制mongo的内存，以便它的缓存/日志/数据使用较少的内存 MongoDB使用了过多的内存：在这里，他们说这是WiredTiger缓存系统，该系统倾向于使用尽可能多的RAM以提供更快的访问速度。他们还说it's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently 是否有任何限制mongodb内存使用的选项？：再次缓存，它们也添加MongoDB uses the LRU (Least Recently Used) cache algorithm to determine which "pages" to release, you will find some more information in these …

11 mongodb  memory  limits  docker 

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。 …

9 sql-server  ssms  sql-server-2017  docker  smo