我在SQL Server上尝试不同的定价层。
我在10秒内插入分布在4个桌子上的4000行
我的问题:我没有从小型D2S_V3到D8S_V3的任何性能改进
我的应用需要插入很多行(膨胀不是一种选择),这种性能是不可接受的
我想知道为什么我看不到改进。
所以我的noob问题:我需要配置一些东西才能看到改进吗?我天真的想法说我应该有所不同:-)
我做错了什么?
答案 0 :(得分:0)
在不了解您的架构的情况下,它看起来像是存储绑定或网络绑定。 存储: 尝试将数据库挂载到本地(临时磁盘),看看是否有任何区别,如果它更快,那么你的瓶颈就是挂载的磁盘。
网络绑定: 插入这些交易的客户在哪里?在同一台机器上?在Azure上? 我建议你在同一地区设置一个客户端并进行测试。
答案 1 :(得分:0)
在10秒内插入分布在4个表中的4000行。我从小型D2S_V3到D8S_V3没有任何性能改进
我会使用等待统计方法来解决这个问题,而不是首先抛出硬件而不知道问题。
例如,在insert
下面运行insert into #t
select orderid from orders o
join
Customers c
on c.custid=o.custid
向我展示了等待统计数据
Wait WaitType =“SOS_SCHEDULER_YIELD”WaitTimeMs =“1”WaitCount =“167” Wait WaitType =“PAGEIOLATCH_SH”WaitTimeMs =“12”WaitCount =“3”/> Wait WaitType =“MEMORY_ALLOCATION_EXT”WaitTimeMs =“21”WaitCount =“4975”/>
大部分时间,查询花费时间
<强> PAGEIOLATCH_SH:强> 从磁盘获取数据到内存中 MEMORY_ALLOCATION_EXT :为要运行的查询分配内存
基于此我将尝试通过查看我的系统是否有内存压力进行故障排除,因为此查询试图从磁盘获取数据。
这只是一个例子,但希望这会给你一个想法..
此外,我将尝试查看select是否快速恢复数据
答案 2 :(得分:0)
性能可以直接链接到您的硬件或配置,但它更可能与结构和查询有关。查看INSERT操作的执行计划,了解优化程序如何解析它。此外,使用扩展事件捕获查询度量标准,以查看操作正在使用的资源数量。这些更有可能导致解决查询执行速度缓慢的原因并使您能够扩展硬件以最好地为查询提供服务。