elasticsearch 版本7.x
前段时间对es的的缓存比较感兴趣，源码稍微跟了下，看到了一个内存回收管理器 PageCacheRecycler，内部将内存以页为单位管理和回收，里面的设计有2点有点疑问：
1. 缓存一页大小是16KB，这个是处于什么考虑呢，为什么不采用4KB为单位
2. 并发recycler采用了分段锁的设计思路将其管理的页分成了n个slot，slot个数取决于CPU核数。 这块我觉得设计者的思路是和并行处理的线程数保持一致能够在请求线程数保持cpu核数以内的情况下避免锁竞争，但是如果线程数超过核数其实还是会产生一定竞争的，而且实际应用中感觉线程数肯定会超过CPU核数的（index, search,refresh等各个线程池应该都会用到这个回收器），有没有考虑设计成和当前线程数动态调整的一个比例，进一步缩小锁的粒度？
前段时间对es的的缓存比较感兴趣，源码稍微跟了下，看到了一个内存回收管理器 PageCacheRecycler，内部将内存以页为单位管理和回收，里面的设计有2点有点疑问：
1. 缓存一页大小是16KB，这个是处于什么考虑呢，为什么不采用4KB为单位
2. 并发recycler采用了分段锁的设计思路将其管理的页分成了n个slot，slot个数取决于CPU核数。 这块我觉得设计者的思路是和并行处理的线程数保持一致能够在请求线程数保持cpu核数以内的情况下避免锁竞争，但是如果线程数超过核数其实还是会产生一定竞争的，而且实际应用中感觉线程数肯定会超过CPU核数的（index, search,refresh等各个线程池应该都会用到这个回收器），有没有考虑设计成和当前线程数动态调整的一个比例，进一步缩小锁的粒度？
1 个回复
Charele - Cisco4321
赞同来自:
在缺省的并发recycler情况下，是指有8个队列来提供服务，