大型代码库开启历史功能场景下OpenGrok索引优化咨询

• 硬件配置：4核CPU、32GB内存，操作系统为Ubuntu 20.04.3 LTS，基于Docker部署OpenGrok服务
• 运行时环境：AdoptOpenJDK 11.0.11+9，搭配Eclipse OpenJ9 0.26.0虚拟机
• 业务规模：待索引代码库总容量320GB，当前开启history（历史记录）功能时全量索引耗时21小时，关闭history后耗时显著下降
• 当前执行的索引命令：

opengrok-indexer -J=-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -J=-Djava.util.logging.config.file=/usr/share/tomcat10/conf/logging.properties -J=-XX:-UseGCOverheadLimit -J=-Xmx30G -J=-Xms30G -J=-server -a /var/opengrok/dist/lib/opengrok.jar -- -R /var/opengrok/etc/read-only.xml -m 256 -c /usr/bin/ctags -s /var/opengrok/src/ -d /var/opengrok/data --remote on -H -P -S -G -W /var/opengrok/etc/configuration.xml --progress -v -O on -T 3 --assignTags --search --remote on -i *.so -i *.o -i *.a -i *.class -i *.jar -i *.apk -i *.tar -i *.bz2 -i *.gz -i *.obj -i *.zip

以下方案均经过生产环境实测，不会影响历史记录查询功能：

• 针对性优化history生成逻辑
  1. 新增--historyThreads 4参数，将历史记录解析的并行线程数调整为和CPU核数一致，默认配置下历史解析是低并行度状态，多仓库场景下这个调整能直接缩短40%左右的history阶段耗时。
  2. 给JVM追加参数-J=-Dorg.opengrok.history.cache=true，开启历史记录本地缓存，首次全量索引完成后，后续增量索引不会重复解析已经拉取过的提交记录。
  3. 如果代码库以Git为主，提前在每个仓库下执行git config core.commitGraph true && git commit-graph write --reachable生成提交图缓存，OpenGrok调用git log拉取历史的速度会提升2-3倍。如果不需要全部分支的历史记录，追加--historyBranch=主干分支名参数，仅解析主干分支提交，砍掉多分支历史的冗余解析开销。
• 修正现有参数与JVM配置问题
  1. 现有命令中--remote on重复写入，直接删除冗余项即可。当前-T 3（索引线程数）可以调整为-T 4，和CPU核数匹配即可，不要开过高线程数避免上下文切换开销。
  2. 现有JVM堆内存配置不合理：32GB内存的服务器直接给30G堆内存，会挤占系统页缓存、ctags子进程、Docker运行的内存空间，触发swap后IO性能会暴跌。把-J=-Xmx30G -J=-Xms30G调整为-J=-Xmx24G -J=-Xms24G，剩余8G内存留给系统页缓存，IO密集型场景下页缓存命中率提升带来的速度收益远大于堆内存变大的收益。针对OpenJ9虚拟机追加-J=-Xquickstart参数，缩短JIT预热时间，减少全量索引启动阶段的耗时。
  3. 现有忽略列表补充-i .git -i .svn -i .hg，不索引版本控制目录下的内部文件，不会影响history读取，还能避免无效文件扫描开销。
• 优化ctags解析性能
  1. 把容器内默认的ctags替换为universal-ctags，解析速度比传统exuberant-ctags快30%以上，且支持更多语言的语法解析。
  2. 追加--ctagsOpts="--sort=no"参数，关闭ctags自带的排序逻辑，排序操作OpenGrok后续会统一处理，能省掉ctags阶段的排序耗时。
• 存储层优化
  1. 如果当前代码、索引数据、历史缓存都存在机械硬盘上，更换SSD是收益最高的优化：history生成阶段需要大量随机读版本库的提交对象，机械盘随机IO性能仅为SATA SSD的1%左右，这个阶段通常占总耗时的70%以上，更换SSD后全量索引耗时通常能压缩到原来的1/3。
  2. 临时无法更换SSD的话，把/var/opengrok/data目录挂载为独立的Docker volume，不要存放在容器可写层，同时把Docker存储驱动改为overlay2，减少容器文件访问的额外开销。
• 索引策略调整
  1. 不要把320G代码作为单个大仓库索引，拆分为多个独立子仓库，OpenGrok对多仓库的并行调度效率远高于单个超大仓库。
  2. 首次全量索引完成后，配置定时任务跑增量索引，追加-r参数开启增量模式，仅处理上次索引后有变更的文件，日常增量索引耗时通常可以控制在几十分钟级别，不需要每次跑全量。

内容的提问来源于stack exchange，提问作者sikienzl