binbin.zhang
binbin.zhang
> 执行 destroy 命令报错这个是需要优化的。我们还需要排查是否是被系统 oomkiller 杀掉。请提供linux 系统版本和内核版本。 和tiny-x沟通过，在1.6.1版本中不支持在容器内直接故障注入，可能是因为这个原因导致到。后面在1.6.2版本中可以兼容回来
> Use current lastest version 1.4.0. Likewise, gopsutil is still 2.20.5 in spec-go 1.4.0
Maybe we can consider that when filling the disk, if the input size is larger than the available space of the disk, dd is preferred. Otherwise, fallocate is used to...
实际上在计算出start和end后，会根据格子的开始时间与start和end进行匹配。 如下图所示：统计间隔=1000ms（跨两个格子），now=1300时 计算出start=500,end=1000, 那么在计算sum时，会根据如下条件遍历格子，也就会找到开始时间是500和1000的两个格子，那么统计的时候1000的这个格子中的数据自然也会被统计到。（当前时间1300，在1000的这个格子中） ```golang satisfiedBuckets := m.real.ValuesConditional(now, func(ws uint64) bool { return ws >= start && ws
个人理解当前的实现方式确实不能得到最佳的并发请求量，因为探测带宽和时延在tcp bbr中是需要发数据包进行探测,而sentinel是一个sdk无法去主动探测带宽和时延，所以看到sentinel-go代码中的函数命名`checkBbrSimple`也可以理解，这是一个简单的bbr实现。
是的，目前这个叫系统自适应限流，从支持的采集类型来看有load,avgrt等等都是根据系统整体维度进行统计的。系统自适应可以和flow流量控制配合使用 达到对系统和对接口都有限流的能力。系统自适应限流更适合用于兜底。
> > CI 处理一下吧，有data race > > 删除 once 导致的，是否不应该删除呢？ 嗯嗯，目前看还是使用once吧
How to clean up the rules？ Did you delete the rules file or did you empty the contents of the rules file？
@tylitianrui Could you please fix the CI failure?
The following options can be considered. record the last retry time,when getting retryTimeoutArrived, change to > func (b *circuitBreakerBase) retryTimeoutArrived() bool { > now:=util.CurrentTimeMillis() > return now>= atomic.LoadUint64(&b.nextRetryTimestampMs) && now-...