沉浸式工作

Posted on by 8 Comments

我发现屏幕上会动的东西都会吸引注意力，现在每天又收到很多消息，只要一个小时不看肯定会上百条。这样的工作状态很糟糕，一开始我强迫自己不要去关注未读消息数量，但是尝试了一段时间之后还是发现会不集中注意力。

最好的方法还是全部屏蔽掉实时的消息，在工作中用 IM 是一个很糟糕的主意，很多同事请 SRE 帮助的时候描述不清楚自己的问题，就导致发过去一条消息还要等他的回复。

也尝试过屏蔽一些消息，但是发现屏蔽不过来，总是有新的群拉起来，默认消息就是推送的，也会有新的陌生人过来问一些问题。

如果 IM 工具有“加急”的功能，那么总有一天，人们发送的所有消息都是“加急”的。

既然用户不喜欢使用提交 ticket，那么我们可以把 IM 用成 ticket。

我发现 Dozer 是网友推荐的一个非常好用的工具，它可以将 Mac 的 Toolbar 上面的活动图标给隐藏掉。

专心工作的时候，只需要留两个图标，一个是时间，另一个是每 30 分钟提醒站立的程序。

而且这个软件的 UI 设计的非常天才，只用两个点就可以完成全部操作。正好满足我的需求：隐藏掉 Toolbar 上面可以动的东西。

这样，只需要在工作的间隙定时去检查 IM 消息就好了。将全部 IM 回复一遍，如果无法一次性将问题描述清楚，就只要等待下一次沟通了。

另外一个烦人的地方是，别人 @我的时候，App 的图标会在 Dock 上跳一下。禁止所有的 App 跳动，可以用下面这两个命令：

  1. defaults write com.apple.dock no-bouncing -bool TRUE
  2. 然后让 Dock 重启一下：killall Dock

这样，专心工作的时候，屏幕上就没有会动的东西了。

 

用 PromQL 计算 SLI 和 SLO

Posted on by 2 Comments

用 PromQL 查询出来过去一个月中用掉的 Error budget，然后展示当前的 SLI。效果如下图所示：

这个查询的难点在于，PromQL 查询出来的内容都是时序的值，比如 memory > 0.6 这个查询，查到的所有满足条件的时序的时间和值的对应。让查询的结果是时间，就需要一些技巧。

实现的思路是：

  1. 首先定义分钟级的 up 标准，即 SLO 的定义：1min中如何算是 up 的，如何算是 down 的；
  2. 然后写一个查询，可以查到在一个时间区间内，有多少个分钟是满足条件，up 的，有多少分钟是 down 的；
  3. 最后就可以得到实时的 SLI 结果；

想到有两个思路能实现。

第一个是利用 recording rules. 首先要定义一个 rule 叫做 job:sla_minute_up，这个 rule evaluation 的结果是当前的这一分钟是否满足 up 的所有条件。所以可能是一个很多 and 连起来的复杂表达式。

然后我们只要将所有 up 的分钟数加起来即可，即 sum_over_time(job:sla_minute_up[30d])。最后除以一个月中所有的分钟数：sum_over_time(job:sla_minute_up[30d]) / 30 * 24 * 60，就是最后得到的 SLI。

但是这里面有一个特别重要的地方，就是 sum_over_time 计算的是这段时间内所有出现过的点。比如，假设采集间隔是 15s，那么 up 这个 metric 在每分钟内会有 4 个点，sum_over_time(up[1m]) 正常情况的结果应该是 4. 所以说，使用这种方法的话，recording rules 的 evaluation internal 必须设置为 60s，来做到每分钟只有一个点。

这种方式实际的结果和计算过程绑定了， 所以并不是很好，下面这种方法更巧妙一些。

我们可以换一个思路，直接计算这段时间内满足条件的百分比，然后百分比乘以时间段，就是最终的 up time。

得到这个百分比，首先依然是需要分钟级的 up 定义。不过我们关心的并不是具体的 value，而是是否满足条件，即非是即否。使用 >bool 这个运算，可以将结果转化成 bool，如果满足条件，结果就是1，不满足，结果就是0. 这样，我们只需要计算这段时间内的平均值，就可以得到 SLI 的百分比了。比如说，如果全部是 up，那么结果全部都是1，那么所有时间内的平均是100%。如果出现了不是 up 的点，那么按照占用所有的点的百分比，也是对的。

这个方法就和 interval 无关了。interval 越小，数据点就多，精度会提高。interval 大，那么精度会损失。从客观来讲，表示的真实 SLI 在去掉精度后都是正确的。

