首页 > 代码库 > 建索引时优化的观察和思考
建索引时优化的观察和思考
同事调整了IndexWriterConfig的maxThreadStates参数，发现性能有很大提升，原来之前一直没去注意这个东西。
addDocument时默认会调用ThreadAffinityDocumentsWriterThreadPool来获取线程锁,而这个线程池默认是8个线程，如果同时addDocument的线程多于8个，则线程处在等待锁的状态(一般是等最小竞争的>锁)，所以本质上要在indexwriterconfig中增加最大索引线程数。
Lucene中还存在一个FlushStallControl,用于平衡addDocument和flush之间的速度差,如果flushBytes + activeBytes > 2 * ramBytes，且flushBytes > 0,则addDocument线程被暂停，直到flush完成。这有一个启发，最好监控下等待时间,如果等待时间太长，是不是考虑硬盘换一下?
另外使用LogByteMergePolicy的确比LogDocMergePolicy好，原因是这样内存平稳一点，表现略好。RamBufferSize是个很微妙的参数,理论上越大,索引归并的趟数越少，有利于减少归并时间,对建索引本身速度的影响，考虑addDocument和flush的平衡这一瓶颈，如果硬盘使用ssd(即等待时间变得超短,而且很少等待)，段应该大一点好?这好像很难说清，从小索引测试结果来看，200M左右性能最好。
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。