最近在小黄鱼刚入的二手 s7 ，2k ，45mm 黑色 蜂窝版，电池 99%，保修到 6 月份

@andyJado 是的，如果对远程分支进行 rebase ，那么已经拉过此分支并且进行了本地 merge 的人，再次 pull 时，都需要处理一遍你在 rebase 时处理过的“合并操作”，每个人的处理方法或者逻辑可能会有所不同，那么当多人再次 push 时，可能会产生很多冲突

@andyJado 新开一个分支，是本地还是远程分支呢？在新分支 rebase 之后，新分支是 merge 到主分支，还是单独创建一个远程分支呢？
如果是本地分支，并且后续需要 merge 到主分支，结论还是和 6 楼的一样。
如果新分支会推送到远程，那么和普通新分支没什么区别，只是 rebase 的时候可能需要处理一些冲突而已

真巧，升级 iOS16 有段时间了，今天下午接连遇到 2 次这种情况，从 mac 粘贴时卡死。重启解决。

看到你的 身高 年龄 体重，感觉就是我本人。

@unt #10
使用 rebase 有个原则：永远不要对已经提交到远程的分支进行 rebase ，否则已经拉过此分支的同事都会抓狂。
所以平时开发只对你本地的临时开发分支进行 rebase ，对别人来说是毫无影响，并且是无感的。他们只能感觉到你的提交永远是一条线，很干净

我一般使用 rebase ，这样做可以把代码冲突在 rebase 的过程中解决，从而 merge 到主分支时，就不会报冲突错误了。使用 rebase 可以把提交记录保持线性，路线比较清晰而且美观。

自助体检机，当时和女朋友一起去换的，看不清的时候叫她进来帮忙看的。

@taka8rie 之前也遇到过，看到网上说解锁时，手面需要触碰到电脑的机身，试了下管用。你也可以试试

Mac 系统，之前有转过 Edge ，后来因为他家的提示更新的毛病，换回去了。
微软的软件，在 Mac 系统中有一个毛病，老有一个弹窗弹出，帮你检查软件更新之类的，这里有没有解决方法？

最近我妈的手机也是经常弹这种广告，一模一样，机型是 iPhone6 ；我说这东西就是病毒，骗人下载呢。看见就把 app 退掉重新打开

@liuxu worker 个数和 cpu 核心数一致，可以减少 CPU 切换的 IO

比如 8 核机器，开 16 个 worker ，那么这 8 核需要在 16 个 worker 中来回切换

如果只开 8 个 worker ，一个核对一个 worker ，就减少了 CPU 的切换 io

之所以没有出现 502 ，可能是因为目前的量没到达顶峰。并且到达顶峰后，也不会报 502 ，表现是 worker 处理的慢，接口响应增长，nginx 那边超时断连，会返回 499.

@liuxu 排除了一下，不是定时器的问题。

后来尝试把异常的三台服务器的 swoole worker number 调整为了 8 ，其他的是 16 ，初步观察变得正常了，所以推测还是程序处理慢，cpu 切换频繁带来的性能消耗。

但是如果是 redis 或者 kafka 响应慢，也不应该只出现在这几台服务器上。所以这个问题还需要继续排查

@liuxu Kafka 写入慢，导致连接数增加，这个是合理的。但写入 Kafka 时用了协程，并不会影响到主协程的速度。

@liuxu
1 、swooler 的控制台日志并没有往 fluentd 里发送，发送的都是业务日志，并且量不小。目前接收的日志服务器确实也存在问题，很早之前搭建的，单核处理的，这么大量的日志目前打包不过来，所以偶尔会出现 ruby 占用内存过高的问题。
2 、这台服务器不止对 kafka 连接数比较多，对 mysql 和 redis 也比其他的服务器要多，我只是列出了 kafka 的。
3 、大多时间异常服务器对 nginx 的连接数是要比正常服务器多的。截图时截太巧了。。
4 、目前每次请求，都会从 Kafka 连接池拿一个链接写入数据，Kafka 连接池并不是服务初始化的，而是有业务请求时去创建的。这样看来从 Kafka 连接池初始化这块逻辑有优化的空间。
5 、目前正在使用 strace 追 worker 进程的问题，发现异常服务器的进程调用 gettimeofday(swooler 定时器)比较多，猜测是业务的定时任务落在了此服务器上，打算把定时任务固定到一台服务器试一下。
6 、感谢指点

用 “strace -cp 进程 id” 追了一下 swoole worker 的系统调用

% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
32.87 0.404515 4 103647 gettimeofday
20.26 0.249291 5 53990 34800 recvfrom
14.14 0.174060 10 18136 sendto
10.83 0.133311 4 33749 clock_gettime
10.02 0.123303 5 26864 epoll_ctl
7.08 0.087140 8 11096 epoll_wait
1.46 0.017924 5 3798 1033 read

目前怀疑和定时器有关