RomanG's questions

我们将 3 个 MongoDB 实例3.2.12配置为副本集。启用日记功能，存储引擎为 WiredTiger。

大多数时候，我们的应用程序在数据库服务器上产生非常低的负载并且运行良好，但我们很少启动导致 x10...x100 负载增加的后台维护，主要是由于insert操作：~10000 次插入/秒。

今天在维护期间，我们注意到我们的应用程序的响应时间在短时间内每 1 分钟增加一次。

我们怀疑它与 MongoDB 服务器有关，并发现以下事实：

mongostat输出示例：

insert query update delete getmore command % dirty % used flushes vsize   res qr|qw ar|aw netIn netOut conn set repl           time
   891   936    235     14     388  2620|0     4.6   80.0       0 33.8G 26.7G   0|0   1|0 2.02m  2.38m  208 rs0  PRI 14:55:49+03:00
  1098   861      3     12     107   452|0     4.6   80.0       0 33.8G 26.7G   0|0   1|1 1.07m  5.39m  208 rs0  PRI 14:55:50+03:00
 14602   725     11     14     259   727|0     4.7   80.0       0 33.8G 26.7G   0|0   0|0 7.57m  8.44m  208 rs0  PRI 14:55:51+03:00
     4   527    260      1      23   100|0     4.7   80.0       0 33.8G 26.7G   0|0   0|0  383k  3.60m  208 rs0  PRI 14:55:52+03:00
  8698   121    671     11     186   585|0     4.8   80.0       0 33.8G 26.7G   0|0   2|0 5.61m  6.30m  208 rs0  PRI 14:55:53+03:00
  5539   645     21      9     199   623|0     4.9   80.0       0 33.8G 26.7G   0|0   1|0 5.19m  5.77m  208 rs0  PRI 14:55:54+03:00
  2599   602     14      9      99   370|0     4.9   80.0       0 33.8G 26.7G   0|0   1|0 1.48m  2.37m  208 rs0  PRI 14:55:55+03:00
  3507   485     22      3     139   415|0     4.9   80.0       0 33.8G 26.7G   0|0   0|0 4.90m  5.33m  208 rs0  PRI 14:55:56+03:00

  3627   369   4019      9     133   415|0     4.3   80.0       1 33.8G 26.7G   0|0   4|3 4.59m  4.18m  208 rs0  PRI 14:55:57+03:00

     3    17     20      1      11    63|0     2.9   80.0       0 33.8G 26.7G   0|0 13|12 29.8k  56.3k  208 rs0  PRI 14:55:58+03:00
     5    24      4      1      18    88|0     2.1   80.0       0 33.8G 26.7G   0|0 18|16 39.1k   270k  208 rs0  PRI 14:55:59+03:00
     2     9      2      3       9    54|0     0.5   80.0       0 33.8G 26.7G   0|0 22|20 20.2k  88.9k  208 rs0  PRI 14:56:00+03:00
     2    47     *0      3       2    21|0     0.3   80.0       0 33.8G 26.7G   0|0 24|23 18.0k  39.6k  208 rs0  PRI 14:56:01+03:00
 26635   991   5475     35     410  1189|0     0.8   80.0       0 33.8G 26.7G   0|1   2|0 16.4m  21.0m  207 rs0  PRI 14:56:02+03:00

• 应用程序缓慢的时刻与mongstat报告的时刻完美匹配flushes = 1。

• 在此事件后的接下来 4 秒内，MongoDB 处理的请求数量非常少。

• transaction checkpoint most recent time (msecs)来自 的值也serverStatus等于 ~4000 毫秒。

