网络层请求断路器内存限制配置

配置项作用 #

network.breaker.inflight_requests.limit 配置项用于控制网络层飞行请求（in-flight requests）断路器的内存限制。

此断路器专门跟踪和处理网络上进行读写请求时分配的内存，防止网络传输层过度消耗内存导致系统崩溃。

配置项属性 #

配置路径: network.breaker.inflight_requests.limit
数据类型: ByteSizeValue（字节大小值）
默认值: 100%（堆内存的100%）
最小值: 理论上为 0（实际不应设为 0）
是否可选: 是
作用域: NodeScope（节点级别）
动态更新: 是（支持动态更新）

配置项详解 #

工作机制 #

In-Flight Requests 断路器

断路器类型: memory
持久性: TRANSIENT (临时性)
开销因子: 2.0 (默认)


内存跟踪流程:

HTTP 请求到达:
├── 获取 contentLength
├── 注册到断路器
├── 内存使用 += contentLength × overhead
└── 检查是否超过限制


网络传输:
├── 读取数据 → 注册内存
├── 写入数据 → 注册内存
└── 完成后释放内存


断路判断:
if (内存使用 > limit) {
    → 抛出 CircuitBreakingException ❌
    → 拒绝新请求
} else {
    → 继续处理 ✅
}

内存计算 #

实际内存占用计算

请求大小: contentLength
开销因子: overhead (默认 2.0)


估算内存:
estimatedMemory = contentLength × overhead


示例 1:
contentLength = 1MB
overhead = 2.0
estimatedMemory = 1MB × 2.0 = 2MB


示例 2:
contentLength = 10MB
overhead = 2.0
estimatedMemory = 10MB × 2.0 = 20MB


为什么需要 overhead:
├── JVM 对象头
├── 内部数据结构
├── 网络缓冲区
├── 并发访问开销
└── 保守估计确保安全

断路器触发 #

断路触发条件

当前状态:
已用内存: 900MB
限制: 1000MB
overhead: 2.0


新请求:
contentLength: 60MB
estimatedMemory: 60MB × 2.0 = 120MB


判断:
900MB + 120MB = 1020MB > 1000MB
    │
    ↓
触发断路 ❌
    │
    ↓
抛出 CircuitBreakingException
拒绝请求


请求完成后:
释放内存: -estimatedMemory
已用内存: 900MB - 120MB = 780MB
断路器恢复 ✅

配置建议 #

生产环境（默认） #

network:
  breaker:
    inflight_requests:
      limit: 100%  # 默认值

建议: 保持默认值 100%。使用全部堆内存。

内存受限环境 #

network:
  breaker:
    inflight_requests:
      limit: 50%  # 限制为堆内存的一半

建议: 设置为 50-75%。内存紧张时使用。

固定大小限制 #

network:
  breaker:
    inflight_requests:
      limit: 2gb  # 固定 2GB

建议: 设置具体大小。需要精确控制时使用。

严格限制 #

network:
  breaker:
    inflight_requests:
      limit: 25%  # 严格限制

建议: 设置为 25-30%。网络请求很小时使用。

代码示例 #

easysearch.yml 基础配置 #

network:
  breaker:
    inflight_requests:
      limit: 100%
      overhead: 2.0

内存受限配置 #

network:
  breaker:
    inflight_requests:
      limit: 50%
      overhead: 2.0

固定大小配置 #

network:
  breaker:
    inflight_requests:
      limit: 1gb
      overhead: 1.5

动态更新配置 #

PUT /_cluster/settings
{
  "transient": {
    "network.breaker.inflight_requests.limit": "75%"
  }
}

配置项	作用	默认值
`network.breaker.inflight_requests.limit`	内存限制	100%
`network.breaker.inflight_requests.overhead`	开销因子	2.0
`indices.breaker.total.limit`	总断路器限制	70%

性能影响分析 #

limit 设置	优点	缺点
25%	安全，内存充裕	可能拒绝正常请求
50%	较安全	中等限制
75%	平衡安全和能力	标准设置
100%（默认）	最大能力	无安全边际

并发请求影响 #

假设堆内存 4GB，overhead = 2.0

limit = 100% (4GB):
最大估算内存: 4GB
可处理: 约 2GB 实际数据 (4GB / 2.0)
并发大请求: 20 个 100MB 请求 ✅


limit = 50% (2GB):
最大估算内存: 2GB
可处理: 约 1GB 实际数据 (2GB / 2.0)
并发大请求: 10 个 100MB 请求 ⚠️


limit = 25% (1GB):
最大估算内存: 1GB
可处理: 约 500MB 实际数据 (1GB / 2.0)
并发大请求: 5 个 100MB 请求 ❌

使用场景 #

监控建议 #

监控指标

Nodes Stats API:
GET /_nodes/stats/breaker


响应:
{
  "nodes": {
    "breakers": {
      "inflight_requests": {
        "limit_size_in_bytes": 4294967296,
        "limit_size": "4gb",
        "estimated_size_in_bytes": 536870912,
        "estimated_size": "512mb",
        "tripped": 0,
        "overhead": 2.0
      }
    }
  }
}


关注:
├── estimated_size: 当前使用
├── limit_size: 限制大小
├── tripped: 触发次数
└── 使用率: estimated / limit

注意事项 #

默认值: 默认值为 100%，堆内存的 100%。
动态更新: 支持动态更新，修改后立即生效。
百分比计算: 百分比相对于堆内存大小。
overhead 影响: 实际限制要考虑 overhead 因子。
临时性: 断路器是 TRANSIENT 类型，请求完成后自动恢复。
配合 overhead: 应与 overhead 配置配合。
其他断路器: 需要与其他断路器协调配置。
监控重要: 必须监控断路器触发情况。
测试验证: 配置变更后应验证请求处理能力。
合理设置: 根据实际负载合理设置限制。

断路器协调 #

多个断路器的协调

inflight_requests (100%):
├── 网络层内存
├── 读写请求
└── 临时占用


parent (total):
├── 父级断路器
├── 控制总内存
└── 通常 70%


协调原则:
├── 子断路器之和不应超过父断路器
├── inflight_requests 占用一部分
├── 其他断路器占用剩余部分
└── 防止超额分配

标签

网络断路器内存管理保护机制