如果要表示一天内的 SLI，假设 SLO 只有错误率的话，就可以用下面的查询（假设我们把错误率认为小于1%就是 up）：

也可以和 Grafana 配合，使用 Grafana 选中的时间区间：

 

参考资料：

  1. https://stackoverflow.com/questions/54292803/calculate-the-duration-in-which-a-prometheus-metric-had-a-certain-value
  2. https://docs.bitnami.com/tutorials/implementing-slos-using-prometheus
 

用 Wireshark 分析 TCP 吞吐瓶颈

Posted on by 18 Comments

Debug 网络质量的时候，我们一般会关注两个因素：延迟和吞吐量（带宽）。延迟比较好验证，Ping 一下或者 mtr 一下就能看出来。这篇文章分享一个 debug 吞吐量的办法。

看重吞吐量的场景一般是所谓的长肥管道(Long Fat Networks, LFN, rfc7323). 比如下载大文件。吞吐量没有达到网络的上限，主要可能受 3 个方面的影响：

  1. 发送端出现了瓶颈
  2. 接收端出现了瓶颈
  3. 中间的网络层出现了瓶颈

发送端出现瓶颈一般的情况是 buffer 不够大，因为发送的过程是，应用调用 syscall，将要发送的数据放到 buffer 里面，然后由系统负责发送出去。如果 buffer 满了，那么应用会阻塞住（如果使用 block 的 API 的话），直到 buffer 可用了再继续 write，生产者和消费者模式。

图片来自 cisco

发送端出现瓶颈一般都比较好排查，甚至通过应用的日志看何时阻塞住了即可。大部分情况都是第 2，3 种情况，比较难以排查。这种情况发生在，发送端的应用已经将内容写入到了系统的 buffer 中，但是系统并没有很快的发送出去。

TCP 为了优化传输效率（注意这里的传输效率，并不是单纯某一个 TCP 连接的传输效率，而是整体网络的效率），会:

  1. 保护接收端，发送的数据不会超过接收端的 buffer 大小 (Flow control)。数据发送到接受端，也是和上面介绍的过程类似，kernel 先负责收好包放到 buffer 中，然后上层应用程序处理这个 buffer 中的内容，如果接收端的 buffer 过小，那么很容易出现瓶颈，即应用程序还没来得及处理就被填满了。那么如果数据继续发过来，buffer 存不下，接收端只能丢弃。
  2. 保护网络，发送的数据不会 overwhelming 网络 (Congestion Control, 拥塞控制), 如果中间的网络出现瓶颈，会导致长肥管道的吞吐不理想；

对于接收端的保护，在两边连接建立的时候，会协商好接收端的 buffer 大小 (receiver window size, rwnd), 并且在后续的发送中，接收端也会在每一个 ack 回包中报告自己剩余和接受的 window 大小。这样，发送端在发送的时候会保证不会发送超过接收端 buffer 大小的数据。（意思是，发送端需要负责，receiver 没有 ack 的总数，不会超过 receiver 的 buffer.）

图片来自 cisco

对于网络的保护，原理也是维护一个 Window，叫做 Congestion window，拥塞窗口，cwnd, 这个窗口就是当前网络的限制，发送端不会发送超过这个窗口的容量（没有 ack 的总数不会超过 cwnd）。

怎么找到这个 cwnd 的值呢？

这个就是关键了，默认的算法是 cubic, 也有其他算法可以使用，比如 Google 的 BBR.

主要的逻辑是，慢启动(Slow start), 发送数据来测试，如果能正确收到 receiver 那边的 ack，说明当前网络能容纳这个吞吐，将 cwnd x 2，然后继续测试。直到下面一种情况发生：

  1. 发送的包没有收到 ACK
  2. cwnd 已经等于 rwnd 了

第 2 点很好理解，说明网络吞吐并不是一个瓶颈，瓶颈是在接收端的 buffer 不够大。cwnd 不能超过 rwnd，不然会 overload 接收端。

对于第 1 点，本质上，发送端是用丢包来检测网络状况的，如果没有发生丢包，表示一切正常，如果发生丢包，说明网络处理不了这个发送速度，这时候发送端会直接将 cwnd 减半。

但实际造成第 1 点的情况并不一定是网络吞吐瓶颈，而可能是以下几种情况：

  1. 网络达到了瓶颈
  2. 网络质量问题丢包
  3. 中间网络设备延迟了包的送达，导致发送端没有在预期时间内收到 ACK

2 和 3 原因都会造成 cwnd 下降，无法充分利用网络吞吐。

