Shamvil Kazmi's questions

我是 Linux 新手，我们的客户决定在 Linux 上使用 SQL Server。我们一开始测试，就遇到了性能问题。

有问题的服务器是配置有 SSD 本地磁盘和“本机”附加存储的物理机器。我不知道这里引用的“本机”实际上是什么意思。下面是 Linux 家伙的原话

存储“本地”连接到服务器

存储区域网络也建立在 SSD 之上，我在一秒钟内将一个 4.7 GB 的备份文件从那里复制到本地 SSD。

cp \gsfs\sql\backups\testdb01.bak \tmp\backups\testdb01.bak

但是当我尝试从

1. SAN

RESTORE DATABASE 在 369.425 秒（12.952 MB/秒）内成功处理了 612466 个页面。

2. 本地磁盘

RESTORE DATABASE 在 26.248 秒（182.295 MB/秒）内成功处理了 612466 个页面。

数据库文件也存储在 SAN 上，虽然 SAN 到物理机没有连接问题，但我敢肯定，MS SQL 读取 SAN 上文件的方式与速度慢有关。

数据库大小不够大，根据等待统计，数据库通常处于空闲状态

我想了解为什么 SQL Server 从 SAN 恢复比本地文件系统慢。如果差异很小，我会理解，但目前，差异是巨大的。由于我们的数据文件和日志文件也在 SAN 上，我们需要确保尽可能快地读取/写入磁盘。

• 大多数设置都设置为默认值
• 网络数据包大小为 4096
• 没有安装防病毒软件

服务器信息

操作系统 Redhat 7 内存 100GB CPU 使用率 1% 用户 db 大小 每个平均 2 GB 总共 7 个用户数据库 SSMS 安装在跳转服务器上 Azure Data studio 也安装在应用程序服务器上 App Gui 跳转服务器到数据库服务器之间的延迟 <1ms 应用程序之间的延迟server和db server <1ms都在同一个网络中，它们之间只有交换机都是物理机

问题

1. SSMS - 当我连接到 SSMS 时，对象资源管理器中的数据库需要大约 30 秒来填充。打开数据库属性最多需要 50 秒才能从 SSMS 中打开查询分析器/sqlcmd 立即运行“从 sys.sysdatabases 中选择名称”，不会有任何延迟

2. Azure 数据工作室 - 填充数据库列表的速度相当快，但显示数据库属性需要一分钟多的时间。

3. App Gui - 也具有与 SSMS 相同的行为。

从每个位置，查询似乎都足够快，但发现 GUI 很慢。

不同的场景

我在 Windows 操作系统上还有其他 SQL Server、SSMS、Azure 数据工作室的行为很常见，它们会立即在 GUI 上填充信息。我们在 Azure SQL 数据库和 Azure VM 上也有很少的数据库，它们还可以即时连接并在 SSMS GUI 上即时填充信息

我们想要达到什么目的？

我们需要我们的 App gui、SSMS 在 gui 级别上与 Windows 操作系统上的 SQL Server 一样快。

那么可能是什么问题以及如何解决这个问题？

请帮忙！

编辑 -

我错过了最重要的部分。所述实例为Express版。因此，他们投入其中的超级令人印象深刻的硬件并未得到充分利用。加上默认的自动关闭功能。