0

我有一个应用程序处理存储在 ESENT 中的大量数据（100 GB+）。该表的架构是：12 字节JET_bitColumnFixed键和JET_coltypLongBinary值，典型大小约为 2 KiB。页面大小设置为 32 KiB。我不会更改外部 long 值的默认 1024 字节大小阈值，因此我认为这些值主要存储在外部。

我对提高冷缓存查找和检索性能很感兴趣，因为这些操作是分批进行的，并且密钥是预先知道的。据我了解，JetPrereadKeys () API 旨在提高这种情况下的性能，但事实证明，无论有没有这个调用，我都看不到实际行为有任何变化。

更多详情如下：

  • 就我而言，JetPrereadKeys() 总是报告足够数量的预读密钥，等于我在调用 API 时提交的密钥数量。如文档中所述，提交的密钥已适当排序。

  • 我尝试了同步和异步两种方法，其中异步方法是：将预读调用发送到线程池，同时继续在当前线程上查找和检索数据。

  • 通过尝试JET_paramEnableViewCache和JET_paramEnableFileCache参数的所有可用组合，我尝试了 ESENT 的两种可用缓存模式，无论是使用 MMAP 还是专用页面缓存。

  • 除了一个小例外，我无法看到记录的 I/O 操作在有和没有预读的情况下有什么区别。也就是说，我希望此操作会导致（最好是异步）获取 B 树的必要内部节点。但我唯一看到的是从 JetPrereadKeys() 本身的堆栈中偶尔出现的同步小读取。读取的大小很小，从某种意义上说，我认为它不可能预取所有需要的信息。

  • 如果我调试 Windows Search 服务，我可以中断对 JetPrereadKeys() 的各种调用。因此，至少有一个真实世界的示例调用此 API，大概是出于某种原因。

  • 我所有的实验都是在机器重启后进行的，以确保数据库页面缓存为空。

问题：

  1. 在所描述的情况下，JetPrereadKeys() 的预期行为是什么？

  2. 如果我使用这个 API，我是否应该期望看到不同的 I/O 模式和更好的性能？我应该期望看到数据的同步预读还是异步预读？

  3. 是否有另一种方法可以通过以某种方式向 ESENT 暗示即将到来的批次来提高 I/O 性能？

4

1 回答 1

2

JetPrereadKeys() API 确实将读取同步到叶级别的父级，然后将所需键/记录所需的所有叶页面的异步 IO 排入队列......我认为这回答了 #2。如果您的主表记录（注意突发长值/LV 存储在单独的树中）很浅或完全缓存，则此 JetPrereadKeys() 可能无济于事。但是，如果您在表上的主树又大又深，那么这个 API 可以提供很大帮助……它只取决于您正在检索的数据的形状和分布。您可以通过倾倒空间并查看树的深度并了解“数据”页面来了解有关您的表的一些基础知识，我可能会建议：

esentutl /ms Your.Db /v /fName,Depth,Internal,Data

列出表名、深度、内部页数和叶级数据页数。将按表名为主记录树列出单独的行，然后在其下方将 LV/ 作为“[Long Values]”列出。

另请注意，此预读键也不会扩展到突发 LV ......所以再次，如果您立即读取突发 LV 列 - 不幸的是，您将固定在 IO 后面。

默认模式是 ESE 以独占方式分配和控制自己的数据库缓冲区/页面缓存。JET_paramEnableFileCache 主要用于（通常较小的）客户端进程退出（或至少 JetTerm/JetDetach 他们的 DB）并重新启动很多......所以 ESE 的私有缓冲区缓存将在每次退出时丢失......但 JET_paramEnableFileCache 是一个参数，因此如果他们最近退出，数据可能仍然在文件缓存中。但不建议用于大型 DB，因为这会导致数据在 ESE 缓冲区缓存和 NTFS / ReFS 文件缓存中双重缓存。JET_paramEnableViewCache 增强了先前的参数，并在一定程度上改善了这种双重缓存......但它只能在干净/未修改的页面缓冲区上节省内存/不能双重缓冲区。对于大型数据库，将这两个参数都保留为关闭/错误。此外，如果您不使用这些参数，那么测试冷性能会更容易......只需在您的应用退出后在您的 HD 上复制一个大（100 MB，可能 1 或 2 GB）文件（以清除 HD缓存），并且您的数据将是冷的。;-)

因此，既然我们已经提到了缓存...最后一件事-我认为这可能是您的实际问题（如果不是我上面提到的“数据形状”）...打开 perfmon 并找到“数据库”和/或“数据库 ==> 实例”性能对象（这些用于 ESENT）并查看您的缓存大小有多大 [“数据库缓存大小”或“数据库缓存大小 (MB)”] 并查看您的可用池有多大is / ["Database Cache % Available"]...您当然必须采用此 % 并根据您的数据库缓存大小进行数学运算以了解...但是如果这很低，这可能是您的问题。 .. 这是因为 JetPrereadKeys 只会使用已经可用的缓冲区，所以你必须有一个健康/足够大的可用池。要么增加 JET_paramCacheSizeMin 更大，

paramCacheSizeMin = 500
paramCacheSizeMax = 100000
paramStartFlush.. =   1000
paramStopFlushT.. =   2000

这意味着您的开始和停止阈值分别是当前缓存大小的 1% 和 2%，无论它碰巧是什么。因此，如果缓存为 500 个缓冲区（分钟），则 5 和 10 将是您的开始/停止阈值 - 即您的可用池的范围，如果稍后它增长到 10000 个缓冲区，那么您的可用池将介于 100 和 200 之间缓冲区。无论如何，您希望这些数字足够好，以便为 JetPrereadKeys 可能需要的所有叶页提供足够的缓冲区。

我没有解释这封电子邮件中的每个术语，因为您在上面看起来非常先进 - 谈论 B-tree 内部节点等......但如果有什么不清楚的地方，请问我会澄清它。

谢谢，

布雷特雪莉 [MSFT]

可扩展存储引擎开发人员

此帖子“按原样”提供，不提供任何保证，也不授予任何权利。

PS - 您可能喜欢玩的最后一件事：JetGetThreadStats / JET_THREADSTATS，它告诉您我们在 API 下执行的一些内部操作。您基本上读取 JET API 之前和之后的值，然后减去它们以获得该 JET API 的操作数。所以你会在那里看到 cPagePreread ......这将是查看 JetPrereadKeys 是否正在调度应该有助于提高性能的异步 IO 的好方法。请注意，不幸的是，特定计数器在较旧的操作系统中被破坏了，但我不记得它何时被破坏和修复......从win7到win8，从win8到win8.1。如果你在Win10上，那么没问题，到那时它肯定已经修复了。;-) 而且 cPageRead 是同步读取页面（内部节点可能会上升）...我认为您会发现这些对于各种 JET API 的成本非常有指导意义。

于 2020-01-15T22:50:44.423 回答