Link Search Menu Expand Document Documentation Menu
文档

红线测试

--redline-test 命令使 OpenSearch Benchmark 能够自动确定您的 OpenSearch 集群在负载增加的情况下可以处理的最大请求吞吐量。它根据实时集群性能动态调整活动客户端的数量，有助于容量规划和识别性能退步。

当使用 --redline-test 标志时，OpenSearch Benchmark 会执行以下步骤：

  1. 客户端初始化：OpenSearch Benchmark 初始化大量客户端（默认：1,000）。您可以使用可选的 --redline-max-clients=<int> 标志覆盖此设置。
  2. 反馈机制：OpenSearch Benchmark 逐步增加活动客户端的数量。一个 FeedbackActor 会监控实时请求失败情况并相应地调整客户端计数。
  3. 共享状态协调：OpenSearch Benchmark 使用 Python 的多进程库来管理共享字典和队列，以实现进程间通信
    • 工作器创建客户端状态映射并与 WorkerCoordinatorActor 共享。
    • WorkerCoordinatorActor 聚合客户端状态并将其转发给 FeedbackActor。
    • FeedbackActor 增加客户端数量，直到检测到请求错误，然后暂停客户端，等待 30 秒，再恢复测试。

以下图片提供了红线测试架构的视觉概览。

Redline Overview

用法

要执行红线测试，请使用带有 --redline-test 标志的 execute-test 命令和定时测试程序。

此测试程序使用 keyword-terms 操作定义了一个定时工作负载。它分两个阶段运行：

  • 预热阶段：测试以预热期（warmup-time-period）开始，以在测量开始前稳定性能指标。这有助于避免因冷启动效应而使结果失真。
  • 测量阶段：在 time-period 期间，OpenSearch Benchmark 使用指定数量的客户端以 target-throughput（每秒请求数）发送请求。红线测试逻辑将从此基线扩展活动客户端的数量，以确定集群的最大可持续负载。

以下示例定时测试程序用作红线测试的输入，红线测试随后动态调整客户端负载，以找到您的集群在没有错误的情况下可以处理的最大请求吞吐量

{
  "name": "timed-mode-test-procedure",
  "schedule": [
    {
       "operation": "keyword-terms",
       "warmup-time-period": {{ warmup_time | default(300) | tojson }},
       "time-period": {{ time_period | default(900) | tojson }},
       "target-throughput": {{ target_throughput | default(20) | tojson }},
       "clients": {{ search_clients | default(20) }}
    }
  ]
}

运行以下命令，使用定时测试程序对您的 OpenSearch 集群启动红线测试：

opensearch-benchmark execute-test \
  --pipeline=benchmark-only \
  --target-hosts=<your-opensearch-cluster> \
  --workload=<workload> \
  --test-procedure=timed-mode-test-procedure \
  --redline-test

基于延迟或 CPU 的反馈

OpenSearch Benchmark 支持每个请求的 timeout 值，如果请求超出指定持续时间，则会取消该请求。您可以使用 --client-options=timeout:<int> 标志设置此值。默认值为 10 秒。

您可以调整此值以定义 OpenSearch Benchmark 在红线测试期间应容忍的最大请求延迟。例如，要确定您的集群在不超过 15 秒延迟的情况下可以处理的最高负载，请将客户端选项中的超时设置为 15。

红线测试除了支持延迟和请求错误监控外，还支持基于 CPU 的反馈。这有助于防止集群超出安全利用率限制。

要求

要在红线测试期间使用基于 CPU 的反馈，您的设置必须满足以下要求：

  • 必须配置指标存储。使用内存存储会导致以下错误：

    [ERROR] Cannot execute-test. Error in worker_coordinator (CPU-based feedback requires a metrics store. You are using an in-memory metrics store)
  • --redline-cpu-max-usage 标志是必需的。此标志设置测试期间每个节点允许的最大 CPU 使用率（以百分比表示）。
  • 当基于 CPU 的反馈处于活动状态时，node-stats 遥测设备会自动启用。

行为

红线 CPU 反馈循环具有以下行为：

  • FeedbackActor 以固定间隔查询指标存储，以检索每个节点的平均 CPU 使用率。
  • 如果任何节点超出由 --redline-cpu-max-usage 设置的阈值，系统将启动缩容。
  • 缩容后，actor 会等待一段时间，然后才会尝试再次扩容。

结果

在红线测试期间，OpenSearch Benchmark 提供详细日志，其中包含测试期间的扩展决策和请求失败。在红线测试结束时，OpenSearch Benchmark 会记录您的集群在没有请求错误的情况下支持的最大客户端数量。

以下示例日志输出表明红线测试检测到 keyword-terms 操作的错误率为 15%，并确定在发生错误之前集群的最大稳定客户端负载为 410。

[WARNING] Error rate is 15.0 for operation 'keyword-terms'. Please check the logs.
Redline test finished. Maximum stable client number reached: 410

配置提示和测试行为

使用以下可选命令标志可以更好地理解和自定义红线测试执行：

  • --redline-scale-step：指定在每次扩展迭代中要取消暂停的客户端数量。
  • --redline-scaledown-percentage：指定在发生错误时要暂停的客户端百分比。
  • --redline-post-scaledown-sleep：指定反馈 actor 在缩容后尝试扩容前等待的秒数。
  • --redline-max-clients：指定红线测试期间允许的最大客户端数量。如果未设置，OpenSearch Benchmark 将默认为测试程序中定义的客户端数量。

对于基于 CPU 的反馈

使用以下附加标志来配置基于 CPU 的反馈：

  • --redline-cpu-max-usage：（必需）在触发缩容之前，每个节点允许的最大 CPU 负载（以百分比表示）。
  • --redline-cpu-window-seconds：计算每个节点 CPU 使用率平均值的持续时间（秒）。默认值为 30 秒。
  • --redline-cpu-check-interval：CPU 使用率检查之间的时间间隔（秒）。默认值为 30 秒。
剩余 350 字符

有问题？。

想做贡献？ 或 。