常规处理增强功能

以下调整通过提高具有多个文档的集合的总体吞吐量来减少装入和开始处理文档所花费的时间量。

当没有任何扩充项应用于文档时，这些设置是最佳设置。 但是，不同的项目类型会自动将不同的扩充项应用于其集合。 缺省情况下，仅 定制 项目类型不应用任何扩充项。 要对应用了扩充项的集合进行调整，请参阅 改进扩充项处理。

对于包含 20,000 个或更多文档的集合，请尝试以下调整:

• 增大 PostgreSQL pod 的内存限制和 sharedBuffer 大小。
• 将 Gateway pod 的 Java 堆大小，内存和 CPU 限制的大小加倍。
• 将采集 API pod 的采集 API 容器的内存限制和 Java 堆大小加倍。
• 将 Java 堆大小增加一倍，并将采集 API pod 的采集容器的 CPU 和内存限制增加 4 倍。

以下 YAML 摘录显示了应用这些更改的样本定制资源补丁文件:

cat <<EOF | oc patch wd wd --type=merge --patch -
spec:
  api:
    api:
      wlpMaxHeap: 1024m
      resources:
        limits:
          memory: 2Gi
          cpu: "4"
  coreapi:
    ingestionApi:
      wlpMaxHeap: 2048m
      resources:
        limits:
          memory: 2Gi
      ingestion:
        resources:
          limits:
            cpu: "2"
            memory: 4Gi
  postgres:
    database:
      resources:
        limits:
          memory: 8Gi
      sharedBuffer: 2048MB
EOF

改进浓缩处理

将扩充项应用于集合时，需要更多资源来处理文档。 某些项目类型会自动将扩充项应用于其集合。 例如，如果创建 Document Retrieval 项目类型，那么 Part of Speech 和 Entities 扩充项将应用于集合。

Discovery 的缺省配置针对每个集合使用一个 hdp-worker pod 来处理扩充项。 当您将数据采集到单独的集合中时，将以并行方式处理每个集合。 增加 hdp-worker pod 的数量允许同时处理更多集合。 但是，如果仅将文档添加到一个集合，或者需要处理每个集合的扩充项以加快速度，那么增加 hdp-worker pod 的数量将不会提高性能。 而是必须更改 docproc job number 参数值。

要增加同时在同一 hdp-worker pod 上运行的扩充作业数，请增大 docproc job number 参数值。 更改 docproc job number 值时请小心。 请缓慢增大该值，并检查其影响。 例如，将值从 1 增大到 2，然后监视 pod 中的潜在内存问题。 如果未发生任何问题，那么可以增加 2 的增量值。 同样，在每次更改后，请注意潜在问题。 如果由于缺少内存而导致某些文档的摄入开始失败，那么可以减小 docproc job number 参数的值或增大 hdp-worker memory 参数的值。

来自工作程序 pod 的结果将发送到 Elasticsearch 服务 pod 以建立索引。 当您增加扩充处理的并行性时，将同时向索引器 pod 发送更多文档。 因此，您可能需要增加索引器 pod 的大小以处理更高的卷。

除了常规处理增强设置之外，您还可以尝试进行以下调整，以优化应用了扩充项的集合的摄入:

• 将 Java Docproc 作业最大内存大小和索引文档批处理大小加倍。
• 增加可以对每个集合执行的 Docproc 作业号。
• 加倍索引器 pod 的 Java 堆大小，内存和 CPU 限制和副本。
• 将 Elasticsearch Data Node pod 的 Java 堆大小，内存和 CPU 限制和副本加倍。

以下 YAML 摘录显示了应用这些更改的样本定制资源补丁文件:

cat <<EOF | oc patch wd wd --type=merge --patch -
spec:
  postgres:
    database:
      resources:
        limits:                               
          memory: 8Gi                         
      sharedBuffer: 2048MB                    
  hdp:
    worker:
      replicas: 6                             
      resources:
        limits:
          cpu: "16"                           
          memory: 36Gi                        
        requests:
          cpu: "6"                            
          memory: 24Gi                        
  orchestrator:
    esPublishBatchSize: 400                   
    esPublishDataSizeThreshold: "20"          
    docproc:
      maxMemory: 4g                           
      workerNum: "10"                         
  foundation:
    indexer:
      replicas: 4                             
      javaOptions: "-Xmx4096m -Xms512m"       
      resources:
        limits:
          cpu: "2"                            
          memory: 8Gi                         
  elasticsearch:
    dataNode:
      replicas: 4
      maxHeap: 8g
      resources:
        limits:
          cpu: "4"
          memory: 16Gi
EOF

改进智能文档理解处理

将“智能文档理解”(SDU) 模型应用于集合时，需要其他额外资源来处理文档。 某些项目类型会自动将 SDU 模型应用于其集合。 例如，如果创建 针对合同的文档检索 项目类型，那么 SDU 扩充项将应用于集合。

如果将用户训练的或预训练的智能文档理解 (SDU) 模型应用于大型集合，那么可以增加 hdp-worker pod 的数量，以减少处理文档所需的时间。 hdp-worker pod 需要大量核心和内存才能启动。 请确保根据集群中可用的工作程序节点的大小和数量来检查所请求的副本数，以确保您有足够的节点来处理需求。

尝试对应用了 SDU 模型的集合进行以下调整:

• 以 2 为增量增加 hdp-worker 副本数。 例如，从 4 转至 6，然后观察问题。

改进图像处理

为集合启用光学字符识别 (OCR) 是一项昂贵的操作。 仅当您知道文档中感兴趣的区域位于图像时，才会将 OCR 应用于集合。 如果您的文档未包含任何图像，或者这些图像在本质上大多具有样式，那么它们是没有相关文本的徽标或图片，例如，在集合上禁用 OCR。