我们启动iostat -x -d 1并发现了以下模式：

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              36.00   311.00   33.00   61.00   276.00  1384.00    35.32     0.04    0.39    0.36    0.41   0.34   3.20
sdb              60.00   311.00   21.00   61.00   324.00  1384.00    41.66     0.03    0.38    0.38    0.38   0.34   2.80
sdc              36.00   311.00   33.00   63.00   276.00  1392.00    34.75     0.04    0.43    0.33    0.48   0.38   3.60
sdd              57.00   311.00   20.00   63.00   308.00  1392.00    40.96     0.04    0.46    0.30    0.51   0.42   3.50
md126             0.00     0.00  296.00  695.00  1184.00  2776.00     7.99     0.00    0.00    0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    7.00   21.00    28.00    36.00     4.57     0.01    0.43    0.29    0.48   0.32   0.90
sdb               0.00     0.00    4.00   21.00    16.00    36.00     4.16     0.01    0.40    0.25    0.43   0.28   0.70
sdc               0.00     0.00    6.00   21.00    24.00    36.00     4.44     0.01    0.26    0.33    0.24   0.19   0.50
sdd               0.00     0.00    4.00   21.00    16.00    36.00     4.16     0.01    0.24    0.25    0.24   0.16   0.40
md126             0.00     0.00   21.00   21.00    84.00    72.00     7.43     0.00    0.00    0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    4.00     0.00     8.00     4.00     0.00    0.50    0.00    0.50   0.50   0.20
sdb               0.00     0.00    0.00    4.00     0.00     8.00     4.00     0.00    0.50    0.00    0.50   0.50   0.20
sdc               0.00     0.00    0.00    2.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdd               0.00     0.00    0.00    2.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
md126             0.00     0.00    0.00    4.00     0.00     8.00     4.00     0.00    0.00    0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00 17275.00    1.00 2824.00     4.00 79688.00    56.42    10.25    3.63    0.00    3.63   0.14  39.40
sdb               0.00 17275.00    1.00 2824.00     4.00 79688.00    56.42    10.65    3.77    0.00    3.77   0.14  39.60
sdc               0.00 17284.00    1.00 2799.00     4.00 79624.00    56.88    10.70    3.82    0.00    3.82   0.14  39.20
sdd               0.00 17284.00    1.00 2799.00     4.00 79624.00    56.88    11.40    4.07    0.00    4.07   0.15  40.70
md126             0.00     0.00    4.00 39867.00    16.00 159316.00     7.99     0.00    0.00    0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              53.00 19426.00   64.00 4645.00   468.00 95132.00    40.60    18.43    3.91    0.31    3.96   0.11  52.80
sdb              28.00 19426.00   29.00 4645.00   228.00 95132.00    40.80    18.68    4.00    0.97    4.02   0.12  56.80
sdc              62.00 19463.00   61.00 4660.00   492.00 95340.00    40.60    24.42    5.17    1.00    5.23   0.12  57.00
sdd              18.00 19463.00   39.00 4660.00   228.00 95340.00    40.68    19.39    4.13    0.15    4.16   0.11  53.70
md126             0.00     0.00  357.00 47782.00  1428.00 190468.00     7.97     0.00    0.00    0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              24.00  1261.00  275.00  127.00  1196.00  5348.00    32.56     0.10    0.26    0.11    0.59   0.24   9.80
sdb              55.00  1261.00   33.00  127.00   352.00  5348.00    71.25     0.09    0.54    0.30    0.61   0.52   8.30
sdc              61.00  1261.00  281.00  128.00  1368.00  5352.00    32.86     0.13    0.31    0.14    0.68   0.28  11.50
sdd              11.00  1261.00   38.00  128.00   196.00  5352.00    66.84     0.09    0.54    0.16    0.66   0.53   8.80
md126             0.00     0.00  775.00 2675.00  3100.00 10700.00     8.00     0.00    0.00    0.00    0.00   0.00   0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              75.00  1161.00   59.00  165.00   536.00  5040.00    49.79     0.11    0.51    0.29    0.59   0.48  10.70
sdb               4.00  1161.00   37.00  165.00   164.00  5040.00    51.52     0.11    0.52    0.14    0.61   0.52  10.60
sdc              58.00  1151.00   58.00  165.00   464.00  5000.00    49.00     0.12    0.54    0.31    0.62   0.50  11.20
sdd              23.00  1151.00   33.00  165.00   224.00  5000.00    52.77     0.10    0.50    0.18    0.56   0.50   9.90
md126             0.00     0.00  347.00 2510.00  1388.00 10040.00     8.00     0.00    0.00    0.00    0.00   0.00   0.00