以上就是基本的原理，下面介绍如何定位这种问题。

rwnd 查看方式

这个 window size 直接就在 TCP header 里面，抓下来就能看这个字段。

但是真正的 window size 需要乘以 factor, factor 是在 TCP 握手节点通过 TCP Options 协商的。所以如果分析一条 TCP 连接的 window size，必须抓到握手阶段的包，不然就不可以知道协商的 factor 是多少。

cwnd 查看方式

Congestion control 是发送端通过算法得到的一个动态变量，会实时调整，并不会体现在协议的传输数据中。所以要看这个，必须在发送端的机器上看。

在 Linux 中可以使用 ss -i 选项将 TCP 连接的参数都打印出来。

这里展示的单位是 TCP MSS. 即实际大小是 1460bytes * 10.

Wireshark 分析

Wireshark 提供了非常实用的统计功能，可以让你一眼就能看出当前的瓶颈是发生在了哪里。但是第一次打开这个图我不会看，一脸懵逼，也没查到资料要怎么看。好在我同事会，他把我教会了，我在这里记录一下，把你也教会。

首先，打开的方式如下：

然后你会看到如下的图。

首先需要明确，tcptrace 的图表示的是单方向的数据发送，因为 tcp 是双工协议，两边都能发送数据。其中最上面写了你当前在看的图数据是从 10.0.0.1 发送到 192.168.0.1 的，然后按右下角的按钮可以切换看的方向。

X轴表示的是时间，很好理解。

然后理解一下 Y 轴表示的 Sequence Number, 就是 TCP 包中的 Sequence Number，这个很关键。图中所有的数据，都是以 Sequence Number 为准的。

所以，你如果看到如上图所示，那么说明你看反了，因为数据的 Sequence Number 并没有增加过，说明几乎没有发送过数据，需要点击 Switch Direction。

这就对了，可以看到我们传输的 Sequence Number 在随着时间增加而增加。

这里面有 3 条线，含义如下：

除此之外，另外还有两种线：

需要始终记住的是 Y 轴是 Sequence Number，红色的线表示 SACK 的线表示这一段 Sequence Number 我已经收到了，然后配合黄色线表示 ACK 过的 Sequence Number，那么发送端就会知道，在中间这段空挡，包丢了，红色线和黄色线纵向的空白，是没有被 ACK 的包。所以，需要重新传输。而蓝色的线就是表示又重新传输了一遍。

学会了看这些图，我们可以认识几种常见的 pattern：

丢包

很多红色 SACK，说明接收端那边重复在说：中间有一个包我没有收到，中间有一个包我没有收到。

吞吐受到接收端 window size 限制

从这个图可以看出，黄色的线（接收端一 ACK）一上升，蓝色就跟着上升（发送端就开始发），直到填满绿色的线（window size）。说明网络并不是瓶颈，可以调大接收端的 buffer size.

吞吐受到发送端 Buffer 的限制

为什么发送端也会限制带宽呢？如果你要榨干线路上所有的性能，那么就要了解一个概念：BDP。

BDP = bandwidth * RTT

为什么这个概念很重要呢？因为 TCP 是一个可靠的协议，这就意味着它要保证发送的每一个 byte 都被 ACK，并不是发送出去就可以了。所以 sender buffer 的作用，不光是程序将要发送的内容传送给 Kernel，Kernel 要在 buffer 中存储这些数据，直到被接收端 ACK。

Buffer 需要多大才会不成为瓶颈呢？就是足够大能存放住所有未被 ACK 的数据。那么没有被 ACK 的数据最大是多大呢？其实就是 BDP。比如带宽是 10Mib/s, RTT 是 1s，那么 BDP 就是 10Mib/s * 1s = 10Mib，这个连接上最多可能有 10Mib 的数据没有被 ACK，发送端的容量必须比这个大才行（如果你要完全利用网络资源的话）。

下面是一个 Buffer 不足够大的例子：

可以看到绿线（接收端的 window size）远没有达到瓶颈，但是发送端的模式不是一直发， 而是发一段停一段。就说明发送端的 buffer 已经满了，这时候 Kernel block 住了 App，必须等这些数据被 ACK 了，才能让 App 继续往 buffer 中塞入数据。

那么怎么和下面要介绍的被 cwnd 限制了区分开呢？两种模式比较相似。

可以看一开始蓝色线的垂直距离很短，后面逐渐变长，说明 cwnd 在变大，然后变大到一定的成都不变了。说明 cwnd 没成为瓶颈。

在 Wireshark 中可以切换到 Window scaling 图。

