【发布时间】：2018-09-19 21:45:05
【问题描述】：
我正在编写实现 lruskips 参数的业务案例。我知道好处（而且它们可能相当大）。我不知道的是内存等方面的性能开销，我应该将其视为缺点。毕竟我们需要一个平衡的观点！ 开放边缘 10.2B08 未使用 Linux 修补的各种版本的 Windows。
【问题讨论】：
标签： openedge progress-db
【发布时间】：2018-09-19 21:45:05
【问题描述】：
该功能通过避免与维护 LRU 链相关的内务处理来消除开销。使用它不会增加任何内存需求，并且可以减少 CPU 消耗。
不是每次引用一个块到 LRU 链的头部，它只是每次 X 引用一次。因此，与其驱逐绝对是“最近最少使用”的块，不如驱逐“可能不是最近使用”的块。
唯一潜在的不利因素是，理论上，可能存在一种反常的情况，即将其设置得太高可能会导致一些糟糕的驱逐决定。 IOW 事情的“可能”部分结果是不真实的，因为您检查的频率不够高（您基本上已将 -B 管理转换为 FIFO 队列）。
例如，将其设置为 1000000 且 -B 为 1000 可能不是很聪明。 （但更大的问题可能是-B 1000）
假设您这样做了（设置 -lruskips 1000000 -B 1000）并且您的应用程序混合了“正常”访问以及一些执行某种顺序扫描以支持报告的后台进程。
报告内容将读取大量数据，而这些数据只会查看一次（或几次）。此数据将立即放置在队列的 MRU 端，并在读取新数据时移向 LRU 端。
即使它被频繁访问，“正常”数据的工作集也会被推送到 LRU 端，因为正在跳过访问计数器更新。使用较小的 -B 它将很快从末端脱落并被驱逐。然后下一次访问会导致IO发生，循环重新开始。
您将 -lruskips 设置得越高，您对这类事情就越敏感。 -lruskips 10 将消除 90% 的 lru 内务处理，应该是一个非常非常低风险的设置。 -lruskips 100 将消除 99% 的内务处理，并且仍然应该是非常低的风险（除非 -B 非常小）。除非您有一组非常特殊的情况，将其设置为高于 100 似乎几乎没有意义。你很容易陷入“收益递减”的境地，并可能将你的运气推向不正当的结果。
【讨论】：