Opengrok 在大基础上的优化答案

【问题标题】：Optimizing of Opengrok on large baseOpengrok 在大基础上的优化
【发布时间】：2022-06-10 21:04:46
【问题描述】：

我这里有一个服务器实例，它有 4 个内核和 32 GB RAM，并安装了 Ubuntu 20.04.3 LTS。在这台机器上，有一个 opengrok-instance 作为 docker 容器运行。

在 docker 容器内部它使用 AdoptOpenJDK：

OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
Eclipse OpenJ9 VM AdoptOpenJDK-11.0.11+9 (build openj9-0.26.0, JRE 11 Linux amd64-64-Bit Compressed References 20210421_975 (JIT enabled, AOT enabled)
OpenJ9   - b4cc246d9
OMR      - 162e6f729
JCL      - 7796c80419 based on jdk-11.0.11+9)

opengrok-indexer 扫描的代码库大小为 320 GB，耗时 21 小时。

我想出来的是，我已经禁用了历史选项，它花费的时间更少。如果设置了历史标志，是否有可能减少这个时间。

这是我的索引命令：

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"

提前感谢您的帮助。

亲切的问候

齐格飞

【问题讨论】：

你看过github.com/oracle/opengrok/wiki/Tuning-for-large-code-bases吗？
感谢您的回答。是的，我知道这个页面。从那里我有选项 -m 的提示。

标签： docker server configuration jvm opengrok

【解决方案1】：

您应该尝试使用以下选项增加线程数：

  --historyThreads number
    The number of threads to use for history cache generation on repository level. By default the number of threads will be set to the number of available CPUs.
    Assumes -H/--history.
    
  --historyFileThreads number
    The number of threads to use for history cache generation when dealing with individual files.
    By default the number of threads will be set to the number of available CPUs.
    Assumes -H/--history.

   -T, --threads number
    The number of threads to use for index generation, repository scan
    and repository invalidation.
    By default the number of threads will be set to the number of available
    CPUs. This influences the number of spawned ctags processes as well.

也看看“renamedHistory”选项。理论上“关闭”是默认选项，但这对索引时间有很大影响，因此值得一试：

  --renamedHistory on|off
    Enable or disable generating history for renamed files.
    If set to on, makes history indexing slower for repositories
    with lots of renamed files. Default is off.

【讨论】：