可以发现 cwnd 并没有收缩回去。

在 window scaling 图中，绿色的是 Rcv Win, 蓝色的是 Bytes out. 蓝色线每次发送数据 burst 到某一个最高点就不再上升了。但是上升的过程也没有下降过，“没有下降过”就可以说明，cwnd 没有下降过，即 cwnd 没有成为瓶颈。

吞吐受到网络质量限制

从这张图中可以看出，接收端的 window size 远远不是瓶颈，还有很多空闲。但是发送端不会一直发直到填满接收端的 buffer。

放大可以看出，中间有很多丢包和重传，这会让发送端认为网络质量不好，会谨慎发送数据，想避免造成网络拥塞。发送端每次只发送一点点数据，发送的模式是发一点，停一点，然后再发一点，而不是一直发。这也说明很有可能是 cwnd 太小了，受到了拥塞控制算法的限制。

下面这种模式是一种更加典型的因为丢包导致带宽很小的问题：

从这个图中我们可以发现以下信息：

  1. 在这个链接中，Flow Control（即 Linux 中的 tcp buffer 参数，绿色线）远远没有达到瓶颈；
  2. 图中有很多红色线，表示 SACK，说明图中有很多丢包；
  3. 蓝色线表示发送的数据，发送的模式是，每隔 0.23s 就发送一波，然后暂停，等 0.23s 然后再发送一波。蓝色线在 Y 轴上表示一次性发送的数据，可以看到，每一段的纵向长度在不断减少。从中，我们可以得到以下信息：
    1. 0.23s 是物理上的延迟；
    2. 蓝色线没有一直发送，而是发送，暂停，发送，暂停，是因为拥塞控制算法的窗口（cwnd）变小了，每次发送很快填满窗口，等接收端（0.23s之后）收到了，再继续发送；
    3. 并且蓝色线的纵向距离每一波都在减少，说明这个窗口在每次发生丢包之后都在变小（减为一半）。

完美的 TCP 连接

最后放一张完美的 TCP 连接（长肥管道），发送端一直稳定的发，没有填满 receiver window，cwnd 也没有限制发送速率。这个完美连接的带宽是 10Mib/s，RTT < 1ms, 可以看到2s发送的 Sequence nunber 是 2500000，计算可以得到 2500000 / 1024 / 1024 * 8 / 2 = 9.535Mib/s，正好达到了带宽。

