我对ghost清理过程的理解是,它每5秒钟就会删除一个索引中的幻影记录.因此它不会使系统过载,它一次只能“清理”大约十页.
那么,这意味着它每五秒只能清理大约8万条记录吗？似乎我的索引总是充满了幻影记录,清理工作永远不会完成.
所以,假设我运行一个删除,可能是一百万行,这些数百万行的索引记录大小约为8Gb.所以差不多是80k的100,000倍.这是否意味着幽灵清理过程需要500,000s,或者差不多六天才能完成？
显然我在这里遗漏了一些东西,因为清除幻影记录需要很长时间才有意义.那个击中同一个指数的其他活动怎么样？ ghost清理过程会导致等待,还是必须等待其他进程？
[我们在OpsMgrDW中看到的性能问题带来了这个问题,我们希望了解更多有关此过程的信息]
解决方法
我写了两篇全面的博客文章来解释幽灵清理(它是唯一一个在任何地方深入解释的地方,无论是印刷版还是在线版).
第一个是Inside the Storage Engine: Ghost cleanup in depth,第二个是Ghost cleanup redux.是的,每次10页,鬼清理任务可能永远不会赶上大量的连续删除.
通过确保存储引擎“看到”鬼记录,可以积极地触发除10页 – 每5秒之外的Ghost清理.使用类似的方法强制扫描受影响的表或索引
select(from [problem-table] with(index = problem-index)
这将排除一个积极清理幽灵记录的请求.但要注意,它会产生大量的事务日志.它们也应该通过索引重建来清除,或者作为常规索引维护的一部分进行重组.
希望这可以帮助.