首先，所有 IO 活动指标都降为零（我根本无法解释），然后我们看到一堆写入增加到avgqu-sz20，然后所有指标都恢复到典型值。

因此，我猜我们遇到的性能下降与每 1 分钟发生一次的 WiredTiger 检查点写入过程有关 ( docs )。

看起来写这么多数据花费的时间是合理的，但是为什么MongoDB在这个过程中不处理请求呢？我认为它应该在后台发生并且不应该影响当前正在执行的操作。

我们的应用程序使用 SQL Server 2014，我们遇到了与计划缓存相关的问题。

我们有一个参数化查询，它的执行计划取决于参数值。服务器缓存在某些情况下不是最佳的执行计划，然后将其用于所有后续查询。

细节：

我们有一个表由以下列组成：

(
 [Revision] [bigint] IDENTITY(1,1) NOT NULL,
 [UserId] [uniqueidentifier] NOT NULL,
 ...A WHOLE LOT OF OTHER COLUMNS...
)

这两列的意思很清楚，UserId是记录所属用户的Id，是记录Revision的自增索引。其他列并不重要，但它们存在并影响执行计划。

该表包含约 40.000.000 行和约 200.000 个不同的UserId值，因此每个用户平均有 200 条记录。行永远不会更新，我们只使用 INSERT 和 DELETE 来修改数据。

我们的应用程序对该表执行以下查询：

SELECT * FROM SampleTable WHERE Revision > {someRevision} AND UserId = {someId}

该表有两个索引：

1. 聚集索引：Revision asc
2. 非聚集索引：UserId asc, Revision asc

当我手动执行此查询时，我看到执行计划取决于someRevision.

• 如果它比较接近 Revision 的当前最大值，则服务器使用Clustered Index SeekwithSeek Predicate: Revision > someRevision

• 如果它不关闭，则服务器使用Index Seek (NonClustered)+Key Lookup (Clustered)和Seek Predicate: UserId = someId AND Revision > someRevision。

我们的应用程序使用 Linq-To-Sql 并生成参数化查询，它们看起来像这样：

exec sp_executesql N'SELECT * FROM [SampleTable] AS [t0]
WHERE ([t0].[Revision] > @p0) AND ([t0].[UserId] = @p1)',N'@p0 bigint,@p1 
uniqueidentifier',@p0=1234,@p1='bc38dd12-238c-41a2-9dea-bb12ce105e6d'

我使用dm_exec_cached_plans,并了解服务器将此查询的单个计划放入缓存中dm_exec_sql_text。dm_exec_query_plan因此，如果具有相应值的查询Revision首先出现，则使用的计划Clustered Index Seek将存储在计划缓存中，然后将用于所有后续查询。

它会导致过多的逻辑读取 (x10000) 和不可接受的查询执行时间，这些查询应该使用第二个计划 ( Index Seek (NonClustered)+ Key Lookup (Clustered)) 执行。

我还注意到服务器在计划之间切换的阈值（临界点）取决于统计信息，如果它是陈旧的，即使缓存不考虑，计划也可能是次优的，因为服务器错误地估计了Revision大于的行数给了一个。

此外，我们有大量具有相似用例的相似表，它们都有相同的问题。

我能做些什么来解决这个问题？

我可以尝试使用OPTION (RECOMPILE)，这对于 Linq-To-Sql 来说并不容易，但它在性能方面看起来也不是最优的。

我也可以更多地使用sp_create_plan_guide或破解 Linq-To-Sql 并尝试WITH (INDEX(...))使用第二个计划来强制使用，但正如我所说，有很多具有相同核心结构的表，所以这种方式看起来像很多手工工作.

一般来说，我的问题：

SQL Server 能否理解存储在缓存中的计划对于给定参数不是最佳的并且不使用它？

如果参数化查询的最佳执行计划取决于参数，是否有一些处理参数化查询的最佳实践？