本文中用到的抓包文件可以从这里下载(credit: https://www.youtube.com/watch?v=yUmACeSmT7o):

  1. https://www.cloudshark.org/captures/f5eb7c033728
  2. https://www.cloudshark.org/captures/c967765aef38

其他的一些参考资料：

  1. https://www.stackpath.com/edge-academy/what-is-cwnd-and-rwnd/
  2. https://www.baeldung.com/cs/tcp-flow-control-vs-congestion-control
  3. https://www.cs.cornell.edu/courses/cs4450/2020sp/lecture21-congestion-control.pdf
  4. https://www.mi.fu-berlin.de/inf/groups/ag-tech/teaching/2011-12_WS/L_19531_Telematics/08_Transport_Layer.pdf
  5. https://wiki.aalto.fi/download/attachments/69901948/TCP-CongestionControlFinal.pdf
  6. https://paulgrevink.wordpress.com/2017/09/08/about-long-fat-networks-and-tcp-tuning/

帮这位老师的项目打一个广告：https://github.com/royzhr/spate 一个大流量网络性能测试工具。

 

开源的世界如此之小？！

Posted on by Leave a comment

今天想基于前两天有用户提交的 PR 做一下 iredis 的 TLS feature，然后突然发现 iredis 的 master 分支不能 build 了。fail 的 action

为了防止 action 日志失效，这里放一个截图

错误也非常莫名其妙，我什么时候就拿 None 和 String 比较了呢？

主要是前两天用户提交的 PR 完全 pass 了我才 merge 的呀，怎么 merge 到 master 之后就不行了呢？

隐约感觉是有什么依赖 broke 了，如果直接 diff 之前安装的依赖可能定位会快一些（这就是为啥我每次会在 CI 里面先打一行 pip list 的原因！）但是这次我想直接去找找是什么问题，闲着也是闲着。

那就直接先从出错误的 poetry 入手，我直接在它的代码里面加入了很多 print（Python 的优势，直接改安装的包就行）。然后不断缩小范围，发现 poetry-core 的代码中，有一个 copy.copy，copy 之后的内容和之前的不一样：

于是开始研究这个 copy 的对象有啥特殊的，发现是 tomlkit 里面的一个对象。不是一个简单的 list。

然后跳到 tomlkit 里面去看这个对象，发现是一个自定义的 list，代码有一些长，花了一些时间读明白之后发现，它解析之后为了保持格式问题，会加一个 Null 的 dummy 对象占位。本来这个 dummy 不会在 value 里面的，但是一经过 copy 的时候，__init__ 并没有过滤掉 Null，就导致这个 None 被加进去了。

提交了一个 PR 修复：https://github.com/sdispater/tomlkit/pull/221

这都不是重点，重点是，这个 bug 不是很好触发：

  1. 需要使用 copy.copy，除了 copy 我想不到其他的场景会出现这个问题，而 poetry 正好用到了，并且 copy 的是 classifier；
  2. 需要在 toml 的被 copy 的 list 里面有一些 Comment，而我的 iredis 里面，我之前为了给自己备忘去哪里找 classifier 列表正好写了一行 comment；

这些还不是重点，重点是我去看了一下这个仓库，发现代码的问题是在两天前引入的，而两天内正好让我给触发了。

这些依然不是重点，重点是，这段代码的作者，居然正是我的明哥（@frostming）！！！

 

Golang 的 Channel 是一种免费的无锁实现吗？

Posted on by 1 Comment

今天看到一段代码，是用 Prometheus 的 client_go 暴露 metrics 的代码。里面不是简单的将对应的一个 metric counter inc()的操作，而是自己实现了一个非常奇怪的逻辑：

  1. 当程序需要将 counter +1 的时候，没有直接操作对应的 metrics，而是将要增加的 metrics 用自己的格式打包出一个对象，然后将对象发送到一个 channel，每一个 metric 都对应一个 channel
  2. 程序启动之初就会启动全局唯一的 worker goroutine, 这个 goroutine 负责操作所有的 metrics：它从不同的 channel 中拿到消息，然后解包出来，找到对应的应该增加的 metrics，然后执行最终的增加操作。

实际的操作还要复杂的多，先创建一个 MetricsBuilder，然后 MetricsBuilder 有 Add() 函数，实际上是往 Channel 里面发送了一条信息，Channel 里面读出来，又通过一些系列的层层调用执行到 metrics + 1 上。

事先声明， 本人不会写 golang，本文可能写的不对，请读者指正。

感觉本身就是一行 metrics.Add() 的事情，为什么要搞这么复杂呢？思来想去，我觉得唯一可能的解释就是：这是一个负载极高的系统，希望将 metrics 的操作变成异步的操作，不占用业务处理的时间。但是用 channel 还涉及到打包和解包，真的能快吗？

一开始我以为 channel 可能是一种高性能的无锁的操作，但是看了 golang 的 runtime 部分，发现也是有锁的，如果多个线程同时往一个 channel 里面写，也是存在竞争条件的。

而 Prometheus 的 client_golang 只是执行了一个 Add 操作：atomic.AddUint64(&c.valInt, ival)

虽然 atomic 也是一个 CAS 操作，但直觉上我觉得用 channel 是不会比 atomic 快的。

写了两段代码来比较这两种情况（测试代码和运行方式可以在 atomic_or_channel 这里找到）：

直接用 atomic 代码：

模拟开一个 channel 负责增加的情况：

参数如下，意在模拟 100 个并行连接，需要增加1百万次：

实际运行的结果也和我想的一样，atomic 要比 channel 的方式快了 15 倍。

atomic 2s 就可以完成模拟 100 个客户端并行增加1百万次，即可以支持5千万的 QPS （还只是在我的笔记本上），而相同的操作用上文描述的 channel 的方式需要 30-40s。慢了15倍。

虽然我在有些地方说 atomic 很慢，但是这个速度对于 metrics 统计的这个场景来说，是完全足够了。

Twitter 上的 @Kontinuation 提醒有一种优化的方式，我觉得这个很好：

每一个 thread 维护自己的 threadlocal 变量，这样完全不需要锁。只是在 collect metrics 的时候采取收集每一个 thread 的 counter 等。TiKV 中就是使用这个方法实现的 Local 指标（@_yeya24），即每一个线程保存自己的指标在 Thread Local Storage，然后每 1s 刷新到全局变量（其实我觉得可以只有在 metrics 被收集的时候才刷新？），这样可以减少锁的次数。

但是在 golang 里面，从这篇文章发现 go 语言官方是不想让你用 thread local 的东西的，而且为此还专门让 go id 不容易被获取到。那我就像不到什么比较好的实现方法了。