为什么 SQL Server docker 映像始终使用高 CPU，以及如何修复它？

Question

使用它docker-compose.yml我创建了一个容器：

version: "3.9"
services:
    database:
        image: mcr.microsoft.com/mssql/server
        user: root
        restart: always
        container_name: ContainerNameHere
        volumes:
            - /Organization/Databases:/var/opt/mssql/data
        environment:
            - ACCEPT_EULA=Y
            - SA_PASSWORD=password_here
            - MSSQL_PID=Express
        ports:
            - 1433:1433
        logging:
            driver: none
        networks:
            - NetworkNameHere
networks:
    NetworkNameHere:
        name: NetworkNameHere
        driver: bridge

它的用户数据库为零。它只是一个简单的空 SQL Server docker 容器，没有数据库，也没有数据。

但这是我的top命令的结果：

正如你所看到的，它完全摧毁了我的 VPS。

这太令人沮丧了，微软团队还没有回复我。

为什么 SQL Server 的 docker 容器会这样，我应该如何解决这个问题？

---

我有 10 GB 可用空间：

df -h /

已用文件系统大小 Avail Use% 安装在
/dev/sda1 20G 8.9G 10G 47% /

我的 SQL Server 构建版本是 15.0.4153.1，这意味着它是 SQL Server 2019 CU13。

我的主机操作系统（运行 docker Demon）是 Debian GNU/Linux 10 (buster)。

Answer 1

从top输出来看：

平均负载：0.94、0.55、0.51

这些是过去 1 分钟、5 分钟和 15 分钟的平均CPU 利用率。所以...根据您的屏幕截图（假设有两个CPU），SQL Server 似乎并没有使用大量资源。

第 3 行还显示 CPU 的空闲时间为 87.9%。

您评论道：

问题在于，当SQL Server没有负载时，它为什么会消耗资源呢？我们在一台 VPS 上有 10 个 mariadb 容器，在没有负载时它们甚至不使用 1% 的 CPU。

MySQL 是一个与 SQL Server 非常不同的数据库引擎。我认为这是在比较苹果和橙子。

SQL Server 有许多后台进程和任务，它们会定期触发以维护系统状态。一些例子包括：

• 死锁监视器，定期检查涉及无法解决的死锁的查询
• 幽灵清理，每隔一段时间运行一次，以删除已标记为删除的行
• 调度程序监视器，它验证工作线程是否正确地将 CPU 上的时间让给其他任务（如果没有，则创建错误日志条目和故障转储）
• 默认的 system_health 扩展事件会话，它非常定期地写入诊断信息

还有许多其他类似的项目。因此，您有时会看到空闲的 SQL Server 实例使用一些 CPU。在小型两核系统上，它甚至可能看起来占总容量的很高比例。但我不认为这对于系统上的预期工作负载本身来说是一个问题。它看起来也不像是 SQL Server 的错误或整体问题。