plantegg

java tcp mysql performance network docker Linux

发表于 更新于 分类于

长连接黑洞重现和分析

这是一个存在多年，遍及各个不同的业务又反反复复地在集团内部出现的一个问题，本文先通过重现展示这个问题，然后从业务、数据库、OS等不同的角度来分析如何解决它，这个问题值得每一位研发同学重视起来，避免再次踩到

背景

为了高效率应对故障，本文尝试回答如下一些问题：

  • 为什么数据库crash 重启恢复后，业务还长时间不能恢复？
  • 我依赖的业务做了高可用切换，但是我的业务长时间报错
  • 我依赖的服务下掉了一个节点，为什么我的业务长时间报错
  • 客户做变配，升级云服务节点规格，为什么会导致客户业务长时间报错

目的：希望通过这篇文章尽可能地减少故障时长、让业务快速从故障中恢复

重现

空说无凭，先也通过一次真实的重现来展示这个问题

LVS+MySQL 高可用切换

OS 默认配置参数

1
2
3
4
5
6
#sysctl -a |grep -E "tcp_retries|keepalive"
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 10
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15  //主要是这个参数，默认以及alios 几乎都是15

LVS 对外服务端口是3001， 后面挂的是 3307，假设3307是当前的Master，Slave是 3306，当检测到3307异常后会从LVS 上摘掉 3307挂上 3306做高可用切换

undefined

切换前的 LVS 状态

1
2
3
4
5
6
7
8
#ipvsadm -L --timeout
Timeout (tcp tcpfin udp): 900 120 300
#ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  127.0.0.1:3001 rr
  -> 127.0.0.1:3307               Masq    1      0          0

Sysbench启动压力模拟用户访问，在 31秒的时候模拟管控检测到 3307的Master无法访问，所以管控执行切主把 3306的Slave 提升为新的 Master，同时到 LVS 摘掉 3307，挂上3306，此时管控端着冰可乐、翘着二郎腿，得意地说，你就看吧我们管控牛逼不、我们的高可用牛逼不，这一套行云流水3秒钟不到全搞定

切换命令如下：

1
2
#cat del3307.sh
ipvsadm -d -t  127.0.0.1:3001 -r 127.0.0.1:3307 ; ipvsadm -a -t  127.0.0.1:3001 -r 127.0.0.1:3306 -m

此时Sysbench运行状态，在第 32秒如期跌0：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#/usr/local/bin/sysbench --debug=on --mysql-user='root' --mysql-password='123' --mysql-db='test' --mysql-host='127.0.0.1' --mysql-port='3001' --tables='16'  --table-size='10000' --range-size='5' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all' --time='11080' --report-interval='1' --histogram='on' --threads=1 oltp_read_write run
sysbench 1.1.0 (using bundled LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Report intermediate results every 1 second(s)
Debug mode enabled.

Initializing random number generator from current time


Initializing worker threads...

DEBUG: Worker thread (#0) started
DEBUG: Reporting thread started
DEBUG: Worker thread (#0) initialized
Threads started!

[ 1s ] thds: 1 tps: 51.89 qps: 947.00 (r/w/o: 739.44/207.56/0.00) lat (ms,95%): 35.59 err/s 0.00 reconn/s: 0.00
[ 2s ] thds: 1 tps: 60.03 qps: 1084.54 (r/w/o: 841.42/243.12/0.00) lat (ms,95%): 22.28 err/s 0.00 reconn/s: 0.00
…………
[ 29s ] thds: 1 tps: 68.00 qps: 1223.01 (r/w/o: 952.00/271.00/0.00) lat (ms,95%): 16.12 err/s 0.00 reconn/s: 0.00
[ 30s ] thds: 1 tps: 66.00 qps: 1188.00 (r/w/o: 924.00/264.00/0.00) lat (ms,95%): 16.71 err/s 0.00 reconn/s: 0.00
[ 31s ] thds: 1 tps: 67.00 qps: 1203.96 (r/w/o: 937.97/265.99/0.00) lat (ms,95%): 17.95 err/s 0.00 reconn/s: 0.00
[ 32s ] thds: 1 tps: 22.99 qps: 416.85 (r/w/o: 321.88/94.96/0.00) lat (ms,95%): 15.55 err/s 0.00 reconn/s: 0.00
[ 33s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 34s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 35s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00

5分钟后故障报告大批量涌进来，客户：怎么回事，我们的业务挂掉10分钟了，报错都是访问MySQL 超时，赶紧给我看看，从监控确实看到10分钟后客户业务还没恢复：

1
2
3
4
[ 601s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 602s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 603s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 604s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00

这时 oncall 都被从被窝里拎了起来，不知谁说了一句赶紧恢复吧，先试试把应用重启，5秒钟后应用重启完毕，业务恢复，大家开心地笑了，又成功防御住一次故障升级，还是重启大法好！

在业务/Sysbench QPS跌0 期间可以看到 3307被摘掉，3306 成功挂上去了，但是没有新连接建向 3306，业务/Sysbench 使劲薅着 3307

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#ipvsadm -L -n --stats -t 127.0.0.1:3001
Prot LocalAddress:Port               Conns   InPkts  OutPkts  InBytes OutBytes
  -> RemoteAddress:Port
TCP  127.0.0.1:3001                      2   660294   661999 78202968  184940K
  -> 127.0.0.1:3306                      0        0        0        0        0
  
#ipvsadm -Lcn | head -10
IPVS connection entries
pro expire state       source             virtual            destination
TCP 13:11  ESTABLISHED 127.0.0.1:33864    127.0.0.1:3001     127.0.0.1:3307

#netstat -anto |grep -E "Recv|33864|3001|33077"
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Timer
tcp        0    248 127.0.0.1:33864         127.0.0.1:3001          ESTABLISHED probe (33.48/0/8)
tcp6       0     11 127.0.0.1:3307          127.0.0.1:33864         ESTABLISHED on (49.03/13/0)

直到 900多秒后 OS 重试了15次发现都失败，于是向业务/Sysbench 返回连接异常，触发业务/Sysbench 释放异常连接重建新连接，新连接指向了新的 Master 3306，业务恢复正常

1
2
3
4
5
6
7
[ 957s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
DEBUG: Ignoring error 2013 Lost connection to MySQL server during query,
DEBUG: Reconnecting 
DEBUG: Reconnected
[ 958s ] thds: 1 tps: 53.00 qps: 950.97 (r/w/o: 741.98/208.99/0.00) lat (ms,95%): 30.26 err/s 0.00 reconn/s: 1.00
[ 959s ] thds: 1 tps: 64.00 qps: 1154.03 (r/w/o: 896.02/258.01/0.00) lat (ms,95%): 22.69 err/s 0.00 reconn/s: 0.00
[ 960s ] thds: 1 tps: 66.00 qps: 1184.93 (r/w/o: 923.94/260.98/0.00) lat (ms,95%): 25.28 err/s 0.00 reconn/s: 0.00

到这里重现了故障中经常碰到的业务需要900多秒才能慢慢恢复，这个问题也就是 TCP 长连接流量黑洞

如果我们把 net.ipv4.tcp_retries2 改成5 再来做这个实验，就会发现业务/Sysbench 只需要20秒就能恢复了，也就是这个流量黑洞从900多秒变成了20秒，这回 oncall 不用再被从被窝里拎出来了吧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[ 62s ] thds: 1 tps: 66.00 qps: 1191.00 (r/w/o: 924.00/267.00/0.00) lat (ms,95%): 17.63 err/s 0.00 reconn/s: 0.00
[ 63s ] thds: 1 tps: 63.00 qps: 1123.01 (r/w/o: 874.00/249.00/0.00) lat (ms,95%): 17.63 err/s 0.00 reconn/s: 0.00
[ 64s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 65s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 66s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 67s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 68s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 69s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 70s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 71s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 72s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 73s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 74s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 75s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 76s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 77s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 78s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 79s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 80s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 81s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
[ 82s ] thds: 1 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s 0.00 reconn/s: 0.00
DEBUG: Ignoring error 2013 Lost connection to MySQL server during query,
DEBUG: Reconnecting 
DEBUG: Reconnected
[ 83s ] thds: 1 tps: 26.00 qps: 457.01 (r/w/o: 357.01/100.00/0.00) lat (ms,95%): 16.41 err/s 0.00 reconn/s: 1.00
[ 84s ] thds: 1 tps: 60.00 qps: 1086.94 (r/w/o: 846.96/239.99/0.00) lat (ms,95%): 26.68 err/s 0.00 reconn/s: 0.00
[ 85s ] thds: 1 tps: 63.00 qps: 1134.02 (r/w/o: 882.01/252.00/0.00) lat (ms,95%): 23.10 err/s 0.00 reconn/s: 0.00

LVS + Nginx 上重现

NGINX上重现这个问题：https://asciinema.org/a/649890 3分钟的录屏，这个视频构造了一个LVS 的HA切换过程，LVS后有两个Nginx，模拟一个Nginx(Master) 断网后，将第二个Nginx(Slave) 加入到LVS 并将第一个Nginx(Master) 从LVS 摘除，期望业务能立即恢复，但实际上可以看到之前的所有长连接都没有办法恢复，进入一个流量黑洞

TCP 长连接流量黑洞原理总结

TCP 长连接在发送包的时候，如果没收到ack 默认会进行15次重传(net.ipv4.tcp_retries2=15, 这个不要较真，会根据RTO 时间大致是15次)，累加起来大概是924秒，所以我们经常看到业务需要15分钟左右才恢复。这个问题存在所有TCP长连接中(几乎没有业务还在用短连接吧？)，问题的本质和 LVS/k8s Service 都没关系

我这里重现带上 LVS 只是为了场景演示方便

这个问题的本质就是如果Server突然消失(宕机、断网，来不及发 RST )客户端如果正在发东西给Server就会遵循TCP 重传逻辑不断地TCP retran , 如果一直收不到Server 的ack，大约重传15次，900秒左右。所以不是因为有 LVS 导致了这个问题，而是在某些场景下 LVS 有能力处理得更优雅，比如删除 RealServer的时候 LVS 完全可以感知这个动作并 reset 掉其上所有长连接

为什么在K8S 上这个问题更明显呢，K8S 讲究的就是服务不可靠，随时干掉POD(切断网络），如果干POD 之前能kill -9(触发reset)、或者close 业务触发断开连接那还好，但是大多时候啥都没干，有强摘POD、有直接隔离等等，这些操作都会导致对端只能TCP retran

怎么解决

业务方

业务方要对自己的请求超时时间有控制和兜底，不能任由一个请求长时间 Hang 在那里

比如JDBC URL 支持设置 SocketTimeout、ConnectTimeout，我相信其他产品也有类似的参数，业务方要设置这些值，不设置就是如上重现里演示的900多秒后才恢复

SocketTimeout

只要是连接有机会设置 SocketTimeout 就一定要设置，具体值可以根据你们能接受的慢查询来设置；分析、AP类的请求可以设置大一点

最重要的：任何业务只要你用到了TCP 长连接一定要配置一个恰当的SocketTimeout，比如 Jedis 是连接池模式，底层超时之后，会销毁当前连接，下一次重新建连，就会连接到新的切换节点上去并恢复

RFC 5482 TCP_USER_TIMEOUT

RFC 5482 中增加了TCP_USER_TIMEOUT这个配置，通常用于定制当 TCP 网络连接中出现数据传输问题时，可以等待多长时间前释放网络资源，对应Linux 这个 commit

TCP_USER_TIMEOUT 是一个整数值，它指定了当 TCP 连接的数据包在发送后多长时间内未被确认（即没有收到 ACK），TCP 连接会考虑释放这个连接。

打个比方，设置 TCP_USER_TIMEOUT 后，应用程序就可以指定说：“如果在 30 秒内我发送的数据没有得到确认，那我就认定网络连接出了问题，不再尝试继续发送，而是直接断开连接。”这对于确保连接质量和维护用户体验是非常有帮助的。

在 Linux 中，可以使用 setsockopt 函数来设置某个特定 socket 的 TCP_USER_TIMEOUT 值：

1
2
int timeout = 30000; // 30 seconds
setsockopt(sock, IPPROTO_TCP, TCP_USER_TIMEOUT, (char *)&timeout, sizeof(timeout));

在这行代码中，sock 是已经 established 的 TCP socket，我们将该 socket 的 TCP_USER_TIMEOUT 设置为 30000 毫秒，也就是 30 秒。如果设置成功，这个 TCP 连接在发送数据包后 30 秒内如果没有收到 ACK 确认，将开始进行 TCP 连接的释放流程。

TCP_USER_TIMEOUT 相较 SocketTimeout 可以做到更精确(不影响慢查询)，SocketTimeout 超时是不区分ACK 还是请求响应时间的，但是 TCP_USER_TIMEOUT 要求下层的API、OS 都支持。比如 JDK 不支持 TCP_USER_TIMEOUT，但是 Netty 框架自己搞了Native 来实现对 TCP_USER_TIMEOUT 以及其它OS 参数的设置，在这些基础上Redis 的Java 客户端 lettuce 依赖了 Netty ，所以也可以设置 TCP_USER_TIMEOUT

原本我是想在Druid 上提个feature 来支持 TCP_USER_TIMEOUT，这样集团绝大部分业务都可以无感知解决掉这个问题，但查下来发现 JDK 不支持设置这个值，想要在Druid 里面实现设置 TCP_USER_TIMEOUT 的话，得像 Netty 一样走Native 绕过JDK 来设置，这对 Druid 而言有点重了

ConnectTimeout

这个值是针对新连接创建超时时间设置，一般设置3-5秒就够长了

连接池

建议参考这篇 《数据库连接池配置推荐》 这篇里的很多建议也适合业务、应用等，你把数据库看成一个普通服务就好理解了

补充下如果用的是Druid 数据库连接池不要用它来设置你的 SocketTimeout 参数，因为他有bug 导致你觉得设置了但实际没设置上，2024-03-16号的1.2.22这个Release 才fix，所以强烈建议你讲 SocketTimeout 写死在JDBC URL 中简单明了

OS 兜底

假如业务是一个AP查询/一次慢请求，一次查询/请求就是需要半个小时，将 SocketTimeout 设置太小影响正常的查询，那么可以将如下 OS参数改小，从 OS 层面进行兜底

1
2
net.ipv4.tcp_retries2 = 8
net.ipv4.tcp_syn_retries = 4

keepalive

keepalive 默认 7200秒太长了，建议改成20秒，可以在OS 镜像层面固化，然后各个业务可以 patch 自己的值；

如果一条连接限制超过 900 秒 LVS就会Reset 这条连接，但是我们将keepalive 设置小于900秒的话，即使业务上一直闲置，因为有 keepalive 触发心跳包，让 LVS 不至于 Reset，这也就避免了当业务取连接使用的时候才发现连接已经不可用被断开了，往往这个时候业务抛错误的时间很和真正 Reset 时间还差了很多，不好排查

在触发 TCP retransmission 后会停止 keepalive 探测

LVS

如果你们试用了aliyun的SLB，当摘除节点的时候支持你设置一个时间，过了这个时间 aliyun的SLB 就会向这些连接的客户端发 Reset 干掉这些流量，让客户端触发新建连接，从故障中快速恢复，这是一个实例维度的参数，建议云上所有产品都支持起来，管控可以在购买 aliyun的SLB 的时候设置一个默认值：

connection_drain_timeout

其它

神奇的900秒

上面阐述的长连接流量黑洞一般是900+秒就恢复了，有时候我们经常在日志中看到 CommunicationsException: Communications link failure 900秒之类的错误，恰好 LVS 也是设置的 900秒闲置 Reset

1
2
#ipvsadm -L --timeout
Timeout (tcp tcpfin udp): 900 120 300

为什么这个问题这几年才明显暴露

  • 工程师们混沌了几十年
  • 之前因为出现频率低重启业务就糊弄过去了
  • 对新连接不存在这个问题
  • 有些连接池配置了Check 机制(Check机制一般几秒钟超时 fail)
  • 微服务多了
  • 云上 LVS 普及了
  • k8s service 大行其道

我用的 7层是不是就没有这个问题了？

幼稚，你4层都挂了7层还能蹦跶，再说一遍只要是 TCP 长连接就有这个问题

极端情况

A 长连接 访问B 服务，B服务到A网络不通，假如B发生HA，一般会先Reset/断开B上所有连接(比如 MySQL 会去kill 所有processlist；比如重启MySQL——假如这里的B是MySQL)，但是因为网络不通这里的reset、fin网络包都无法到达A，所以B是无法兜底这个异常场景， A无法感知B不可用了，会使用旧连接大约15分钟

最可怕的是 B 服务不响应，B所在的OS 还在响应，那么在A的视角 网络是正常的，这时只能A自己来通过超时兜底

总结

这种问题在 LVS 场景下暴露更明显了，但是又和LVS 没啥关系，任何业务长连接都会导致这个 900秒左右的流量黑洞，首先要在业务层面重视这个问题，要不以后数据库一挂掉还得重启业务才能从故障中将恢复，所以业务层面处理好了可以避免900秒黑洞和重启业务，达到快速从故障中恢复

再强调下这个问题如果去掉LVS/k8s Service/软负载等让两个服务直连，然后拔网线也会同样出现

最佳实践总结：

  • 如果你的业务支持设置 SocketTimeout 那么请一定要设置，但不一定适合分析类就是需要长时间返回的请求
  • 最好的方式是设置 OS 层面的 TCP_USER_TIMEOUT 参数，只要长时间没有 ack 就报错返回，但 JDK 不支持直接设置
  • 如果用了 ALB/SLB 就一定要配置 connection_drain_timeout 这个参数
  • OS 镜像层面也可以将 tcp_retries2 设置为5-10次做一个兜底
  • 对你的超时时间做到可控、可预期

假如你的业务不是 Java，而是 Python 的话，请参考Java/Python超时参数对照表：

功能 JDBC (Java) mysql-connector-python PyMySQL
连接建立超时 connectTimeout connect_timeout connect_timeout
读写操作超时 socketTimeout connection_timeout read_timeout/write_timeout
连接池等待超时 poolTimeout pool_timeout 需手动实现

相关故障和资料

ALB 黑洞问题详述：https://mp.weixin.qq.com/s/BJWD2V_RM2rnU1y7LPB9aw

数据库故障引发的“血案” ：https://www.cnblogs.com/nullllun/p/15073022.html 这篇描述较细致，推荐看看

tcp_retries2 的解释：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
tcp_retries1 - INTEGER
    This value influences the time, after which TCP decides, that
    something is wrong due to unacknowledged RTO retransmissions,
    and reports this suspicion to the network layer.
    See tcp_retries2 for more details.

    RFC 1122 recommends at least 3 retransmissions, which is the
    default.

tcp_retries2 - INTEGER
    This value influences the timeout of an alive TCP connection,
    when RTO retransmissions remain unacknowledged.
    Given a value of N, a hypothetical TCP connection following
    exponential backoff with an initial RTO of TCP_RTO_MIN would
    retransmit N times before killing the connection at the (N+1)th RTO.

    The default value of 15 yields a hypothetical timeout of 924.6
    seconds and is a lower bound for the effective timeout.
    TCP will effectively time out at the first RTO which exceeds the
    hypothetical timeout.

    RFC 1122 recommends at least 100 seconds for the timeout,
    which corresponds to a value of at least 8.

tcp_retries2 默认值为15，根据RTO的值来决定，相当于13-30分钟(RFC1122规定，必须大于100秒)，但是这是很多年前的拍下来古董参数值，现在网络条件好多了，尤其是内网，个人认为改成 5-10 是比较恰当 azure 建议：https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-connection ，Oracle RAC的建议值是3：https://access.redhat.com/solutions/726753

发表于 更新于 分类于

十年后数据库还是不敢拥抱NUMA-续篇

背景

十年后数据库还是不敢拥抱NUMA， 这篇经典的纠正大家对NUMA 认知的文章一晃发布快3年了，这篇文章的核心结论是：

  • 之所以有不同的NUMA Node 是不同的CPU Core 到不同的内存距离远近不一样所决定的，这是个物理距离
  • 程序跑在不同的核上要去读写内存可以让性能差异巨大，所以我们要尽量让一个程序稳定跑在一个Node 内
  • 默认打开NUMA Node 其实挺好的

写这个续篇是我收到很多解释，因为跨Node 导致性能抖动，所以集团在物理机OS 的启动参数里设置了 numa=off ，也就是不管BIOS 中如何设置，我们只要在OS 层面设置一下 numa=off 就能让程序稳定下来不再抖了！

我这几年也认为这是对的，只是让我有点不理解，既然不区分远近了，那物理上存在的远近距离(既抖动)如何能被消除掉的呢？

所以这个续篇打算通过测试来验证下这个问题

设置

BIOS 中有 numa node 设置的开关(注意这里是内存交错/交织)，不同的主板这个BIOS设置可能不一样，但是大同小异，基本都有这个参数

img

Linux 启动引导参数里也可以设置numa=on(默认值)/off ，linux 引导参数设置案例：

1
2
#cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-327.x86_64  ro crashkernel=auto vconsole.font=latarcyrheb-sun16 vconsole.keymap=us BIOSdevname=0 console=tty0 console=ttyS0,115200 scsi_mod.scan=sync intel_idle.max_cstate=0 pci=pcie_bus_perf ipv6.disable=1 rd.driver.pre=ahci numa=on nosmt=force

注意如上的 numa=on 也可以改为 numa=off

看完全置篇要记住一条铁律：CPU到内存的距离是物理远近决定的，你软件层面做些设置是没法优化这个距离，也就是没法优化这个时延 (这是个核心知识点，你要死死记住和理解，后面的一切实验数据都回过头来看这个核心知识点并揣摩)

实验

测试机器CPU，如下是BIOS numa=on、cmdline numa=off所看到的，一个node

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                96
On-line CPU(s) list:   0-95
Thread(s) per core:    2
Core(s) per socket:    24
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz
Stepping:              4
CPU MHz:               2500.000
CPU max MHz:           3100.0000
CPU min MHz:           1000.0000
BogoMIPS:              4998.89
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              33792K
NUMA node0 CPU(s):     0-95

测试工具是lmbench，测试命令：

1
for i in $(seq 0 6 95); do echo core:$i; numactl -C $i -m 0 ./bin/lat_mem_rd -W 5 -N 5 -t 64M; done >lat.log 2>&1

上述测试命令始终将内存绑定在 node0 上，然后用不同的物理core来读写这块内存，按照前一篇 这个时延肯定有快慢之分

BIOS和引导参数各有两种设置方式，组合起来就是四种，我们分别设置并跑一下内存时延，测试结果：

BIOS ON BIOS OFF
cmdline numa=on（默认值） NUMA 开启，内存在Node内做交织，就近有快慢之分 bios 关闭后numa后，OS层面完全不知道下层的结构，默认全局内存做交织，时延是个平均值
cmdline numa=off 交织关闭，效果同上 同上

测试原始数据如下(测试结果文件名 lat.log.BIOSON.cmdlineOff 表示BIOS ON，cmdline OFF )：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
//从下面两组测试来看，BIOS层面 on后，不管OS 层面是否on，都不会跨node 做交织，抖动存在
//BIOS on 即使在OS层面关闭numa也不跨node做内存交织，抖动存在
//默认从内存高地址开始分配空间，所以0核要慢
#grep -E "core|64.00000" lat.log.BIOSON.cmdlineOff 
core:0 //第0号核
64.00000 100.717 //64.0000为64MB， 100.717 是平均时延100.717ns 即0号核访问node0 下的内存64MB的平均延时是100纳秒
core:24
64.00000 68.484
core:48
64.00000 101.070
core:72
64.00000 68.483
#grep -E "core|64.00000" lat.log.BIOSON.cmdlineON
core:0
64.00000 67.094
core:24
64.00000 100.237
core:48
64.00000 67.614
core:72
64.00000 101.096

//从下面两组测试来看只要BIOS off了内存就会跨 node 交织，大规模测试下内存 latency 是个平均值
#grep -E "core|64.00000" lat.log.BIOSOff.cmdlineOff //BIOS off 做内存交织，latency就是平均值
core:0
64.00000 85.657  //85 恰好是最大100，最小68的平均值
core:24
64.00000 85.741
core:48
64.00000 85.977
core:72
64.00000 86.671

//BIOS 关闭后numa后，OS层面完全不知道下层的结构，默认一定是做交织
#grep -E "core|64.00000" lat.log.BIOSOff.cmdlineON
core:0
64.00000 89.123
core:24
64.00000 87.137
core:48
64.00000 87.239
core:72
64.00000 87.323

从数据可以看到在BIOS 设置ON后，无论 OS cmdline 启动参数里是否设置了 ON 还是 OFF，内存延时都是抖动且一致的(这个有点诧异，说好的消除抖动的呢？)。如果BIOS 设置OFF后内存延时是个稳定的平均值(这个比较好理解)

疑问

  • 内存交错时为什么 lmbench 测试得到的时延是平均值，而不是短板效应的最慢值？

测试软件只能通过大规模数据的读写来测试获取一个平均值，所以当一大块内存读取时，虽然通过交织大块内存被切分到了快慢物理内存上，但是因为规模大慢的被平均掉了。(欢迎内核大佬指正)

  • 什么是内存交织？

我的理解假如你有8块物理内存条，如果你有一个int 那么只能在其中一块上，如果你有1MB的数据那么会按cacheline 拆成多个块然后分别放到8块物理内存条上(有快有慢)这样带宽更大，最后测试得到一个平均值

如果你开启numa那么只会就近交织，比如0-3号内存条在0号core所在的node，OS 做内存交织的时候只会拆分到这0-3号内存条上，那么时延总是最小的那个，如上测试中的60多纳秒。

这个问题一直困扰了我几年，所以我最近再次测试验证了一下，主要是对 BIOS=on 且 cmdline=off 时有点困扰

Intel 的 mlc 验证

测试参数: BIOS=on 同时 cmdline off

用Intel 的 mlc 验证下，这个结果有点意思，latency稳定在 145 而不是81 和 145两个值随机出现，应该是mlc默认选到了0核，对应lmbench的这组测试数据(为什么不是100.717， 因为测试方法不一样)：

1
2
3
4
5
6
7
8
9
10
11
12
//如下是
//从下面两种测试来看，BIOS层面 on后，不管OS 层面是否on，都不会跨node 做交织，抖动存在
//BIOS on 即使在OS层面关闭numa也不跨node做内存交织，抖动存在
#grep -E "core|64.00000" lat.log.BIOSON.cmdlineOff 
core:0
64.00000 100.717
core:24
64.00000 68.484
core:48
64.00000 101.070
core:72
64.00000 68.483

此时对应的mlc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#./mlc
Intel(R) Memory Latency Checker - v3.9
Measuring idle latencies (in ns)...
    Numa node
Numa node    0
    0   145.8  //多次测试稳定都是145纳秒

Measuring Peak Injection Memory Bandwidths for the system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using traffic with the following read-write ratios
ALL Reads     :  110598.7
3:1 Reads-Writes :  93408.5
2:1 Reads-Writes :  89249.5
1:1 Reads-Writes :  64137.3
Stream-triad like:  77310.4

Measuring Memory Bandwidths between nodes within system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
    Numa node
Numa node    0
    0  110598.4

Measuring Loaded Latencies for the system
Using all the threads from each core if Hyper-threading is enabled
Using Read-only traffic type
Inject  Latency Bandwidth
Delay (ns)  MB/sec
==========================
 00000  506.00   111483.5
 00002  505.74   112576.9
 00008  505.87   112644.3
 00015  508.96   112643.6
 00050  574.36   112701.5

当两个参数都为 on 时的mlc 测试结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#./mlc
Intel(R) Memory Latency Checker - v3.9
Measuring idle latencies (in ns)...
    Numa node
Numa node    0     1
    0    81.6   145.9
    1   144.9    81.2

Measuring Peak Injection Memory Bandwidths for the system
Bandwidths are in MB/sec (1 MB/sec = 1,000,000 Bytes/sec)
Using all the threads from each core if Hyper-threading is enabled
Using traffic with the following read-write ratios
ALL Reads     :  227204.2
3:1 Reads-Writes :  212432.5
2:1 Reads-Writes :  210423.3
1:1 Reads-Writes :  196677.2
Stream-triad like:  189691.4

说明：mlc和 lmbench 测试结果不一样，mlc 时81和145，lmbench测试是68和100，这是两种测试方法的差异而已，但是快慢差距基本是一致的

结论

在OS 启动引导参数里设置 numa=off 完全没有必要、也不能解决抖动的问题，反而设置了 numa=off 只能是掩耳盗铃，让用户看不到 NUMA 结构

发表于 更新于 分类于

流量一样但为什么CPU使用率差别很大

这是我翻到2013年的一篇文章，当时惊动所有公司高人，最后分析得知原因后所有人都跪拜，你要知道那是2013年，正好10年过去了，如果是现在用我们星球的理论去套的话，简直不要太容易

问题描述

同样大小内存、同样的CPU、同样数量的请求、几乎可以忽略的io，两个机器的load却差异挺大。一个机器的load是12左右，另外一个机器却是30左右

你可以理解这是两台一摸一样的物理机挂在一个LVS 下，LVS 分发流量绝对均衡

所以要找出为什么？

分析

两台机器的资源使用率：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
//load低、CPU使用率低 的物理机，省略一部分核
Cpu0  : 67.1%us,  1.6%sy,  0.0%ni, 30.6%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
Cpu1  : 64.1%us,  1.6%sy,  0.0%ni, 34.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 63.0%us,  1.6%sy,  0.0%ni, 35.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  : 60.0%us,  1.3%sy,  0.0%ni, 38.4%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu4  : 59.8%us,  1.3%sy,  0.0%ni, 37.9%id,  1.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  : 56.7%us,  1.0%sy,  0.0%ni, 42.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  : 63.4%us,  1.3%sy,  0.0%ni, 34.6%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
Cpu7  : 62.5%us,  2.0%sy,  0.0%ni, 35.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu8  : 58.5%us,  1.3%sy,  0.0%ni, 39.5%id,  0.0%wa,  0.0%hi,  0.7%si,  0.0%st
Cpu9  : 55.8%us,  1.6%sy,  0.0%ni, 42.2%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st

//load高、CPU使用率高 的物理机，省略一部分核
Cpu0  : 90.1%us,  1.9%sy,  0.0%ni,  7.1%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu1  : 88.5%us,  2.9%sy,  0.0%ni,  8.0%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
Cpu2  : 90.4%us,  1.9%sy,  0.0%ni,  7.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  : 86.9%us,  2.6%sy,  0.0%ni, 10.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu4  : 87.5%us,  1.9%sy,  0.0%ni, 10.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu5  : 87.3%us,  1.9%sy,  0.0%ni, 10.5%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu6  : 90.4%us,  2.9%sy,  0.0%ni,  6.4%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu7  : 90.1%us,  1.9%sy,  0.0%ni,  7.6%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu8  : 89.5%us,  2.6%sy,  0.0%ni,  6.7%id,  0.0%wa,  0.0%hi,  1.3%si,  0.0%st
Cpu9  : 90.7%us,  1.9%sy,  0.0%ni,  7.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

可以分析产出为什么低，检查CPU是否降频、内存频率是否有差异——检查结果一致

10年前经过一阵 perf top 看热点后终于醒悟过来知道得去看 IPC，也就是相同CPU使用率下，其中慢的机器产出低了一半，那么继续通过perf看IPC：

img

可以看到两台机器的IPC是 0.3 VS 0.55，和CPU使用率差异基本一致，instructions几乎一样(意味着流量一样，LVS 不背锅)，但是处理同样的instructions 用掉的cpu-clock 几乎差了一倍，这应该是典型的内存时延大了一倍导致的。IPC 大致等于 instrunctions/cpu-clock （IPC：instrunctions per cycles）

经检查这两台物理机都是两路，虽然CPU型号/内存频率一致，但是主板间跨Socket的 QPI带宽差了一倍(主板是两个不同的服务商提供)。可以通过绑核测试不同Socket/Node 下内存时延来确认这个问题

这是同一台机器下两个Socket 的内存带宽，所以如果跨Socket 内存访问多了就会导致时延更高、CPU使用率更高

img

总结

在今天我们看到这种问题就很容易了，但我还是要感叹一下在入门前简直太神奇，入门后也不过尔尔，希望你也早点入门。

第一：向CPU要产出，同样的使用率产出得一样，不一样的话肯定是偷懒了，偷懒的直接证据就是 IPC 低了，导致IPC 低最常见的是内存时延高(内存频率、跨Node/Socket 等，或者内存碎片)；延伸阅读：性能的本质 IPC ，也是本星球唯二的必读实验

第二：测试工具很完善了，lmbench , 怎么用lmbench 可以看这篇 ; 怎么使用perf Perf IPC以及CPU性能

，学成后装逼可以看 听风扇声音来定位性能瓶颈

我以前说过每个领域都有一些核心知识点，IPC 就是CPU领域的核心知识点，和tcp的rmem/wmem 一样很容易引导你入门

计算机专业里非要挑几个必学的知识点肯定得有计算机组成原理，但计算机组成原理内容太多，都去看也不现实，况且很多过时的东西，那么我只希望你能记住计算机组成原理里有个最核心的麻烦：内存墙——CPU 访问内存太慢导致了内存墙是我们碰到众多性能问题的最主要、最核心的一个，结合今天这个案例掌握IPC后再来学内存墙，再到理解计算机组成原理就对了，从一个实用的小点入手。

计算机专业里除掉组成原理(有点高大上，没那么接地气)，另外一个我觉得最有用的是网络——看着low但是接地气，问题多，很实用

2011年的文章：

详解服务器内存带宽计算和使用情况测量

更好的工具来发现类似问题：https://github.com/intel/numatop

img

发表于 更新于 分类于

SocketTimeout 后客户端怎么做和服务端怎么做

背景

希望通过一个极简，几乎是人人都可以上手验证的实验来触及到一些深度的内容，然后再看看是否会激发你进一步自己设计类似实验和验证过程等

关于这种简单类型的实验欢迎给我提意见：比如你会不会做；太难、太容易？能学到东西吗？效果如何？我要如何改进

安装JDK和MySQL

1
2
3
4
5
6
7
8
9
10
11
yum install -y java-1.8.0-openjdk.x86_64 java-1.8.0-openjdk-devel.x86_64  podman-docker.noarch wireshark 

//启动MySQL Server，root密码123
docker run -it -d --net=host -e MYSQL_ROOT_PASSWORD=123 --name=plantegg mysql

docker run --net=host -v /root/mysql/my3306.cnf:/etc/my.cnf -it -d  -e MYSQL_ROOT_PASSWORD=123 --name=mysql3306 mysql:8.0

//可能需要的MySQL 账号命令
//8.0密码问题，可以设置配置：
ALTER USER 'test'@'localhost' IDENTIFIED WITH mysql_native_password BY '123';
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY '123';

测试环境机器是99块一年购买的aliyun ECS，OS版本选ALinux3，对应内核版本：

1
5.10.134-15.al8.x86_64

测试使用的MySQL 版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
mysql> \s
--------------
mysql  Ver 8.0.32 for Linux on x86_64 (Source distribution)

Connection id:		9
Current database:	test
Current user:		root@127.0.0.1
SSL:			Not in use
Current pager:		stdout
Using outfile:		''
Using delimiter:	;
Server version:		8.2.0 MySQL Community Server - GPL
Protocol version:	10
Connection:		127.1 via TCP/IP
Server characterset:	utf8mb4
Db     characterset:	utf8mb4
Client characterset:	utf8mb4
Conn.  characterset:	utf8mb4
TCP port:		3306
Binary data as:		Hexadecimal
Uptime:			15 hours 46 min 24 sec

Threads: 2  Questions: 34  Slow queries: 0  Opens: 176  Flush tables: 3  Open tables: 95  Queries per second avg: 0.000

客户端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
测试代码(复制粘贴就可以编译运行了，运行时需要下载jdbc mysql driver，链接见附录)：
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.sql.PreparedStatement;
public class Test { //不要琢磨代码规范、为什么要这么写，就是为了方便改吧改吧做很多不同的验证试验
    public static void main(String args[]) throws NumberFormatException, InterruptedException, ClassNotFoundException {
        Class.forName("com.mysql.jdbc.Driver");
        String url = args[0];
        String user = args[1];
        String pass = args[2];
        String sql = args[3];
        String interval = args[4];
        try {
            Connection conn = DriverManager.getConnection(url, user, pass);
            while (true) {
                PreparedStatement stmt = conn.prepareStatement(sql);
                //stmt.setFetchSize(Integer.MIN_VALUE); //这句是表示开流式读取，但是每条SQL 都会先发set net_write_timeout=600 给Server
                stmt.setString(1, interval);
                ResultSet rs = stmt.executeQuery();
                rs.close();
                stmt.close();

                PreparedStatement stmt2 = conn.prepareStatement(sql);
                stmt2.setString(1, interval);
                rs = stmt2.executeQuery();
								while (rs.next()) {
								    System.out.println("fine");
								}
                rs.close();
                stmt2.close();

                Thread.sleep(Long.valueOf(interval));
								break;
            }
						conn.close();
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}

#javac Test.java //编译，需要提前安装JDK
//执行，需要下载jdbc jar驱动，见附录，还需要有一个数据库，随便建个表，或者查里面自带的库都可以
#java -cp .:./mysql-connector-java-5.1.45.jar Test "jdbc:mysql://127.0.0.1:3306/test?useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&connectTimeout=500&socketTimeout=1700" root 123 "select sleep(10), id from sbtest1 where id= ?" 100 //设置了1.7秒超时查询还不返回的话业务代码报错，堆栈如下：
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure //连接异常

The last packet successfully received from the server was 1,701(1700ms) milliseconds ago.  The last packet sent successfully to the server was 1,701 milliseconds ago.
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:990)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3559)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3459)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3900)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2527)
	at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1283)
	at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:783)
	at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1966)
	at Test.main(Test.java:30)
Caused by: java.net.SocketTimeoutException: Read timed out // 异常，JDBC Driver 会调 Socket.setSoTimeout 来设置超时时间给 timeRead使用
	at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:284) //timedRead 函数可以设置读取超时（timeout）
	at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:310)
	at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:351)
	at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
	at java.base/java.net.Socket$SocketInputStream.read(Socket.java:919)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3008)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3469)
	... 7 more

源码参考：https://sourcegraph.com/github.com/openjdk/jdk/-/blob/src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java?L291:18-291:26

客户端读到一半的时候 MySQL Hang 了，也会触发 SocketTimeoutException 异常，同时客户端还会看到 Consider raising value of ‘net_write_timeout’ on the server(测试代码开启了流式读取)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
java -cp .:./mysql-connector-java-5.1.45.jar Test "jdbc:mysql://gf1:3307/test?useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&connectTimeout=500&socketTimeout=1500&netTimeoutForStreamingResults=0" root 123 "select *, id from streaming " 5000

timestamp:1734084150084 id:1 count:60798
timestamp:1734084150084 id:2 count:60799
timestamp:1734084151594  //读到 60799行后，MySQL 卡了，读卡了 1500ms 后报错
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Application was streaming results when the connection failed. Consider raising value of 'net_write_timeout' on the server.
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:990)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3559)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3459)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3900)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:873)
	at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1996)
	at com.mysql.jdbc.RowDataDynamic.nextRecord(RowDataDynamic.java:374)
	at com.mysql.jdbc.RowDataDynamic.next(RowDataDynamic.java:354)
	at com.mysql.jdbc.ResultSetImpl.next(ResultSetImpl.java:6312)
	at Test.main(Test.java:38)
Caused by: java.net.SocketTimeoutException: Read timed out
	at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:288)
	at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:314)
	at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:355)
	at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:808)
	at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3008)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3469)
	... 8 more

服务端对应的抓包

如果OS 比较老，安装的tshark 也较老，那么命令参数略微不一样，主要是 col.Info 这个列，没有 _ws 前缀：

1
#tshark -i eth0 port 3306 -d tcp.port==3306,mysql -nn -T fields -e frame.number -e frame.time_delta -e tcp.srcport -e tcp.dstport -e col.Info -e mysql.query

如果是阿里云 99 买了ECS，安装的内核版本较高比如4.19，那么配套安装的tshark也较高，就用如下命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#tshark -i eth0 -Y "tcp.port==3306" -d tcp.port==3306,mysql -T fields -e frame.number -e frame.time -e frame.time_delta -e tcp.srcport -e tcp.dstport -e tcp.len -e _ws.col.Info -e mysql.query
 //第二列是时间间隔
1	0.000000000	30260	3306	kingdomsonline > mysql [SYN] Seq=0 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=512
2	0.000024473	3306	30260	mysql > kingdomsonline [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=128
3	0.000271938	30260	3306	kingdomsonline > mysql [ACK] Seq=1 Ack=1 Win=42496 Len=0 //3次握手
4	0.000660359	3306	30260	Server Greeting proto=10 version=8.2.0 //MySQL server主动发送版本、问候信息等
5	0.000263009	30260	3306	kingdomsonline > mysql [ACK] Seq=1 Ack=78 Win=42496 Len=0
6	0.039698745	30260	3306	Login Request user=test db=test //客户端验证账号密码
7	0.000009044	3306	30260	mysql > kingdomsonline [ACK] Seq=78 Ack=243 Win=30336 Len=0
8	0.000171281	3306	30260	Response
9	0.000260062	30260	3306	kingdomsonline > mysql [ACK] Seq=243 Ack=126 Win=42496 Len=0
10	0.000298127	30260	3306	Request Unknown (168)
11	0.000142114	3306	30260	Response OK 
12	0.000255322	30260	3306	kingdomsonline > mysql [ACK] Seq=267 Ack=137 Win=42496 Len=0
13	0.003596187	30260	3306	Request Query	/* mysql-connector-java-5.1.45 ( Revision: 9131eefa398531c7dc98776e8a3fe839e544c5b2 ) */SELECT  @@session.auto_increment_increment AS auto_increment_increment, @@character_set_client AS character_set_client, @@character_set_connection AS character_set_connection, @@character_set_results AS character_set_results, @@character_set_server AS character_set_server, @@collation_server AS collation_server, @@init_connect AS init_connect, @@interactive_timeout AS interactive_timeout, @@license AS license, @@lower_case_table_names AS lower_case_table_names, @@max_allowed_packet AS max_allowed_packet, @@net_buffer_length AS net_buffer_length, @@net_write_timeout AS net_write_timeout, @@have_query_cache AS have_query_cache, @@sql_mode AS sql_mode, @@system_time_zone AS system_time_zone, @@time_zone AS time_zone, @@transaction_isolation AS transaction_isolation, @@wait_timeout AS wait_timeout
14	0.000328419	3306	30260	Response
15	0.000266581	30260	3306	kingdomsonline > mysql [ACK] Seq=1164 Ack=1208 Win=42496 Len=0
16	0.022407439	30260	3306	Request Query	SHOW WARNINGS
17	0.000058143	3306	30260	Response
18	0.000267585	30260	3306	kingdomsonline > mysql [ACK] Seq=1182 Ack=1411 Win=42496 Len=0
19	0.001776177	30260	3306	Request Query	SET NAMES utf8mb4 //客户端设置charset
20	0.000052102	3306	30260	Response OK
21	0.000263257	30260	3306	kingdomsonline > mysql [ACK] Seq=1204 Ack=1422 Win=42496 Len=0
22	0.000175172	30260	3306	Request Query	SET character_set_results = NULL
23	0.000046756	3306	30260	Response OK
24	0.000258191	30260	3306	kingdomsonline > mysql [ACK] Seq=1241 Ack=1433 Win=42496 Len=0
25	0.000185322	30260	3306	Request Query	SET autocommit=1
26	0.000037833	3306	30260	Response OK
27	0.000255747	30260	3306	kingdomsonline > mysql [ACK] Seq=1262 Ack=1444 Win=42496 Len=0
28	0.011132112	30260	3306	Request Prepare Statement	select sleep(10), id from sbtest1 where id= ?  //进一步学习
29	0.000171861	3306	30260	Response //作业：Prepared Statement 后 MySQL回了啥？
30	0.000290736	30260	3306	kingdomsonline > mysql [ACK] Seq=1312 Ack=1570 Win=42496 Len=0
31	0.000613187	30260	3306	Request Execute Statement                                           //客户端发送SQL请求
32	0.039923585	3306	30260	mysql > kingdomsonline [ACK] Seq=1570 Ack=1334 Win=32128 Len=0
33	1.675682641	30260	3306	kingdomsonline > mysql [FIN, ACK] Seq=1334 Ack=1570 Win=42496 Len=0 //1.7秒后客户端发fin主动断开
34	0.039320026	3306	30260	mysql > kingdomsonline [ACK] Seq=1570 Ack=1335 Win=32128 Len=0

//MySQL 还完全不知道客户端fin了，继续发送响应结果。tcp断开在OS 层面处理，业务再使用这个已断开的连接时OS 会返回错误
35	3.245406398	3306	30260	Response
36	0.000041708	3306	30260	Server Greeting Error 1158 //MySQL 感知到OS返回的错误，发送错误码(已经没有用了)，不过客户端已经断开收不到了
37	0.000053987	3306	30260	mysql > kingdomsonline [FIN, ACK] Seq=1742 Ack=1335 Win=32128 Len=0
38	0.000165707	30260	3306	kingdomsonline > mysql [RST] Seq=1335 Win=0 Len=0 //连接都断开了，客户端已经退出，客户端的OS代发reset 
39	0.000017860	30260	3306	kingdomsonline > mysql [RST] Seq=1335 Win=0 Len=0
40	0.000082025	30260	3306	kingdomsonline > mysql [RST] Seq=1335 Win=0 Len=0

如果你的 tshark 版本较高，以上命令行可以改为：

1
tshark -i lo -Y "tcp.port==3306" -T fields -e frame.number -e frame.time_delta -e tcp.srcport -e tcp.dstport -e _ws.col.Info -e mysql.query

GPT4.0 Turbo 对上面这个 tshark 命令的解释：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
你提到的命令使用tshark捕获在端口3306（MySQL的默认端口）上的网络流量，并提取特定的字段进行显示。tshark是Wireshark的命令行版本，一个非常强大的网络协议分析工具。

这条命令的组成部分解释如下：

-i eth0: 指定tshark监听eth0接口上的流量。这是网络接口的名称，可以根据实际情况进行修改。

port 3306: 指定tshark只捕获目标或源端口为3306的TCP流量，这是MySQL服务器监听的标准端口。

-T fields: 设置tshark的输出格式为字段值（fields），意味着输出将以列的形式显示指定的字段。

-e frame.number: 添加一个字段，显示每个捕获的帧的编号。

-e frame.time_delta: 添加一个字段，显示自上一帧以来经过的时间（以秒为单位）。

-e tcp.srcport: 添加一个字段，显示TCP源端口号。

-e tcp.dstport: 添加一个字段，显示TCP目标端口号。

-e col.Info: 添加一个字段，显示捕获帧的信息列。

-e mysql.query: 添加一个字段，如果捕获的TCP流量是MySQL流量，显示MySQL查询。

这个命令的输出将是以空格分隔的列，每一列代表上述参数指定的一个字段。每一行代表一个捕获的网络帧，其中包含MySQL查询。

请注意，由于这个命令包含了mysql.query，它需要tshark能够解析MySQL协议。而且，如果MySQL流量是加密的（例如使用SSL/TLS），那么tshark将无法直接显示查询内容。

在运行这个命令前，你需要有足够的权限来捕获网络流量，通常需要root权限或者足够的权限来访问网络接口。如果你不是root用户，可以使用sudo运行tshark命令。

sudo tshark -i eth0 port 3306 -T fields -e frame.number -e frame.time_delta -e tcp.srcport -e tcp.dstport -e col.Info -e mysql.query
这个命令将实时显示MySQL查询相关的流量信息。如果你想要保存结果到一个文件，可以使用重定向或-w选项。如果只想要捕获一定数量的包，可以使用-c选项后跟要捕获的包的数量。

最后用一张大截图来演示这个实验：

image-20240111121421625

PreparedStatement 验证

测试代码，用Prepared执行三次查询：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
                PreparedStatement stmt = conn.prepareStatement(sql);
//                stmt.setFetchSize(Integer.MIN_VALUE);
                stmt.setString(1, interval);
                ResultSet rs = stmt.executeQuery();
                rs.close();
                stmt.close();

                PreparedStatement stmt2 = conn.prepareStatement(sql);
                stmt2.setString(1, interval);
                rs = stmt2.executeQuery();
                //Thread.sleep(60000);
                while (rs.next()) {
                        System.out.println("fine");
                }
                rs = stmt2.executeQuery();
                //Thread.sleep(60000);
                while (rs.next()) {
                        System.out.println("fine");
                }
                rs.close();
                stmt2.close();

如图绿色是Prepared过程不会真执行 Select 查数据，只是把这条SQL 发给Server，让Server 提前编译，可以看出来编译时间0.000146秒(绿色方框)，因为SQL 非常简单；三个红色线分别是3次真正的查询，都走了Prepared(不再传 Select了)，不过时间很不稳定，所以这个统计必须大批量。红色方框是三次通过Prepared 执行 Select 查数据的执行时间：

image-20240322103643718

结论

作为一个CRUD boy从以上实验中你可以学到哪些东西？

  • 客户端报错堆栈要熟悉，Communications link failure (很多原因可以导致这个错误哈)和 java.net.SocketTimeoutException: Read timed out
  • JDBC 连接参数要配置socketTimeout，不配置会导致很多很多故障，显得CRUD boy太业余
  • 抓包，从抓包中学到每个动作，反过来分析原因，比如这次报错就是客户端发送了查询过1.7秒主动断开，所以问题在客户端，1.7秒也要敏感
  • 最重要的是学到这个实验过程，比如再自己去试试分析 PreparedStatement 的工作原理，如何才能让 PreparedStatement 生效

进一步学习

你可以把抓包保存，然后下载到wireshark中，能看到具体每一个包的详细内容，比如加密后的密码、Prepared statement是个啥(一个唯一id)

比如明明MySQL Server感知到了连接断开错误(Message: Got an error reading communication packets) 还要挣扎着返回这个错误信息给客户端有必要吗？

java 跑着，直接kill -9 java-pid 看看服务端收到什么包？(有经验后下次看到这样的症状就知道为啥了)

参考

MySQL 1158错误信息的详细意思

mysql jdbc driver

后续 Debug

为啥我的Java 代码跑半天也不报错：

image-20240115090336526

jstack -p java-pid ，可以看到main 卡在执行SQL 后等结果的堆栈里，所以不是Java sleep了，等看对端MySQL 在干什么

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f6a5c0db000 nid=0x109d8e in Object.wait() [0x00007f6a60a75000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f6b08d90> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000000f6b08d90> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"main" #1 prio=5 os_prio=0 tid=0x00007f6a5c04b000 nid=0x109d8a runnable [0x00007f6a638e9000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
        at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
        at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
        - locked <0x00000000f6b71370> (a com.mysql.jdbc.util.ReadAheadInputStream)
        at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3008)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3469)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3459)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3900)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2527)
        at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1283)
        - locked <0x00000000f6b0a228> (a com.mysql.jdbc.JDBC4Connection)
        at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:783)
        - locked <0x00000000f6b0a228> (a com.mysql.jdbc.JDBC4Connection)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1966)
        - locked <0x00000000f6b0a228> (a com.mysql.jdbc.JDBC4Connection)
        at Test.main(Test.java:30)

"VM Thread" os_prio=0 tid=0x00007f6a5c0d1000 nid=0x109d8d runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f6a5c05e000 nid=0x109d8b runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f6a5c060000 nid=0x109d8c runnable

抓包

为啥抓不到任何包？

image-20240115090420370

先确认3306 端口是你的MySQL 在跑：

1
2
3
# ss -lntp |grep 3306
LISTEN 0      151                *:3306             *:*    users:(("mysqld",pid=1023638,fd=22))
LISTEN 0      70                 *:33060            *:*    users:(("mysqld",pid=1023638,fd=20))

:3306 中的‘“” 表示MySQLD 监听本机任何网卡的3306端口，查看一下网卡名字：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:16:3e:39:b5:e0 brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    altname ens5
    inet 172.17.151.5/20 brd 172.17.159.255 scope global dynamic noprefixroute eth0
       valid_lft 309352989sec preferred_lft 309352989sec
    inet6 fe80::216:3eff:fe39:b5e0/64 scope link
       valid_lft forever preferred_lft forever
3: cni-podman0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether de:a8:06:82:76:00 brd ff:ff:ff:ff:ff:ff
    inet 10.88.0.1/16 brd 10.88.255.255 scope global cni-podman0
       valid_lft forever preferred_lft forever
    inet6 fe80::dca8:6ff:fe82:7600/64 scope link
       valid_lft forever preferred_lft forever
4: veth82cad224@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni-podman0 state UP group default
    link/ether 4e:1b:4a:0d:a9:e2 brd ff:ff:ff:ff:ff:ff link-netns netns-58786150-bf63-2ae1-242f-cf221eed34fe
    inet6 fe80::4c1b:4aff:fe0d:a9e2/64 scope link
       valid_lft forever preferred_lft forever

尝试 tshark -i any – any是个什么鬼，展开学习下抓包参数

这里对select sleep 不确定的话可以Google sleep的单位、用法；也可以MySQL Client 验证一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# mysql -h127.1  -uroot -p123
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select sleep(1.4);
+------------+
| sleep(1.4) |
+------------+
|          0 |
+------------+
1 row in set (1.40 sec)

为什么不用mysql client做这个SocketTimeout的实验：mysql似乎没有SocketTimeout这个参数：
mysql --help |grep -i time
                      and reconnecting may take a longer time. Disable with
  --connect-timeout=# Number of seconds before connection timeout.
connect-timeout                           0

终于能抓到包了

image-20240115090938622

Kill Java

1
2
3
4
5
6
7
8
9
10
11
12
56	0.014671013	40102	3306	Request Prepare Statement	select sleep(60), id from sbtest1 where id= ?
57	0.000253230	3306	40102	Response
58	0.000173110	40102	3306	40102 → 3306 [ACK] Seq=1312 Ack=1570 Win=65536 Len=0 TSval=478689604 TSecr=478689604
59	0.000602784	40102	3306	Request Execute Statement
60	0.040903127	3306	40102	3306 → 40102 [ACK] Seq=1570 Ack=1334 Win=65536 Len=0 TSval=478689645 TSecr=478689604


77	0.397023820	40102	3306	40102 → 3306 [FIN, ACK] Seq=1334 Ack=1570 Win=65536 Len=0 TSval=478705206 TSecr=478689645
78	0.040424926	3306	40102	3306 → 40102 [ACK] Seq=1570 Ack=1335 Win=65536 Len=0 TSval=478705246 TSecr=478705206
83	0.793390527	3306	40102	Response
84	0.000016522	40102	3306	40102 → 3306 [RST] Seq=1335 Win=0 Len=0

mysql kill pid

1
2
3
4
5
6
7
8
# tshark -i lo -Y "tcp.port==59636" -T fields -e frame.number -e frame.time_delta -e tcp.srcport -e tcp.dstport -e _ws.col.Info -e mysql.query
Running as user "root" and group "root". This could be dangerous.
Capturing on 'Loopback'
//
85	0.000042261	3306	59636	3306 → 59636 [FIN, ACK] Seq=1 Ack=1 Win=512 Len=0 TSval=478849322 TSecr=478831136
92	0.008106470	59636	3306	59636 → 3306 [FIN, ACK] Seq=1 Ack=2 Win=512 Len=0 TSval=478849333 TSecr=478849322
93	0.000008612	3306	59636	3306 → 59636 [ACK] Seq=2 Ack=2 Win=512 Len=0 TSval=478849333 TSecr=478849333

kill mysqld pid

1
2
3
4
5
6
7
8
9
]# tcpdump -i lo port 50436
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes


09:32:50.138291 IP localhost.mysql > localhost.50436: Flags [F.], seq 206507581, ack 2788331892, win 512, options [nop,nop,TS val 479088777 ecr 479041791], length 0
09:32:50.150621 IP localhost.50436 > localhost.mysql: Flags [F.], seq 1, ack 1, win 512, options [nop,nop,TS val 479088789 ecr 479088777], length 0
09:32:50.150640 IP localhost.mysql > localhost.50436: Flags [.], ack 2, win 512, options [nop,nop,TS val 479088789 ecr 479088789], length 0

视频学习

如果你也想试试这个实验的话，可以参考我们的视频：https://meeting.tencent.com/user-center/shared-record-info?id=c0962ad4-16bc-4ac8-83ab-2e302c372e73&is-single=false&record_type=2&from=3

1
2
3
JDBC客户端MySQL服务器初始化阶段建立数据库连接连接成功配置参数socketTimeout=1459msnetTimeoutForStreamingResults=1s设置流式查询setAutoCommit(false)setFetchSize(Integer.MIN_VALUE)执行查询: SELECT * FROM data_table开始准备结果集返回第一批数据开始处理第一条数据Thread.sleep(1500ms)net_write_timeout计时开始(1s)等待客户端处理...1秒后超时关闭连接仍在sleep(1500ms)尝试读取下一条数据连接已关闭抛出CommunicationsExceptionJDBC客户端MySQL服务器


发表于 更新于 分类于

无招胜有招–一周年总结

大家抱着美好和雄赳赳的目标来到这个知识星球，开始的时候兴奋地以为找到了银弹(其实银弹是有的，在文章最后)，经过一段时间后大概率发现没什么变化，然后就回到了以前的老路子上，我觉得关键问题是你没获取到星球的精华，所以这篇我打算反复再唠叨一下

知识效率 工程效率

虽然我们现在通过这篇《知识效率 工程效率》知道了两者的差别， 但是还是需要记住通过积累可以将我们的学习能力从工程效率升级到知识效率(厚积薄发)，大部分时候没有做到薄发，是因为你以为理解了、积累了实际没理解

核心知识点

尽力寻找每个领域的核心知识点，核心知识点的定义就是通过一两个这样的知识点能撬动对整个领域的理解，也就是常说的纲挈目张

比如网络领域里：一个网络包是怎么流转的+抓包。假如你理解网络包的流转后再去看LVS 负载均衡的原理你就发现只需要看一次你就能很好掌握LVS各个负载均衡的本质，而在这之前你反复看反复忘。掌握了这个知识点基本就可以通关整个领域，剩下的只是无招胜有招碰到一个挨个积累的问题了。

比如CPU领域理解超线程+IPC+会用perf和内存延时，理解超线程的本质是为什么一个核能干两个核的工作(这和操作系统的分时多任务背后原理是想通的)，那是因为我们的程序没法吃满流水线(也就是没法用完一个核的计算能力，用IPC去衡量)，没吃满闲置的时候就可以虚拟给另外一个进程用，比如CPU 跑起来最高IPC都能到4，但是无论你找一个Java还是MySQL 去看他们的IPC基本都在1以内，纯计算场景的IPC会高一点，IPC 可以到4但只跑到1的话也就是只用满了25%的能力，那当然可以再虚出来一个超线程提高效率。IPC 之所以低就是因为内存延时大，这么多年CPU的处理能力一直按摩尔定律在提升但是内存延时没有怎么提升，导致基本上我们常见的业务场景(Nginx/MySQL/Redis 等)都是CPU在等从内存取数据(所以搞了L1、L2、L3一堆cache)。

发散一下或者说留个作业你去看看NUMA 的原理或者说本质就是为了让CPU知道就近分配读取内存以提升效率。

你看整本计算机组成原理+性能的本质都在这一个知识点的范围内进行延伸和突破。

如果你发现一个核心知识点也欢迎写成博客文章分享出来

读日志、错误信息

我的经验只是大概20%左右的程序员会去耐心读别人的日志、报错信息，大部分摊摊手求助、放弃了

日志是最好的学习机会，我知道别人的日志写得很烂，但是你要能耐心多琢磨一点就会比别人更专业一点

对知识的可观测性

抓包、perf的使用这些平时要多积累，这点没有捷径，一个好的工程师肯定有一堆好的锤子、瑞士军刀、工具包的。在你掌握了知识点后要转化为工作效率，就得多积累这些工具，很多次我们碰到一个好的问题没分析出来是因为我们这种没有门槛的积累不够导致放弃了

比如需要抓包确认下，不会，一看tcpdump 一堆参数头疼放弃；比如想要知道长连接还是短连接，或者自己设置的长连接有没有生效，不会用netstat -o 这个参数去确认等；比如要下载个源码自己make/install 中间报了几个错误不仔细看放弃；

反过来回到我们所说的工程效率，就是靠这些工具帮你实现可视、可以触摸，网络之所以大多数同学在大学都学过但是最后基本学懂，就是因为这些网络的东东你只看理论很难立即，但是让你抓过一次包分析下就会恍然大悟——这就是关键门槛你能跨过去

好习惯

在星球里我更希望你带走一个好的习惯而不是一个具体知识点，虽然星球里的具体知识点、案例胜过很多教材，但他们总有过时、用不上的时候，唯有好的习惯可以跟随你，帮你实现无招胜有招

记笔记

放低身段，不要高估自己的能力(认为自己是知识效率)，放低后你要怎么做呢：记笔记、记笔记、记笔记

只要是你在学习就要或者看书、看资料的时候觉得自己有点通透了，赶紧记录下来，因为大概率一个星期你就忘了，半年你就完全不记得自己以前看过一次了，我好多次看到一篇好文章就感叹自己学到了，兴奋地拉到文章最后想去评论下，结果发现居然有了自己的评论在下面 :)

动手

动手，看到后理解了，也记了笔记，其实最好还是要自己去重现，记下自己看到的现象和理解，动手又会有一堆门槛，搭环境、客观则、怎么验证等等，这个时候我前面说的可观测性里面积累的一大堆工具可以让你如有神助、重现起来效率就是比别人高

汇总输出

最后笔记记完还没完，笔记基本是零散的，你反复积累后到了一定的时机就是要把他们总结汇总成一篇完整度较高的博客文章，这里当然有自己的虚荣心在这里，但更多的是为了自己查询方便，有了新的理解或者使用姿势我经常更新补充10年前的博客文章，不会写一篇新的，这个补充知识让我的知识结构更完善，不是为了多发一篇博文，我现在解决问题、使用工具基本要靠翻自己的博客文章照着操作

慢就是快、少就是多

往往我们喜欢求快，以为自己一看就懂；求多以为自己越看的多越厉害

不要等着时间流投喂

看这篇置顶：https://t.zsxq.com/14Yel6KBg

纲举目张

对公司的业务、一个软件的运转流程都要尽量做到理解

比如学MySQL 要尽量知道从一条SQL 怎么进来，进行哪些处理后得到了查询结果；比如前面讲过的一个网络包是怎么到达对端的；比如你们公司的请求是怎么从客户端到达服务端(中间经过了LVS、Nginx吗)，服务端又是那些服务得依赖和调用，有没有Redis、MQ、Database，最后数据又是怎么返回的，我知道这在一个公司很难(屎山很复杂)，但目前没有更好的方法让你快速掌握并立足

为什么出现问题后总有一两个人很快能猜出来问题可能在哪个环节，这一部分是经验但更多的是对系统的了解，你都不知道有Redis存在一旦出错了你肯定猜不到Redis这里来

可以看看我之前说的实习生的故事，完全真实哈：

讲一个我碰到的实习生的事情

北邮毕业直接后直接到我司实习

特点：英语好、动手能力强、爱琢磨，除了程序、电脑没有其它爱好 :)

实习期间因为英语好把我司文档很快就翻烂了，对产品、业务逻辑的理解基本是顶尖的

实习期间很快成为所有老员工的红人，都离不开他，搭环境、了解业务流程

因为别人的习惯都是盯着自己眼前的这一趴，只有他对业务非常熟悉

实习后很快就转正了，又3年后transfer 去了美国总部

连女朋友都是老员工给牵线的，最后领证一起去了美国。为啥老员工这么热情，是大家真心喜欢他

再看看张一鸣自述的第一年的工作：

img

总结

我前面所说的我也没做太好，希望大家能做得更好，我第一次感受无招胜有招就是故事一里面，到故事二过去差不多10年，这10年里我一直在琢磨怎么才能无招胜有招，也有在积累，但是花了10年肯定效率不算高，所以在星球里我希望通过我的经验帮你们缩短一些时间

上面讲再多如果你只是看看那根本还是没用，买再多的课也没用，关键是看触动后能否有点改变。你可以从里面试着挑几个你认为容易操作，比如记笔记、比如不要等着时间流投喂，或者有感触的试试先改变或者遵循下看看能不能获得一些变化进而形成正向循环

或者从评论里开始说说你星球这一年真正有哪些改变、学到了啥、你的感悟，不方便的也可以微信我私聊一下

这篇就当成整个星球学习的一个总结吧

发表于 更新于 分类于

网球肘 过劳性(持续)肌腱病的治疗

因为长期打球，导致手肘部分疼痛难耐，2024年1月开始进行了长时间的休息期，中间2024的2月是春节，所以总共修了快2个月，还不见好，于是去医院，其实医院给的治疗方案也不好，但是医师告诉了我一个关键词这个病叫：网球肘

知道关键词后就开始了自我寻求治疗方案的过程，记下来供参考，到2024年3月14号，最近两周多次打球验证我的网球肘基本好了，所以说一下治疗过程

个人总结

网球肘的核心是肌肉过劳发炎了，所以关键是如何消炎

一定要用：氟比洛芬凝胶贴膏 ，而且每天两贴尽量不要断，期间通过大拇指使劲按压疼痛部分来感受验证的减轻，一般连续贴3-5天会有明显的效果，如果无效请去医院

口服消炎药也可以试试，我估计针对性不强(瞎猜的，希望你试试后来告诉我)。至于体外冲击波可以尝试尝试，我个人的经验觉得还不足以证明其有效

后面的可以不用看了

治疗

网球肘已经有几个月了，开始我没在意以为就是肌肉劳累，休息休息就会好，直到过年的时候我真正歇了一个多月，过完年偶尔一用力居然又开是疼，让我计划去医院看看，之前自己在社区医院开过几盒：氟比洛芬凝胶贴膏

image-20240305141525956

(家中请常备这个药，膏药里的神奇)

【适应症】
下列疾病及症状的镇痛、消炎：
骨关节炎、肩周炎、肌腱及腱鞘炎、腱鞘周围炎、肱骨外上髁炎 ( 网球肘 )、肌肉痛、外伤所致肿胀、疼痛

过年期间自己也偶尔贴一下，但是效果不明显(应该是没有连续贴导致的效果不好)。

这次去医院正规想看看，但是大医院挂不上号，于是去了一个小医院(社区医院推荐的，说这家别的不行，刚好看运动医学还不错)，到医院大夫一听就笑着问我知不知道有一种病叫：网球肘。这是我第一次听说这个病，大夫用大拇指按压我的伤口附近，确实非常疼，结合我经常打球基本确诊。

然后给我开了两次体外冲击波物理治疗，当场治疗了一次，过程中很痛，打完的当时再按压就不疼了，但是过几个小时还是照旧(这也在医师的预料中)，给我开了两次这个治疗，我只去了一次

体外冲击波疗法（extracorporeal shock wave therapy, ESWT）是一种非侵入性、安全、有效治疗多种疾病的方法，在临床多个学科中得到了广泛应用，但临床应用不规范、治疗关键技术不一致、治疗方案不统一、培训体系不健全等问题严重制约了ESWT的临床推广应用。

https://rs.yiigle.com/CN101658202302/1459029.htm#:~:text=%E4%BD%93%E5%A4%96%E5%86%B2%E5%87%BB%E6%B3%A2%E7%96%97%E6%B3%95%EF%BC%88extracorporeal%20shock,ESWT%E7%9A%84%E4%B8%B4%E5%BA%8A%E6%8E%A8%E5%B9%BF%E5%BA%94%E7%94%A8%E3%80%82

回到家我就开始了对“网球肘”的学习，中间找到这篇最关键的经验贴【你一定要看】，我把这里面最有价值的引用一下：

比较对症的治疗方法是，内服 洛索洛芬钠片，外贴 氟比洛芬凝胶贴膏（商标是泽普思），尤其要注意用量和时机

  • 洛索洛芬钠片——我这次没吃这个

    • 一日三次，每次两片（60mg/片）
    • 饭后服用（切记！）

  • 氟比洛芬凝胶贴膏——这点最重要，我不再像以前一样偶尔贴，而是连续一周每天两贴

    • 每次一帖，白天/晚上 各一帖
    • 除了洗澡之外，尽量连续贴

按照上面的做法，经过5天后我的网球肘真的神奇地好了，中间还阳了3天(所以第二次冲击波治疗我也没去)

经验

我的判断是网球肘消炎很重要，应该还是氟比洛芬凝胶贴膏起了关键作用，但是要注意：连续贴一周，每天两贴

至于冲击波是否有效果，我目前觉得可能有效果，但是证据还不够

知道这个病的名字很重要，这样就有了搜索关键字，看别人描述相对来说我这次不算严重

UpToDate 临床顾问

知道名字后，我在淘宝上购买了 UpToDate 临床顾问论文库的账号(收录了几乎所有的医学论文，但是只对收费会员开放)，专业点说如果你好好研究 UpToDate，再结合自身状况可以得到比很多专业医师更专业的治疗

但是这次查到的治疗方案都是普通的消炎、镇痛(对乙氨基酚)等，但是不妨碍你下次可以继续到这里查，一般买个3天的账号才几块钱

image-20240305145408804

另外也推荐大家看默沙东手册(完全免费，有网页和app版本)：

image-20240305145706453

自我检查

自己按压疼痛的地方确认在什么地方，结合平时的运动和习惯，是否恢复也可以通过按压和发力来确认

非甾体类抗炎药(NSAID)

非甾体抗炎药（non-steroidal anti-inflammatory drugs，NSAIDs）又称非类固醇抗炎药，简称非甾体类，是一类具有解热镇痛效果的药物，在施用较高剂量时也具有消炎作用。

NSAID 包括布洛芬（Advil、Motrin IB 等）、萘普生纳（Aleve、Anaprox DS 等）、双氯芬酸钠和塞来昔布（Celebrex）

非甾体抗炎药中，属阿司匹林、伊布洛芬、甲芬那酸、萘普生最为著名，在绝大多数国家都可作为非处方药销售[4]。

对乙酰氨基酚因其抗炎作用微弱，而通常不被归为非甾体抗炎药，它主要通过抑制分布在中枢神经系统的环氧合酶-2，以减少前列腺素的生成，从而缓解疼痛，但由于环氧合酶-2在周边组织中数量较少，因此作用微弱

抗炎治疗

抗炎治疗 — 尽管抗炎治疗多年来都是肘部肌腱病的主要疗法，但支持性证据仅来自成功个案和极少数研究。在医学界对肌腱病有了科学认识之后，抗炎疗法对肘部肌腱病和其他慢性退行性肌腱病的作用也出现了争议。抗炎治疗包括冰敷、NSAID、离子透入疗法和注射糖皮质激素。对于LET，冰敷联合离心力量及柔韧性训练并未优于单纯离心力量训练[51]。(参见上文[‘病理生理学’](http://www.uptodate.zd.hggfdd.top/contents/zh-Hans/elbow-tendinopathy-tennis-and-golf-elbow?search=Tennis Elbow 冲击波&source=search_result&selectedTitle=3~150&usage_type=default&display_rank=3#H4))

体外冲击波疗法（extracorporeal shock wave therapy, ESWT）

体外震波治疗和其他电物理疗法 — 声波已用于治疗慢性LET。总体而言，支持体外震波治疗(extracorporeal shock wave therapy, ESWT)和其他“电物理”疗法的证据并不令人信服，所以我们不予以推荐[82]。该操作通常会令患者不适，但有些研究显示ESWT有一定益处[83]，但也有许多研究未发现ESWT有益[84,85]。

体外冲击波疗法临床应用中国疼痛学专家共识 2023版

定义

“网球肘 ”(TenniS Elbow)又名肱骨外上髁炎 (1ateralepicondylitis)，以网球运动 员发病率高 而得名

广义 的网球肘可分 为具有不同临床特点的四个类型 :

  1. 外侧网球肘 :亦称肱骨外上髁炎 ，即经典的网 球肘 ，主要累及附于肱骨外上髁的桡侧腕短伸肌腱起 点。
  2. 内侧网球肘:亦称肱骨内上髁炎或高尔夫球肘， 主要 累及附于 肱骨 内上髁 的屈肌 和旋前 圆肌腱 起 点。
  3. 后侧网球肘 :亦称三头肌腱炎 。
  4. 混合型网球 肘 :内外侧网球肘同时发生 ，并不少见

读懂医疗发票

自付二：对有自付的药品、检查费收取自费部分；比如药品：10%或50%；检查费：8%；材料费：30%；——可以理解为医保不管的全自付

自付一：根据下图，报销比例是90%，也就是你还要出总医药费的10%；但是要注意总医药费要减掉自付二的部分 —— 医保报销之外要自付的部分，比如未满起付线；满了起付线的 30%

举例：一张发票开了一盒泰诺(酚麻美敏片) 13.47块(乙类清单 10%自付)，还有一盒没有无自付的头孢 5.17块，共18.64

最后发票显示自付二：1.35 就是13.47 的10% ——这个10%是因为该药有部分自费，自付一：1.73 是 (18.64-(13.47X10%))X10% ——这个10%就是达到起付线1800后报销90% 比如 CT 平扫收费 135，属于有自付的自付 2，自付钱是：135*8%=10.8 这 10.8 在商保里不报

如果你没有达到起付线，就是100%自付，那么不存在自付二，付款金额全部显示为自付一

image-20250211115151569

image-20250211114917084

一般商保赔付逻辑：自付 1 赔 100%；自付 2 不赔；超过 1800 起付线后剩下的自付部分 90% 赔(去掉自付 2 后)

超过起付线后：(账单-自付 2)*90%（社区 90/医院 70）= 自付 1

职工基本医疗保险门（急）诊待遇标准

痛风

痛风是由于血中尿酸含量过高（高尿酸血症）而导致尿酸盐结晶沉积在关节内的疾病。沉积的结晶导致关节内和关节周围出现疼痛性炎症的发作。通常具有家族遗传性

痛风在男性中的发病率高于女性。男性痛风患者较女性常见，通常发生在中年男性和绝经期后的女性。很少发生于年轻人，但如果小于 30 岁的人发生痛风，其病情一般较重。

食物和痛风没关系。如果发作了就吃止痛药。不疼的时候吃非布司他（找医生开，这是处方药）。定期检查尿酸是否有降下来。 然后非常容易被忽视的一点是注意别喝含糖饮料，干脆戒掉。

而止痛的药物无非是：

  • 非甾体抗炎药（NSAIDs）
  • 秋水仙碱
  • 糖皮质激素

秋水仙碱或秋水仙素，考虑到其肝肾毒性，我是肯定坚决不吃。至于糖皮质激素，也就是俗称的激素，偶尔用一次或许也可以接受，但不能持续用

风湿性多肌痛

风湿性多肌痛是关节滑膜的炎症，是一种能引起颈、肩、髋部肌肉疼痛和僵硬的疾病。

风湿性多肌痛发病年龄在 55 岁以上，原因尚不清楚。女性的患病率较男性高。风湿性多肌痛的病因尚不清楚。风湿性多肌痛可与 巨细胞（颞）动脉炎同时出现，也可在它之前或之后出现。有学者认为这两种疾病是同一种病变的不同表现。风湿性多肌痛似乎比巨细胞动脉炎更常见。

类风湿性关节炎 (RA)

类风湿性关节炎是一种炎症性关节炎，表现为关节的炎症，受累关节通常包括手脚关节，可导致关节肿胀、疼痛以及常常遭到破坏。

发表于 更新于 分类于

从一道面试题谈起

这是一道BAT 的面试题，针对的是应届生，其实我觉得这种题目也适合所有面试人，比刷算法题、八股文要有用、实际多了

题目

给你几天时间自己在家可以借助任何资源用测试工具Sysbench 完成一次MySQL数据的性能测试，并编写测试报告(自行搭建数据库)

sysbench压MySQL常用有只读、读写、只写、update等6个场景

结果

这个候选人把他的结果发给我看了，我看完一惊要坏事，这个结果估计要不及格了

他用 sysbench 跑了一下只读、读写、只写等场景然后截图就没有了！

image-20230908223348050

(如上图，大概就是6/7个这样的截图就没有了！)

我看到这个结果是很震惊的，你希望面试官挨个去看截图？最起码要有测试结果表格当做结论汇总吧。

如果你不知道怎么做可以先去搜一下别人做的测试报告，你可以按照别人的测试流程完全走一遍，基本算是模仿，要有结论的话也能得60分。

60分的答案

每个场景增加1/8/16/32等并发，然后按照6个场景不同并发做成一个表格，并观察rt、cpu的指标最后汇总形成图表、给出结论分析，比如拐点在哪里、为什么

我觉得这个面试题好就好在这里的分析可以无穷展开，适合新手也适合多年的老手，任何结论理由你都可以写上去，只要有理有据有分析

80分的答案

给自己出一个拟题，比如对比5.7和8.0的性能差异，8.0相对5.7在哪些场景有优化、优劣势，比如这个测试报告

比如官方说的8.0在全局锁、pagesize等方面有些有优化，那么就针对性地设置场景来测试这些功能。

比如这是如上链接测试报告中间有数据图表：

image-20230908224210461

最后有结论和分析：

  • the main impact in the given IO-bound OLTP_RW workload is only DBLWR and nothing else !
  • and again, if your workload has more than 32 concurrent users sessions + using a very fast flash storage..
  • so far, impatient to see DBLWR fixed in MySQL 8.0 ;-))
  • using 4K page size is absolutely to consider for any IO-bound workloads !
  • NOTE : every Linux vendor today is claiming that 4K IO writes in Linux are atomic ! – and if this is really true for your platform, then you can safely disable DBLWR if you’re using 4K page and already reach x2 times higher TPS with MySQL 8.0 today in the given IO-bound OLTP_RW or any similar ! ;-)) – the same x2 times higher TPS was also observed on IO-bound TPCC even with an old SSD drive !
  • while if your workload is not IO-bound (having active dataset mostly cached in BP, none or very low IO reads) – then DBLWR is not your main impact ! – you may always tune your MySQL instance to make it mostly “invisible”..
  • Binlog – is the main impact in this case.. Unfortunately it’s another old historical PITA in MySQL Server, and it’s largely a time now to get it fixed (or come with a more advanced alternative).. – “nature is always finding its way”, so let’s see..
  • no comments on MariaDB 10.3 performance.. – but a good live example that just copying InnoDB code from MySQL 5.7 is not enough to get it running right..

之所以有80分是因为超出面试官的期待，给出了一个更高级的结论，面试官肯定很愿意约你过去谈谈

还有没有更高的分

也许有，但是不好说，80分那个就是优秀很好了，挖掘能力强的应届生会搞出来(肯定没有这么细致和周到，但是有几个关键点的结论就够80分了)，再想出彩一点可以根据这个我的星球案例 https://plantegg.github.io/2021/05/14/%E5%8D%81%E5%B9%B4%E5%90%8E%E6%95%B0%E6%8D%AE%E5%BA%93%E8%BF%98%E6%98%AF%E4%B8%8D%E6%95%A2%E6%8B%A5%E6%8A%B1NUMA/ 去搞几台物理机开关NUMA 验证一下，然后给一个对性能影响结果的测试数据报告

或者我博客这篇也行 https://plantegg.github.io/2019/12/16/Intel%20PAUSE%E6%8C%87%E4%BB%A4%E5%8F%98%E5%8C%96%E6%98%AF%E5%A6%82%E4%BD%95%E5%BD%B1%E5%93%8D%E8%87%AA%E6%97%8B%E9%94%81%E4%BB%A5%E5%8F%8AMySQL%E7%9A%84%E6%80%A7%E8%83%BD%E7%9A%84/，找不同Intel机器验证

给出不同的MySQL参数在不同Intel 芯片下性能的差异报告：

image-20221026153750159

这种结论抛出去肯定会让面试官惊到，并对你刮目相看，至少说明你能在某个点上可以钻研很深，到哪里都要的是火车头，而不是普通工程师。

总结

从一个简单的面试题就可以看出应试人员的主观能动性，最起码你要会抄，先去抄别人的测试报告，然后验证一遍然后思考清楚每一个数据的原因(面试大概率会问)

但是大部分工程师都想临时抱佛脚，其实面试官可能会知道你不懂，但是希望看到给你几天你的深度挖掘和学习能力

最后可以从一个问题深挖、总结能力上能看出来候选人的天花板上限，而我们大部分时候都是凑合可以、又不是不能用，逼着自己向前精进一步总是很难的。

发表于 更新于 分类于

必读 成长路径

我的星球介绍

这篇是关于我星球里的内容、目标以及如何达到这个目标的一些概述

星球目标

本星球致力深度分析各种程序员领域疑难案例，通过案例带动对基础核心知识的理解，同时强化动手能力

一年星球没法让大家称为顶尖程序员(我自己都不是)，只是希望用我的方法、知识、经验、案例作为你的垫脚石，帮助你快速、早日成为一个基本合格的程序员。

必会技能

在星球一年的时间你能学到什么(跟着做一定可以学会的)：

视频素材

如果你发现看文章、做实验有些障碍，我特意录制了视频做演示（如果你基础好，看文章就能看懂并把实验做完，其实没必要看视频）：https://articles.zsxq.com/id_blqwkgux7i0a.html

视频内容目前已经完成了：

  • 抓包技巧演示
  • QPS、并发、RT 的关系
  • tcp-rt 展示和在性能定位中的使用
  • 瓶颈定位分析——追着RT 跑
  • 单机内瓶颈定位
  • 认识CPU 和 Cache，以及测试Cache、内存时延

我在星球内一直强调视频不是高效的学习方法，因为你没有办法仔细思索、随时前后反复看等等，看完视频容易形成学懂了的错觉实际很快就忘了，但是我录完这些视频看大家的反馈我发现视频也有优点那就是：很直观、门槛低等，但是一定要注意一个错觉：以为看视频看懂了。但实际就是看视频看完了忘得比看文章快多了，所以看完视频一定要再去实验一下，实验所需要的素材基本都在星球内有了，代码等我都放在了github上

挑战技能

有些技能不好描述，或者说是一些暗知识，我们尽量去讨论这些技能的逻辑，同时对一些特别有效的工具、知识会重点突破，这些恰恰是我希望你们最终能掌握的：

  • 分析解决问题的能力，在一定的知识的基础上靠谱地去分析
  • 掌握技能而不是死知识
  • 掌握核心知识点，核心知识点是指理解了一个点很容易对一个领域有较大的突破，比如IPC对于CPU性能、比如内存墙对计算机组成原理的理解、比如RT 对性能瓶颈的定位等

知识总是学不完的，况且大多时候我们有了知识也解决不了问题，所以我们更注重能力的训练，比如这个提问：https://t.zsxq.com/0cfBnpmLw

节奏安排

如果你发现这个节奏你跟不上，那么就先去看视频，然后再按这个节奏来，如果还不行可以再去看视频，如果视频看不懂可以到微信群里讨论或者就视频里的哪个点提问，如果觉得看懂了，但是还是没法独立实验，那可以这个看懂了还是错觉，或者是基础缺的太多了

请先浏览星球专栏里的必看资源以及学习方法，做到做会而不是看会。另外每个主题后面的留言也很有价值

本星球大部分理论指导部分请看视频：https://t.zsxq.com/0dF2WvzEF (5-10节共90分钟)，视频中的理论要和案例结合

案例选择

星球选用的案例尽量典型普适性强，代表基础组件基本原理等知识。

分析手段尽量通用，分析过程一定要逻辑合理每个疑问都能回答清晰。

搞清楚一个案例基本能横扫一个领域，其次在一个案例后再带3/5个相关小案例可以帮你丰富场景，多角度理解

基于以上目标一年内选择了如下4个案例：

详细描述请看这里：https://t.zsxq.com/0cyPswpVB

本星球口头禅

慢就是快，做会而不是看会，无招胜有招

慢就是快指的是不要贪多，而是要彻底搞懂一个问题、一个知识点，让这个点成为一个支柱长成体系，贪多往往啥都没有掌握

做会而不是看会：程序员是工程类(也有科学家，但我们CRUD boy肯定不是)，尤其像网络包、CPU流水线都是看不到无法感受，所以建议你去抓包、去做实验体会、触摸到每个包就能够更好地理解，所以星球强调做案例

无招胜有招：尽量找我普适性强的技能，比如ping ping神功，比如抓包，比如Google搜索，你会反复看到我的案例中使用这些技能

如何在本星球获得成长的基本步骤

多和以前的学习方式对比，学了一大堆几个月后全忘了，学了很多不会解决问题，学了很多但要靠反复刷。你不应该继续像以前一样忙忙碌碌但是收获很小

  • 该买的书买了：https://t.zsxq.com/0c3P6gpJE
  • 该做的实验做了:https://t.zsxq.com/0cUhJcVNa ，反复试过后，不懂的尽量提问
  • 该看的视频看过了：https://articles.zsxq.com/id_blqwkgux7i0a.html (实验你能独立完成就不用看视频了)
  • 薅住几个case使劲干，能干多深干多深，看不懂的慢慢想，最好能在工作中找到场景实践一下
  • 学习方法一定要看
  • 不要急于求成，贪多不化，尽量单点突破(就是一个点使劲往深里干)，彻底学懂一个后你会感受到加速
  • 体会到动手做和看书的差异，体会到深度学习案例和看书的差异
  • 不要相信自己看会了，不要相信自己的记忆能力
  • 为什么你有知识但是没有能力：https://t.zsxq.com/0cfBnpmLw
  • 养成记笔记，然后总结输出的习惯
  • 必看专栏一定要高优先级先看

最好能有自己的总结输出，比如博客文章，写文章是一次最好的总结，不一定要发出来，也不一定一次写完美了，我经常修改7、8年前的文章，因为随着经验的丰富有了更深入、不同的理解，这时不要写一篇新的，我都是在原来的基础上修改、扩充，这才是体系建设

成长案例

这是大学刚毕业几个月的新同学写的博客：https://yishenggong.com/2023/05/06/why-does-my-network-speed-drop-cn/

https://yishenggong.com/2023/05/22/is-20m-of-rows-still-a-valid-soft-limit-of-mysql-table-in-2023/ 你可以比较他加入星球前后的博客文章(20230315 加入星球), 第二篇是英文版上了hacker news前三

我观察到的学员成长好习惯：

  • 动手动手，不论事情大小先干起来；
  • 有自己的节奏，不贪多先把一篇文章、一个知识点薅扎实了

欢迎在星球里提问

欢迎大家提问，越具体越好

比如这个问题就很具体、很好： https://t.zsxq.com/0enzptS47 (千万不要微信上问，回答了也没有价值)

我自己一个人写写出来的东西难免自嗨，但是如果是你碰到的实际业务问题我觉得就更有代表性一些

提问肯定尽力要把问题描述具体，好重现，典型的就是之前 aws 流量降速导致MySQL QPS下降，提问的同学做得特别好的就是把这个问题自己反复分析后发现是网络流量被限速了，然后问题就很容易描述和重现，最后一大帮人帮忙分析问题，最后的结果大家都很开心学到了东西。问题在这里：https://articles.zsxq.com/id_iq5a872u8sux.html

你要是通过星球里的方法帮你解决了实际问题这是星球的最终目的，我当然最开心，如果你提了一个你工作中的问题大家一起帮你分析、讨论并最终解决了这就是最好的N对1的私教训练——觉得适合你的能力提升

我有时候绞尽脑汁写了文章然后大家不关心，有时候一个普通问题似乎大家都很嗨，我也喜欢能让你们很嗨的问题(即使我不懂也可以一起讨论)

专栏介绍

必看(一定要看的，我尽量控制必看的少)、实战案例(年度计划一定要分享和搞清楚的案例)、动手实验(做会一直是本星球的重要原则)、学习方法(磨刀不误砍柴工)，剩下的就是按类别分比较好理解

其它

星主自我介绍：https://t.zsxq.com/0c33AXrCi

或者在推特找我：https://twitter.com/plantegg

个人博客：https://plantegg.github.io/2022/01/01/%E4%B8%89%E4%B8%AA%E6%95%85%E4%BA%8B/

博客存放在github，图多的文章会慢一些，可以刷新几次。

建议大家多用PC版星球( https://wx.zsxq.com )，第一次记住密码后也很方便，主要是打字看图更合适些

画图工具和素材：https://t.zsxq.com/0enaoOUBp

知识星球：https://t.zsxq.com/0cSFEUh2J 或者看看星球的介绍：https://plantegg.github.io/2023/05/10/%E7%A8%8B%E5%BA%8F%E5%91%98%E6%A1%88%E4%BE%8B%E6%98%9F%E7%90%83%E4%BB%8B%E7%BB%8D/

image-20240324161113874

image-20230407232314969

发表于 更新于 分类于

保险

我的观点

  1. 不推荐任何理财型保险(你简单认为一年保费过万的都不推荐)
  2. 推荐少量消费型的保险(就是那种几乎没人给你推销，一年几百、几千的保费，没事不返还任何钱给你)
  3. 不推荐重疾险，回报率低
  4. 资源有限就优先给家庭主要收入来源的人买保险，很多人一上来给小孩买，中年男人裸奔，这搞错了
  5. 最实惠的保险是相互宝那种，可惜被获利阶层伙同傻逼们干没了

理由

基本逻辑：保险是保意外的，你想赚钱就去买房子、股票、基金、做生意(不是说这几年哈)。消费型的保险(比如人身意外伤害险、车险都算)才是保意外，以小博大，当然也是保的小概率。

任何一个保险扣除运营费用就是返还率，相互宝运营费用10%-8%，大多人没概念，这是极低了，没有营销成本，10%用在理赔的时候调查考证。但是一个理财型的保险20-30% 给一线销售，这就是为什么这些保险人反复、耐心跟你讲要买保险，为你服务，当然这是成本，值不值你自己考虑；这还没完，还有上级、经理、公司的运营工资等，要不保险公司凭什么养那么多领导家属；所以这是保险公司核心收入来源，也必然导致了价格奇高。

理赔很复杂，没事的时候当然好，真要理赔各种你没想到的事前告知，你连我这几百字都不愿意看，保险公司那条款你就更不愿意看了。所以我推荐意外险，死了就陪那种简单些，越复杂的你越搞不懂。卖保险的人是不会跟你说那么清晰的，实际上他自己都搞不清楚，真到了出险才是真正的考验！

一家三口，只买一份保险，假设预算一年5000的话，给谁买？

肯定是给创造家里主要收入来源那人，保险其实是给活人的福利，你给小朋友买，妈妈挂了，他惨不惨？收入一下子也没了，保险能给他生活费、学费？

如果给妈妈买，你看至少保额还可以供他几年。现在的父母觉得自己有爱、爱娃，当然是给小朋友买，所以我说是错的

你别拿有钱人人都买来扛哈。

为什么不推荐重疾险

重疾险本来是挺好的，出险直接给钱，是医保外的补充，正如我上面所说赔付率太低了，你还不如把保费存起来，赌概率。

买一年几百的意外险其实是能嫖到一年几万保费的人为你提供服务的

这个自己想想

保险大家都需要，都希望有，但是保险行业是最需要革命和精简的，比银行还夸张，所以我不会花太多钱补贴这帮蛀得太厉害的蛀虫

个人所得税综合汇算

昨天晚上Review个税到很晚，终于找不回来70%，这里确实有需要补税的地方；但是还有一些抵扣给我漏了；

我这次多算主要有一个2022年的bug，这个bug导致当时要退我几万税(系统自动自己算Bug)，我大喜装糊涂，各种配合税务局提交资料，最后税务局人工Review的时候发现了这个bug，当然钱也不会退我，不过打电话跟我解释了，我也装糊涂就过去了

结果今年这Bug确实修复了，但是他娘的修复过头了，导致我多补70%的税，现在我只需要补30%，开心多了，这30% 是预期内的

毕竟我从2019年对个税申报太熟悉了，如图是我研究后的一些经验

几个省税的点:

1）大部分情况下奖金、工资分开计税税更少，有极小概率合并计税缴税少（比如工资低奖金高、比如奖金落在盲区的话合，因为利用了工资税扣减数不用除12）

2） 目前奖金、工资可以合并也可以单独计税，二选一，默认单独计税——不懂就在个税app上申报的时候两种都试试，哪种缴税少就用哪种

3） 股票比年终奖少扣税，同样100万，股票收入到手比年终奖多了17万(因为股票税没有盲区）

最后附送一个案例(如图)，100万年终奖和100万股票收入的差别，同时100万年终奖跟工资合并计税税更少; 同时如果100万年终奖采用合并计税也比单独计税拿到手要多

目前一个人有机会将税率做得比较低，就是把收入分成3份：工资、将近、股票，算下来几乎可以按综合年入的30%以内缴税(高管个税有其它优惠我粉丝都是屌丝就不展开了，很多高管缴税可能比你少——比如去成都、天津，现在多了海南)

另外因为2023年8月才出通知提高23年的附加抵扣额度，所以今年几乎每个人都要退税，如果没有退就好好Review以下，已经提交了的还可以重新退回来重新算；2022年、2021年算错了的现在还可以申请要回来！ 现在打开个税APP 去Review，如果有找补回来记得给我发红包。如果你今年退税了辛苦评论区说下让我开心开心

发表于 更新于 分类于

几款不同的CPU一些数据–备查

背景

方便大家对不同的CPU混个脸熟，有个整体概念。本来发布在知识星球，但是知识星球上格式看起来太影响阅读效率了，所以特意拿出来发到博客上

简单查看CPU我一般用 lscpu(默认自带) 命令，或者用复杂点的工具：hwloc 工具安装：

1
yum install hwloc -y

安装后生成结构图片命令：

1
lstopo --logical --output-format png > kunpeng_920.png

生成字符结构，不要图片：

1
lstopo-no-graphics

后面展示的都算是整体机构，所以还会附带有内存怎么接(一个多少条，每条多大，一个Numa node插了几个物理内存条)，这些我博客上都有，就不展开了。一般都是对称的(每个node、socket对称，不对称肯定发挥不出来好性能)

intel E5 2682

大概是Intel 2012年的主流服务器CPU

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
#lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                64 //整机总共64核，实际是由32个物理核通过超线程得来
On-line CPU(s) list:   0-63
Thread(s) per core:    2 //一个物理核2个超线程
Core(s) per socket:    16 //每块CPU有16个物理核
Socket(s):             2 //两路，两块物理上能买到的CPU
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
Stepping:              1
CPU MHz:               2499.902
CPU max MHz:           3000.0000
CPU min MHz:           1200.0000
BogoMIPS:              4999.76
Virtualization:        VT-x
L1d cache:             32K //L1 data
L1i cache:             32K
L2 cache:              256K
L3 cache:              40960K //40M L3,也有人叫 LLC(last level cache), L3是一个socket下所有核共享
NUMA node0 CPU(s):     0-15,32-47  //node0
NUMA node1 CPU(s):     16-31,48-63 //node1

//进一步详细看看CPU的结构
#lstopo-no-graphics 
Machine (512GB) //机器总共512G内存
  NUMANode L#0 (P#0 256GB) //两路，共两个Numa Node，第一个Node 256G内存
    Socket L#0 + L3 L#0 (40MB) //Node 0的 L3 40MB，32个逻辑核共享
      //第一个物理核，每一个物理核都有自己的L2(256KB)和 L1(32KB+32KB), L1分数据、指令两部分
      L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 
        PU L#0 (P#0)  //第一个逻辑核
        PU L#1 (P#32) //第二个逻辑核，这两逻辑核实际是同一个物理核，第二个逻辑核编号是32

      //以下是第二个物理核，都是一样的结构……
      L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
        PU L#2 (P#1)
        PU L#3 (P#33)
      L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2
        PU L#4 (P#2)
        PU L#5 (P#34)
      L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3
        PU L#6 (P#3)
        PU L#7 (P#35)
      L2 L#4 (256KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4
        PU L#8 (P#4)
        PU L#9 (P#36)
      L2 L#5 (256KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5
        PU L#10 (P#5)
        PU L#11 (P#37)
      L2 L#6 (256KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6
        PU L#12 (P#6)
        PU L#13 (P#38)
      L2 L#7 (256KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7
        PU L#14 (P#7)
        PU L#15 (P#39)
      L2 L#8 (256KB) + L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8
        PU L#16 (P#8)
        PU L#17 (P#40)
      L2 L#9 (256KB) + L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9
        PU L#18 (P#9)
        PU L#19 (P#41)
      L2 L#10 (256KB) + L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10
        PU L#20 (P#10)
        PU L#21 (P#42)
      L2 L#11 (256KB) + L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11
        PU L#22 (P#11)
        PU L#23 (P#43)
      L2 L#12 (256KB) + L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12
        PU L#24 (P#12)
        PU L#25 (P#44)
      L2 L#13 (256KB) + L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13
        PU L#26 (P#13)
        PU L#27 (P#45)
      L2 L#14 (256KB) + L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14
        PU L#28 (P#14)
        PU L#29 (P#46)
      L2 L#15 (256KB) + L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15
        PU L#30 (P#15)
        PU L#31 (P#47)
    HostBridge L#0
      PCIBridge
        PCI 144d:a804
      PCIBridge
        PCI 8086:10fb
          Net L#0 "eth2" //两块PCI 万兆网卡插在Socket0上，所有Socket0上的core访问网络效率更高
        PCI 8086:10fb
          Net L#1 "eth3"
      PCIBridge
        PCIBridge
          PCI 1a03:2000
            GPU L#2 "card0"
            GPU L#3 "controlD64"
      PCI 8086:8d02
        Block L#4 "sda" //sda硬盘
  NUMANode L#1 (P#1 256GB) //第二路，也就是第二个Node，内存、cache、核都是对称的
    Socket L#1 + L3 L#1 (40MB)
      L2 L#16 (256KB) + L1d L#16 (32KB) + L1i L#16 (32KB) + Core L#16
        PU L#32 (P#16)
        PU L#33 (P#48)
      L2 L#17 (256KB) + L1d L#17 (32KB) + L1i L#17 (32KB) + Core L#17
        PU L#34 (P#17)
        PU L#35 (P#49)
      L2 L#18 (256KB) + L1d L#18 (32KB) + L1i L#18 (32KB) + Core L#18
        PU L#36 (P#18)
        PU L#37 (P#50)
      L2 L#19 (256KB) + L1d L#19 (32KB) + L1i L#19 (32KB) + Core L#19
        PU L#38 (P#19)
        PU L#39 (P#51)
      L2 L#20 (256KB) + L1d L#20 (32KB) + L1i L#20 (32KB) + Core L#20
        PU L#40 (P#20)
        PU L#41 (P#52)
      L2 L#21 (256KB) + L1d L#21 (32KB) + L1i L#21 (32KB) + Core L#21
        PU L#42 (P#21)
        PU L#43 (P#53)
      L2 L#22 (256KB) + L1d L#22 (32KB) + L1i L#22 (32KB) + Core L#22
        PU L#44 (P#22)
        PU L#45 (P#54)
      L2 L#23 (256KB) + L1d L#23 (32KB) + L1i L#23 (32KB) + Core L#23
        PU L#46 (P#23)
        PU L#47 (P#55)
      L2 L#24 (256KB) + L1d L#24 (32KB) + L1i L#24 (32KB) + Core L#24
        PU L#48 (P#24)
        PU L#49 (P#56)
      L2 L#25 (256KB) + L1d L#25 (32KB) + L1i L#25 (32KB) + Core L#25
        PU L#50 (P#25)
        PU L#51 (P#57)
      L2 L#26 (256KB) + L1d L#26 (32KB) + L1i L#26 (32KB) + Core L#26
        PU L#52 (P#26)
        PU L#53 (P#58)
      L2 L#27 (256KB) + L1d L#27 (32KB) + L1i L#27 (32KB) + Core L#27
        PU L#54 (P#27)
        PU L#55 (P#59)
      L2 L#28 (256KB) + L1d L#28 (32KB) + L1i L#28 (32KB) + Core L#28
        PU L#56 (P#28)
        PU L#57 (P#60)
      L2 L#29 (256KB) + L1d L#29 (32KB) + L1i L#29 (32KB) + Core L#29
        PU L#58 (P#29)
        PU L#59 (P#61)
      L2 L#30 (256KB) + L1d L#30 (32KB) + L1i L#30 (32KB) + Core L#30
        PU L#60 (P#30)
        PU L#61 (P#62)
      L2 L#31 (256KB) + L1d L#31 (32KB) + L1i L#31 (32KB) + Core L#31
        PU L#62 (P#31)
        PU L#63 (P#63)
    HostBridge L#5
      PCIBridge
        PCI 8086:1521
          Net L#5 "enp130s0f0" //两块PCI 千兆网卡
        PCI 8086:1521
          Net L#6 "enp130s0f1"
      PCIBridge
        PCI 144d:a804
      PCIBridge
        PCI 144d:a804

intel 还有一个自带的工具：cpuid-topo 可以看结构，以下是其中一个Socket的展示

img

海光

购买的AMD版权设计等搞出来国产的 x86 架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       43 bits physical, 48 bits virtual
CPU(s):              48
On-line CPU(s) list: 0-47
Thread(s) per core:  1 //我故意把超线程关掉了
Core(s) per socket:  24
Socket(s):           2
NUMA node(s):        8
Vendor ID:           HygonGenuine
CPU family:          24
Model:               1
Model name:          Hygon C86 7260 24-core Processor
Stepping:            1
Frequency boost:     enabled
CPU MHz:             1070.950
CPU max MHz:         2200.0000
CPU min MHz:         1200.0000
BogoMIPS:            4399.54
Virtualization:      AMD-V
L1d cache:           1.5 MiB //好大，不符合逻辑，后面解释
L1i cache:           3 MiB
L2 cache:            24 MiB  //48个物理核总共24MB L2，但是每个物理核只能用自己的512KB
L3 cache:            128 MiB // 
NUMA node0 CPU(s):   0-5
NUMA node1 CPU(s):   6-11
NUMA node2 CPU(s):   12-17
NUMA node3 CPU(s):   18-23
NUMA node4 CPU(s):   24-29
NUMA node5 CPU(s):   30-35
NUMA node6 CPU(s):   36-41
NUMA node7 CPU(s):   42-47 //搞了8个Numa Node

L1、L2太大了，好吓人，这么大不符合逻辑(太贵，没必要)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//继续看看L2 为啥这么大
#cd /sys/devices/system/cpu/cpu0

#ls cache/index2/
coherency_line_size      number_of_sets           shared_cpu_list          type
id                       physical_line_partition  shared_cpu_map           uevent
level                    power/                   size                     ways_of_associativity

#cat cache/index2/size
512K  //实际是512K， 2M是4个核共享，搞了个花活，但每个核只能用自己的512K

#cat cache/index2/shared_cpu_list
0  //确认 L2只有自己用

#cat cache/index3/shared_cpu_list
0-2 //L3 给0-2这3个物理核共享，一个Die下有6个物理核，每三个共享一个8M的L3

#cat cache/index3/size
8192K //3个物理核共享8M L3

#cat cache/index1/size
64K

#cat cache/index0/size
32K

index0/index1 分别代表啥？

海光为啥搞了8个Node，请看：https://plantegg.github.io/2021/03/08/%E6%B5%B7%E5%85%89CPU/

图片可以看高清大图

img

对应的字符结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
#lstopo
Machine (504GB total)
  Package L#0
    NUMANode L#0 (P#0 63GB)
      L3 L#0 (8192KB)
        L2 L#0 (512KB) + L1d L#0 (32KB) + L1i L#0 (64KB) + Core L#0 + PU L#0 (P#0)
        L2 L#1 (512KB) + L1d L#1 (32KB) + L1i L#1 (64KB) + Core L#1 + PU L#1 (P#1)
        L2 L#2 (512KB) + L1d L#2 (32KB) + L1i L#2 (64KB) + Core L#2 + PU L#2 (P#2)
      L3 L#1 (8192KB)
        L2 L#3 (512KB) + L1d L#3 (32KB) + L1i L#3 (64KB) + Core L#3 + PU L#3 (P#3)
        L2 L#4 (512KB) + L1d L#4 (32KB) + L1i L#4 (64KB) + Core L#4 + PU L#4 (P#4)
        L2 L#5 (512KB) + L1d L#5 (32KB) + L1i L#5 (64KB) + Core L#5 + PU L#5 (P#5)
      HostBridge L#0
        PCIBridge
          PCIBridge
            PCI 1a03:2000
              GPU L#0 "controlD64"
              GPU L#1 "card0"
        PCIBridge
          PCI 1d94:7901
            Block(Disk) L#2 "sda"
    NUMANode L#1 (P#1 63GB)
      L3 L#2 (8192KB)
        L2 L#6 (512KB) + L1d L#6 (32KB) + L1i L#6 (64KB) + Core L#6 + PU L#6 (P#6)
        L2 L#7 (512KB) + L1d L#7 (32KB) + L1i L#7 (64KB) + Core L#7 + PU L#7 (P#7)
        L2 L#8 (512KB) + L1d L#8 (32KB) + L1i L#8 (64KB) + Core L#8 + PU L#8 (P#8)
      L3 L#3 (8192KB)
        L2 L#9 (512KB) + L1d L#9 (32KB) + L1i L#9 (64KB) + Core L#9 + PU L#9 (P#9)
        L2 L#10 (512KB) + L1d L#10 (32KB) + L1i L#10 (64KB) + Core L#10 + PU L#10 (P#10)
        L2 L#11 (512KB) + L1d L#11 (32KB) + L1i L#11 (64KB) + Core L#11 + PU L#11 (P#11)
      HostBridge L#4
        PCIBridge
          PCI 1c5f:0557
            Block(Disk) L#3 "nvme0n1"
        PCIBridge
          PCI 1c5f:0557
            Block(Disk) L#4 "nvme1n1"
    NUMANode L#2 (P#2 63GB)
      L3 L#4 (8192KB)
        L2 L#12 (512KB) + L1d L#12 (32KB) + L1i L#12 (64KB) + Core L#12 + PU L#12 (P#12)
        L2 L#13 (512KB) + L1d L#13 (32KB) + L1i L#13 (64KB) + Core L#13 + PU L#13 (P#13)
        L2 L#14 (512KB) + L1d L#14 (32KB) + L1i L#14 (64KB) + Core L#14 + PU L#14 (P#14)
      L3 L#5 (8192KB)
        L2 L#15 (512KB) + L1d L#15 (32KB) + L1i L#15 (64KB) + Core L#15 + PU L#15 (P#15)
        L2 L#16 (512KB) + L1d L#16 (32KB) + L1i L#16 (64KB) + Core L#16 + PU L#16 (P#16)
        L2 L#17 (512KB) + L1d L#17 (32KB) + L1i L#17 (64KB) + Core L#17 + PU L#17 (P#17)
      HostBridge L#7
        PCIBridge
          PCI 15b3:1015
            Net L#5 "enp33s0f0"
            OpenFabrics L#6 "mlx5_0"
          PCI 15b3:1015
            Net L#7 "enp33s0f1"
            OpenFabrics L#8 "mlx5_1"
    NUMANode L#3 (P#3 63GB)
      L3 L#6 (8192KB)
        L2 L#18 (512KB) + L1d L#18 (32KB) + L1i L#18 (64KB) + Core L#18 + PU L#18 (P#18)
        L2 L#19 (512KB) + L1d L#19 (32KB) + L1i L#19 (64KB) + Core L#19 + PU L#19 (P#19)
        L2 L#20 (512KB) + L1d L#20 (32KB) + L1i L#20 (64KB) + Core L#20 + PU L#20 (P#20)
      L3 L#7 (8192KB)
        L2 L#21 (512KB) + L1d L#21 (32KB) + L1i L#21 (64KB) + Core L#21 + PU L#21 (P#21)
        L2 L#22 (512KB) + L1d L#22 (32KB) + L1i L#22 (64KB) + Core L#22 + PU L#22 (P#22)
        L2 L#23 (512KB) + L1d L#23 (32KB) + L1i L#23 (64KB) + Core L#23 + PU L#23 (P#23)
      HostBridge L#9
        PCIBridge
          PCI 8086:1521
            Net L#9 "eno1"
          PCI 8086:1521
            Net L#10 "eno2"
  Package L#1
    NUMANode L#4 (P#4 63GB)
      L3 L#8 (8192KB)
        L2 L#24 (512KB) + L1d L#24 (32KB) + L1i L#24 (64KB) + Core L#24 + PU L#24 (P#24)
        L2 L#25 (512KB) + L1d L#25 (32KB) + L1i L#25 (64KB) + Core L#25 + PU L#25 (P#25)
        L2 L#26 (512KB) + L1d L#26 (32KB) + L1i L#26 (64KB) + Core L#26 + PU L#26 (P#26)
      L3 L#9 (8192KB)
        L2 L#27 (512KB) + L1d L#27 (32KB) + L1i L#27 (64KB) + Core L#27 + PU L#27 (P#27)
        L2 L#28 (512KB) + L1d L#28 (32KB) + L1i L#28 (64KB) + Core L#28 + PU L#28 (P#28)
        L2 L#29 (512KB) + L1d L#29 (32KB) + L1i L#29 (64KB) + Core L#29 + PU L#29 (P#29)
    NUMANode L#5 (P#5 63GB)
      L3 L#10 (8192KB)
        L2 L#30 (512KB) + L1d L#30 (32KB) + L1i L#30 (64KB) + Core L#30 + PU L#30 (P#30)
        L2 L#31 (512KB) + L1d L#31 (32KB) + L1i L#31 (64KB) + Core L#31 + PU L#31 (P#31)
        L2 L#32 (512KB) + L1d L#32 (32KB) + L1i L#32 (64KB) + Core L#32 + PU L#32 (P#32)
      L3 L#11 (8192KB)
        L2 L#33 (512KB) + L1d L#33 (32KB) + L1i L#33 (64KB) + Core L#33 + PU L#33 (P#33)
        L2 L#34 (512KB) + L1d L#34 (32KB) + L1i L#34 (64KB) + Core L#34 + PU L#34 (P#34)
        L2 L#35 (512KB) + L1d L#35 (32KB) + L1i L#35 (64KB) + Core L#35 + PU L#35 (P#35)
      HostBridge L#11
        PCIBridge
          PCI 1d94:7901
    NUMANode L#6 (P#6 63GB)
      L3 L#12 (8192KB)
        L2 L#36 (512KB) + L1d L#36 (32KB) + L1i L#36 (64KB) + Core L#36 + PU L#36 (P#36)
        L2 L#37 (512KB) + L1d L#37 (32KB) + L1i L#37 (64KB) + Core L#37 + PU L#37 (P#37)
        L2 L#38 (512KB) + L1d L#38 (32KB) + L1i L#38 (64KB) + Core L#38 + PU L#38 (P#38)
      L3 L#13 (8192KB)
        L2 L#39 (512KB) + L1d L#39 (32KB) + L1i L#39 (64KB) + Core L#39 + PU L#39 (P#39)
        L2 L#40 (512KB) + L1d L#40 (32KB) + L1i L#40 (64KB) + Core L#40 + PU L#40 (P#40)
        L2 L#41 (512KB) + L1d L#41 (32KB) + L1i L#41 (64KB) + Core L#41 + PU L#41 (P#41)
    NUMANode L#7 (P#7 63GB)
      L3 L#14 (8192KB)
        L2 L#42 (512KB) + L1d L#42 (32KB) + L1i L#42 (64KB) + Core L#42 + PU L#42 (P#42)
        L2 L#43 (512KB) + L1d L#43 (32KB) + L1i L#43 (64KB) + Core L#43 + PU L#43 (P#43)
        L2 L#44 (512KB) + L1d L#44 (32KB) + L1i L#44 (64KB) + Core L#44 + PU L#44 (P#44)
      L3 L#15 (8192KB)
        L2 L#45 (512KB) + L1d L#45 (32KB) + L1i L#45 (64KB) + Core L#45 + PU L#45 (P#45)
        L2 L#46 (512KB) + L1d L#46 (32KB) + L1i L#46 (64KB) + Core L#46 + PU L#46 (P#46)
        L2 L#47 (512KB) + L1d L#47 (32KB) + L1i L#47 (64KB) + Core L#47 + PU L#47 (P#47)
  Misc(MemoryModule)
  Misc(MemoryModule)
  Misc(MemoryModule)

以上是海光的7260，还有一个CPU是海光 7280：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                128
On-line CPU(s) list:   0-127
Thread(s) per core:    2
Core(s) per socket:    32
Socket(s):             2
NUMA node(s):          8
Vendor ID:             HygonGenuine
CPU family:            24
Model:                 1
Model name:            Hygon C86 7280 32-core Processor
Stepping:              1
CPU MHz:               1981.025
CPU max MHz:           2000.0000
CPU min MHz:           1200.0000
BogoMIPS:              3999.55
Virtualization:        AMD-V
L1d cache:             32K
L1i cache:             64K
L2 cache:              512K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7,64-71
NUMA node1 CPU(s):     8-15,72-79
NUMA node2 CPU(s):     16-23,80-87
NUMA node3 CPU(s):     24-31,88-95
NUMA node4 CPU(s):     32-39,96-103
NUMA node5 CPU(s):     40-47,104-111
NUMA node6 CPU(s):     48-55,112-119
NUMA node7 CPU(s):     56-63,120-127

作业：7260和7280的区别是？为什么搞了这两个差异很小的CPU？

1
2
3
4
5
6
7
//继续在7280上看看L3的大小和共享，能够识别他的Die设计理念

//7280上 L3 由8个超线程，也就是4个物理核共享
#cat cache/index3/shared_cpu_list
0-3,64-67      //就这里核数不一样
#cat cache/index3/size
8192K          //L3大小和7260一样

还记得7260是3个物理核共享一个8M的L3吧，计算机的世界大多是1、2、4、8，看到3我就觉得有些别扭。评论区告诉我为什么会搞出3个核这样一个奇葩设计？（星球图解专栏里有答案）

AMD 7T83

整机256核，一路128超线程，单CPU 64个物理核，很猛了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
#lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                256
On-line CPU(s) list:   0-255
Thread(s) per core:    2
Core(s) per socket:    64
Socket(s):             2
NUMA node(s):          4
Vendor ID:             AuthenticAMD
CPU family:            25
Model:                 1
Model name:            AMD EPYC 7T83 64-Core Processor
Stepping:              1
CPU MHz:               1638.563    //主频有点低，估计还是核太多了
CPU max MHz:           2550.0000
CPU min MHz:           1500.0000
BogoMIPS:              5090.06
Virtualization:        AMD-V
L1d cache:             32K
L1i cache:             32K
L2 cache:              512K
L3 cache:              32768K
NUMA node0 CPU(s):     0-31,128-159
NUMA node1 CPU(s):     32-63,160-191
NUMA node2 CPU(s):     64-95,192-223
NUMA node3 CPU(s):     96-127,224-255 //这里展示的是4个Node，在Bios中可配置

#lstopo-no-graphics
Machine (2015GB) //2T 内存
  Socket L#0 (1007GB) //单路 1T内存，一路下有两个Numa Node
    NUMANode L#0 (P#0 503GB) //这个Node下有4块独立的L3 
      L3 L#0 (32MB) //看起来16个超线程共享这一个L3，其实这16个核应该是一个独立的Node比较好
        L2 L#0 (512KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
          PU L#0 (P#0)
          PU L#1 (P#128)
        L2 L#1 (512KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1
          PU L#2 (P#1)
          PU L#3 (P#129)
        L2 L#2 (512KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2
          PU L#4 (P#2)
          PU L#5 (P#130)
        L2 L#3 (512KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3
          PU L#6 (P#3)
          PU L#7 (P#131)
        L2 L#4 (512KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4
          PU L#8 (P#4)
          PU L#9 (P#132)
        L2 L#5 (512KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5
          PU L#10 (P#5)
          PU L#11 (P#133)
        L2 L#6 (512KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6
          PU L#12 (P#6)
          PU L#13 (P#134)
        L2 L#7 (512KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7
          PU L#14 (P#7)
          PU L#15 (P#135)
      L3 L#1 (32MB)
        L2 L#8 (512KB) + L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8
          PU L#16 (P#8)
          PU L#17 (P#136)
        L2 L#9 (512KB) + L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9
          PU L#18 (P#9)
          PU L#19 (P#137)
        L2 L#10 (512KB) + L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10
          PU L#20 (P#10)
          PU L#21 (P#138)
        L2 L#11 (512KB) + L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11
          PU L#22 (P#11)
          PU L#23 (P#139)
        L2 L#12 (512KB) + L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12
          PU L#24 (P#12)
          PU L#25 (P#140)
        L2 L#13 (512KB) + L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13
          PU L#26 (P#13)
          PU L#27 (P#141)
        L2 L#14 (512KB) + L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14
          PU L#28 (P#14)
          PU L#29 (P#142)
        L2 L#15 (512KB) + L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15
          PU L#30 (P#15)
          PU L#31 (P#143)
      L3 L#2 (32MB)
        L2 L#16 (512KB) + L1d L#16 (32KB) + L1i L#16 (32KB) + Core L#16
          PU L#32 (P#16)
          PU L#33 (P#144)
        L2 L#17 (512KB) + L1d L#17 (32KB) + L1i L#17 (32KB) + Core L#17
          PU L#34 (P#17)
          PU L#35 (P#145)
        L2 L#18 (512KB) + L1d L#18 (32KB) + L1i L#18 (32KB) + Core L#18
          PU L#36 (P#18)
          PU L#37 (P#146)
        L2 L#19 (512KB) + L1d L#19 (32KB) + L1i L#19 (32KB) + Core L#19
          PU L#38 (P#19)
          PU L#39 (P#147)
        L2 L#20 (512KB) + L1d L#20 (32KB) + L1i L#20 (32KB) + Core L#20
          PU L#40 (P#20)
          PU L#41 (P#148)
        L2 L#21 (512KB) + L1d L#21 (32KB) + L1i L#21 (32KB) + Core L#21
          PU L#42 (P#21)
          PU L#43 (P#149)
        L2 L#22 (512KB) + L1d L#22 (32KB) + L1i L#22 (32KB) + Core L#22
          PU L#44 (P#22)
          PU L#45 (P#150)
        L2 L#23 (512KB) + L1d L#23 (32KB) + L1i L#23 (32KB) + Core L#23
          PU L#46 (P#23)
          PU L#47 (P#151)
      L3 L#3 (32MB)
        L2 L#24 (512KB) + L1d L#24 (32KB) + L1i L#24 (32KB) + Core L#24
          PU L#48 (P#24)
          PU L#49 (P#152)
        L2 L#25 (512KB) + L1d L#25 (32KB) + L1i L#25 (32KB) + Core L#25
          PU L#50 (P#25)
          PU L#51 (P#153)
        L2 L#26 (512KB) + L1d L#26 (32KB) + L1i L#26 (32KB) + Core L#26
          PU L#52 (P#26)
          PU L#53 (P#154)
        L2 L#27 (512KB) + L1d L#27 (32KB) + L1i L#27 (32KB) + Core L#27
          PU L#54 (P#27)
          PU L#55 (P#155)
        L2 L#28 (512KB) + L1d L#28 (32KB) + L1i L#28 (32KB) + Core L#28
          PU L#56 (P#28)
          PU L#57 (P#156)
        L2 L#29 (512KB) + L1d L#29 (32KB) + L1i L#29 (32KB) + Core L#29
          PU L#58 (P#29)
          PU L#59 (P#157)
        L2 L#30 (512KB) + L1d L#30 (32KB) + L1i L#30 (32KB) + Core L#30
          PU L#60 (P#30)
          PU L#61 (P#158)
        L2 L#31 (512KB) + L1d L#31 (32KB) + L1i L#31 (32KB) + Core L#31
          PU L#62 (P#31)
          PU L#63 (P#159)
      HostBridge L#0
        PCIBridge
          PCI 144d:a80a
        PCIBridge
          PCI 144d:a80a
        PCIBridge
          PCIBridge
            PCI 1a03:2000
              GPU L#0 "controlD64"
              GPU L#1 "card0"
    NUMANode L#1 (P#1 504GB)
      L3 L#4 (32MB)
        L2 L#32 (512KB) + L1d L#32 (32KB) + L1i L#32 (32KB) + Core L#32
          PU L#64 (P#32)
          PU L#65 (P#160)
        L2 L#33 (512KB) + L1d L#33 (32KB) + L1i L#33 (32KB) + Core L#33
          PU L#66 (P#33)
          PU L#67 (P#161)
        L2 L#34 (512KB) + L1d L#34 (32KB) + L1i L#34 (32KB) + Core L#34
          PU L#68 (P#34)
          PU L#69 (P#162)
        L2 L#35 (512KB) + L1d L#35 (32KB) + L1i L#35 (32KB) + Core L#35
          PU L#70 (P#35)
          PU L#71 (P#163)
        L2 L#36 (512KB) + L1d L#36 (32KB) + L1i L#36 (32KB) + Core L#36
          PU L#72 (P#36)
          PU L#73 (P#164)
        L2 L#37 (512KB) + L1d L#37 (32KB) + L1i L#37 (32KB) + Core L#37
          PU L#74 (P#37)
          PU L#75 (P#165)
        L2 L#38 (512KB) + L1d L#38 (32KB) + L1i L#38 (32KB) + Core L#38
          PU L#76 (P#38)
          PU L#77 (P#166)
        L2 L#39 (512KB) + L1d L#39 (32KB) + L1i L#39 (32KB) + Core L#39
          PU L#78 (P#39)
          PU L#79 (P#167)
      L3 L#5 (32MB)
        L2 L#40 (512KB) + L1d L#40 (32KB) + L1i L#40 (32KB) + Core L#40
          PU L#80 (P#40)
          PU L#81 (P#168)
        L2 L#41 (512KB) + L1d L#41 (32KB) + L1i L#41 (32KB) + Core L#41
          PU L#82 (P#41)
          PU L#83 (P#169)
        L2 L#42 (512KB) + L1d L#42 (32KB) + L1i L#42 (32KB) + Core L#42
          PU L#84 (P#42)
          PU L#85 (P#170)
        L2 L#43 (512KB) + L1d L#43 (32KB) + L1i L#43 (32KB) + Core L#43
          PU L#86 (P#43)
          PU L#87 (P#171)
        L2 L#44 (512KB) + L1d L#44 (32KB) + L1i L#44 (32KB) + Core L#44
          PU L#88 (P#44)
          PU L#89 (P#172)
        L2 L#45 (512KB) + L1d L#45 (32KB) + L1i L#45 (32KB) + Core L#45
          PU L#90 (P#45)
          PU L#91 (P#173)
        L2 L#46 (512KB) + L1d L#46 (32KB) + L1i L#46 (32KB) + Core L#46
          PU L#92 (P#46)
          PU L#93 (P#174)
        L2 L#47 (512KB) + L1d L#47 (32KB) + L1i L#47 (32KB) + Core L#47
          PU L#94 (P#47)
          PU L#95 (P#175)
      L3 L#6 (32MB)
        L2 L#48 (512KB) + L1d L#48 (32KB) + L1i L#48 (32KB) + Core L#48
          PU L#96 (P#48)
          PU L#97 (P#176)
        L2 L#49 (512KB) + L1d L#49 (32KB) + L1i L#49 (32KB) + Core L#49
          PU L#98 (P#49)
          PU L#99 (P#177)
        L2 L#50 (512KB) + L1d L#50 (32KB) + L1i L#50 (32KB) + Core L#50
          PU L#100 (P#50)
          PU L#101 (P#178)
        L2 L#51 (512KB) + L1d L#51 (32KB) + L1i L#51 (32KB) + Core L#51
          PU L#102 (P#51)
          PU L#103 (P#179)
        L2 L#52 (512KB) + L1d L#52 (32KB) + L1i L#52 (32KB) + Core L#52
          PU L#104 (P#52)
          PU L#105 (P#180)
        L2 L#53 (512KB) + L1d L#53 (32KB) + L1i L#53 (32KB) + Core L#53
          PU L#106 (P#53)
          PU L#107 (P#181)
        L2 L#54 (512KB) + L1d L#54 (32KB) + L1i L#54 (32KB) + Core L#54
          PU L#108 (P#54)
          PU L#109 (P#182)
        L2 L#55 (512KB) + L1d L#55 (32KB) + L1i L#55 (32KB) + Core L#55
          PU L#110 (P#55)
          PU L#111 (P#183)
      L3 L#7 (32MB)
        L2 L#56 (512KB) + L1d L#56 (32KB) + L1i L#56 (32KB) + Core L#56
          PU L#112 (P#56)
          PU L#113 (P#184)
        L2 L#57 (512KB) + L1d L#57 (32KB) + L1i L#57 (32KB) + Core L#57
          PU L#114 (P#57)
          PU L#115 (P#185)
        L2 L#58 (512KB) + L1d L#58 (32KB) + L1i L#58 (32KB) + Core L#58
          PU L#116 (P#58)
          PU L#117 (P#186)
        L2 L#59 (512KB) + L1d L#59 (32KB) + L1i L#59 (32KB) + Core L#59
          PU L#118 (P#59)
          PU L#119 (P#187)
        L2 L#60 (512KB) + L1d L#60 (32KB) + L1i L#60 (32KB) + Core L#60
          PU L#120 (P#60)
          PU L#121 (P#188)
        L2 L#61 (512KB) + L1d L#61 (32KB) + L1i L#61 (32KB) + Core L#61
          PU L#122 (P#61)
          PU L#123 (P#189)
        L2 L#62 (512KB) + L1d L#62 (32KB) + L1i L#62 (32KB) + Core L#62
          PU L#124 (P#62)
          PU L#125 (P#190)
        L2 L#63 (512KB) + L1d L#63 (32KB) + L1i L#63 (32KB) + Core L#63
          PU L#126 (P#63)
          PU L#127 (P#191)
      HostBridge L#5
        PCIBridge
          PCIBridge
            PCIBridge
              PCI 1af4:1001
            PCIBridge
              PCI 1ded:1001
              PCI ffff:ffff

  Socket L#1 (1008GB)
    NUMANode L#2 (P#2 504GB)
      L3 L#8 (32MB)
        L2 L#64 (512KB) + L1d L#64 (32KB) + L1i L#64 (32KB) + Core L#64
          PU L#128 (P#64)
          PU L#129 (P#192)
        L2 L#65 (512KB) + L1d L#65 (32KB) + L1i L#65 (32KB) + Core L#65
          PU L#130 (P#65)
          PU L#131 (P#193)
        L2 L#66 (512KB) + L1d L#66 (32KB) + L1i L#66 (32KB) + Core L#66
          PU L#132 (P#66)
          PU L#133 (P#194)
        L2 L#67 (512KB) + L1d L#67 (32KB) + L1i L#67 (32KB) + Core L#67
          PU L#134 (P#67)
          PU L#135 (P#195)
        L2 L#68 (512KB) + L1d L#68 (32KB) + L1i L#68 (32KB) + Core L#68
          PU L#136 (P#68)
          PU L#137 (P#196)
        L2 L#69 (512KB) + L1d L#69 (32KB) + L1i L#69 (32KB) + Core L#69
          PU L#138 (P#69)
          PU L#139 (P#197)
        L2 L#70 (512KB) + L1d L#70 (32KB) + L1i L#70 (32KB) + Core L#70
          PU L#140 (P#70)
          PU L#141 (P#198)
        L2 L#71 (512KB) + L1d L#71 (32KB) + L1i L#71 (32KB) + Core L#71
          PU L#142 (P#71)
          PU L#143 (P#199)
      L3 L#9 (32MB)
        L2 L#72 (512KB) + L1d L#72 (32KB) + L1i L#72 (32KB) + Core L#72
          PU L#144 (P#72)
          PU L#145 (P#200)
        L2 L#73 (512KB) + L1d L#73 (32KB) + L1i L#73 (32KB) + Core L#73
          PU L#146 (P#73)
          PU L#147 (P#201)
        L2 L#74 (512KB) + L1d L#74 (32KB) + L1i L#74 (32KB) + Core L#74
          PU L#148 (P#74)
          PU L#149 (P#202)
        L2 L#75 (512KB) + L1d L#75 (32KB) + L1i L#75 (32KB) + Core L#75
          PU L#150 (P#75)
          PU L#151 (P#203)
        L2 L#76 (512KB) + L1d L#76 (32KB) + L1i L#76 (32KB) + Core L#76
          PU L#152 (P#76)
          PU L#153 (P#204)
        L2 L#77 (512KB) + L1d L#77 (32KB) + L1i L#77 (32KB) + Core L#77
          PU L#154 (P#77)
          PU L#155 (P#205)
        L2 L#78 (512KB) + L1d L#78 (32KB) + L1i L#78 (32KB) + Core L#78
          PU L#156 (P#78)
          PU L#157 (P#206)
        L2 L#79 (512KB) + L1d L#79 (32KB) + L1i L#79 (32KB) + Core L#79
          PU L#158 (P#79)
          PU L#159 (P#207)
      L3 L#10 (32MB)
        L2 L#80 (512KB) + L1d L#80 (32KB) + L1i L#80 (32KB) + Core L#80
          PU L#160 (P#80)
          PU L#161 (P#208)
        L2 L#81 (512KB) + L1d L#81 (32KB) + L1i L#81 (32KB) + Core L#81
          PU L#162 (P#81)
          PU L#163 (P#209)
        L2 L#82 (512KB) + L1d L#82 (32KB) + L1i L#82 (32KB) + Core L#82
          PU L#164 (P#82)
          PU L#165 (P#210)
        L2 L#83 (512KB) + L1d L#83 (32KB) + L1i L#83 (32KB) + Core L#83
          PU L#166 (P#83)
          PU L#167 (P#211)
        L2 L#84 (512KB) + L1d L#84 (32KB) + L1i L#84 (32KB) + Core L#84
          PU L#168 (P#84)
          PU L#169 (P#212)
        L2 L#85 (512KB) + L1d L#85 (32KB) + L1i L#85 (32KB) + Core L#85
          PU L#170 (P#85)
          PU L#171 (P#213)
        L2 L#86 (512KB) + L1d L#86 (32KB) + L1i L#86 (32KB) + Core L#86
          PU L#172 (P#86)
          PU L#173 (P#214)
        L2 L#87 (512KB) + L1d L#87 (32KB) + L1i L#87 (32KB) + Core L#87
          PU L#174 (P#87)
          PU L#175 (P#215)
      L3 L#11 (32MB)
        L2 L#88 (512KB) + L1d L#88 (32KB) + L1i L#88 (32KB) + Core L#88
          PU L#176 (P#88)
          PU L#177 (P#216)
        L2 L#89 (512KB) + L1d L#89 (32KB) + L1i L#89 (32KB) + Core L#89
          PU L#178 (P#89)
          PU L#179 (P#217)
        L2 L#90 (512KB) + L1d L#90 (32KB) + L1i L#90 (32KB) + Core L#90
          PU L#180 (P#90)
          PU L#181 (P#218)
        L2 L#91 (512KB) + L1d L#91 (32KB) + L1i L#91 (32KB) + Core L#91
          PU L#182 (P#91)
          PU L#183 (P#219)
        L2 L#92 (512KB) + L1d L#92 (32KB) + L1i L#92 (32KB) + Core L#92
          PU L#184 (P#92)
          PU L#185 (P#220)
        L2 L#93 (512KB) + L1d L#93 (32KB) + L1i L#93 (32KB) + Core L#93
          PU L#186 (P#93)
          PU L#187 (P#221)
        L2 L#94 (512KB) + L1d L#94 (32KB) + L1i L#94 (32KB) + Core L#94
          PU L#188 (P#94)
          PU L#189 (P#222)
        L2 L#95 (512KB) + L1d L#95 (32KB) + L1i L#95 (32KB) + Core L#95
          PU L#190 (P#95)
          PU L#191 (P#223)
    NUMANode L#3 (P#3 504GB)
      L3 L#12 (32MB)
        L2 L#96 (512KB) + L1d L#96 (32KB) + L1i L#96 (32KB) + Core L#96
          PU L#192 (P#96)
          PU L#193 (P#224)
        L2 L#97 (512KB) + L1d L#97 (32KB) + L1i L#97 (32KB) + Core L#97
          PU L#194 (P#97)
          PU L#195 (P#225)
        L2 L#98 (512KB) + L1d L#98 (32KB) + L1i L#98 (32KB) + Core L#98
          PU L#196 (P#98)
          PU L#197 (P#226)
        L2 L#99 (512KB) + L1d L#99 (32KB) + L1i L#99 (32KB) + Core L#99
          PU L#198 (P#99)
          PU L#199 (P#227)
        L2 L#100 (512KB) + L1d L#100 (32KB) + L1i L#100 (32KB) + Core L#100
          PU L#200 (P#100)
          PU L#201 (P#228)
        L2 L#101 (512KB) + L1d L#101 (32KB) + L1i L#101 (32KB) + Core L#101
          PU L#202 (P#101)
          PU L#203 (P#229)
        L2 L#102 (512KB) + L1d L#102 (32KB) + L1i L#102 (32KB) + Core L#102
          PU L#204 (P#102)
          PU L#205 (P#230)
        L2 L#103 (512KB) + L1d L#103 (32KB) + L1i L#103 (32KB) + Core L#103
          PU L#206 (P#103)
          PU L#207 (P#231)
      L3 L#13 (32MB)
        L2 L#104 (512KB) + L1d L#104 (32KB) + L1i L#104 (32KB) + Core L#104
          PU L#208 (P#104)
          PU L#209 (P#232)
        L2 L#105 (512KB) + L1d L#105 (32KB) + L1i L#105 (32KB) + Core L#105
          PU L#210 (P#105)
          PU L#211 (P#233)
        L2 L#106 (512KB) + L1d L#106 (32KB) + L1i L#106 (32KB) + Core L#106
          PU L#212 (P#106)
          PU L#213 (P#234)
        L2 L#107 (512KB) + L1d L#107 (32KB) + L1i L#107 (32KB) + Core L#107
          PU L#214 (P#107)
          PU L#215 (P#235)
        L2 L#108 (512KB) + L1d L#108 (32KB) + L1i L#108 (32KB) + Core L#108
          PU L#216 (P#108)
          PU L#217 (P#236)
        L2 L#109 (512KB) + L1d L#109 (32KB) + L1i L#109 (32KB) + Core L#109
          PU L#218 (P#109)
          PU L#219 (P#237)
        L2 L#110 (512KB) + L1d L#110 (32KB) + L1i L#110 (32KB) + Core L#110
          PU L#220 (P#110)
          PU L#221 (P#238)
        L2 L#111 (512KB) + L1d L#111 (32KB) + L1i L#111 (32KB) + Core L#111
          PU L#222 (P#111)
          PU L#223 (P#239)
      L3 L#14 (32MB)
        L2 L#112 (512KB) + L1d L#112 (32KB) + L1i L#112 (32KB) + Core L#112
          PU L#224 (P#112)
          PU L#225 (P#240)
        L2 L#113 (512KB) + L1d L#113 (32KB) + L1i L#113 (32KB) + Core L#113
          PU L#226 (P#113)
          PU L#227 (P#241)
        L2 L#114 (512KB) + L1d L#114 (32KB) + L1i L#114 (32KB) + Core L#114
          PU L#228 (P#114)
          PU L#229 (P#242)
        L2 L#115 (512KB) + L1d L#115 (32KB) + L1i L#115 (32KB) + Core L#115
          PU L#230 (P#115)
          PU L#231 (P#243)
        L2 L#116 (512KB) + L1d L#116 (32KB) + L1i L#116 (32KB) + Core L#116
          PU L#232 (P#116)
          PU L#233 (P#244)
        L2 L#117 (512KB) + L1d L#117 (32KB) + L1i L#117 (32KB) + Core L#117
          PU L#234 (P#117)
          PU L#235 (P#245)
        L2 L#118 (512KB) + L1d L#118 (32KB) + L1i L#118 (32KB) + Core L#118
          PU L#236 (P#118)
          PU L#237 (P#246)
        L2 L#119 (512KB) + L1d L#119 (32KB) + L1i L#119 (32KB) + Core L#119
          PU L#238 (P#119)
          PU L#239 (P#247)
      L3 L#15 (32MB)
        L2 L#120 (512KB) + L1d L#120 (32KB) + L1i L#120 (32KB) + Core L#120
          PU L#240 (P#120)
          PU L#241 (P#248)
        L2 L#121 (512KB) + L1d L#121 (32KB) + L1i L#121 (32KB) + Core L#121
          PU L#242 (P#121)
          PU L#243 (P#249)
        L2 L#122 (512KB) + L1d L#122 (32KB) + L1i L#122 (32KB) + Core L#122
          PU L#244 (P#122)
          PU L#245 (P#250)
        L2 L#123 (512KB) + L1d L#123 (32KB) + L1i L#123 (32KB) + Core L#123
          PU L#246 (P#123)
          PU L#247 (P#251)
        L2 L#124 (512KB) + L1d L#124 (32KB) + L1i L#124 (32KB) + Core L#124
          PU L#248 (P#124)
          PU L#249 (P#252)
        L2 L#125 (512KB) + L1d L#125 (32KB) + L1i L#125 (32KB) + Core L#125
          PU L#250 (P#125)
          PU L#251 (P#253)
        L2 L#126 (512KB) + L1d L#126 (32KB) + L1i L#126 (32KB) + Core L#126
          PU L#252 (P#126)
          PU L#253 (P#254)
        L2 L#127 (512KB) + L1d L#127 (32KB) + L1i L#127 (32KB) + Core L#127
          PU L#254 (P#127)
          PU L#255 (P#255)

这台机器改下BIOS设置

img

白色Channel 那里可以选择Auto/Die/Channel/Socket, 选择Socket后得到如下Node 结构:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                256
On-line CPU(s) list:   0-255
Thread(s) per core:    2
Core(s) per socket:    64
Socket(s):             2
NUMA node(s):          2
Vendor ID:             AuthenticAMD
CPU family:            25
Model:                 1
Model name:            AMD EPYC 7T83 64-Core Processor
Stepping:              1
CPU MHz:               2399.192
CPU max MHz:           2550.0000
CPU min MHz:           1500.0000
BogoMIPS:              5090.50
Virtualization:        AMD-V
L1d cache:             32K
L1i cache:             32K
L2 cache:              512K
L3 cache:              32768K
NUMA node0 CPU(s):     0-63,128-191
NUMA node1 CPU(s):     64-127,192-255 //每个socket下的内存交织，也就是一个Socket是一个独立的 Numa Node

鲲鹏 920

鲲鹏是ARM架构，一般都没有超线程，因为指令简单流水线较流畅，搞超线程收益不大

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
# lscpu
架构：                           aarch64
CPU 运行模式：                   64-bit
字节序：                         Little Endian
CPU:                             96
在线 CPU 列表：                  0-95
每个核的线程数：                 1
每个座的核数：                   48
座：                             2
NUMA 节点：                      4
厂商 ID：                        HiSilicon
型号：                           0
型号名称：                       Kunpeng-920
步进：                           0x1
CPU 最大 MHz：                   2600.0000
CPU 最小 MHz：                   200.0000
BogoMIPS：                       200.00
L1d 缓存：                       6 MiB
L1i 缓存：                       6 MiB
L2 缓存：                        48 MiB
L3 缓存：                        96 MiB
NUMA 节点0 CPU：                 0-23
NUMA 节点1 CPU：                 24-47
NUMA 节点2 CPU：                 48-71
NUMA 节点3 CPU：                 72-95

#lstopo
Machine (766GB total)
  Package L#0
    NUMANode L#0 (P#0 191GB)
      L3 L#0 (24MB)
        L2 L#0 (512KB) + L1d L#0 (64KB) + L1i L#0 (64KB) + Core L#0 + PU L#0 (P#0)
        L2 L#1 (512KB) + L1d L#1 (64KB) + L1i L#1 (64KB) + Core L#1 + PU L#1 (P#1)
        L2 L#2 (512KB) + L1d L#2 (64KB) + L1i L#2 (64KB) + Core L#2 + PU L#2 (P#2)
        L2 L#3 (512KB) + L1d L#3 (64KB) + L1i L#3 (64KB) + Core L#3 + PU L#3 (P#3)
        L2 L#4 (512KB) + L1d L#4 (64KB) + L1i L#4 (64KB) + Core L#4 + PU L#4 (P#4)
        L2 L#5 (512KB) + L1d L#5 (64KB) + L1i L#5 (64KB) + Core L#5 + PU L#5 (P#5)
        L2 L#6 (512KB) + L1d L#6 (64KB) + L1i L#6 (64KB) + Core L#6 + PU L#6 (P#6)
        L2 L#7 (512KB) + L1d L#7 (64KB) + L1i L#7 (64KB) + Core L#7 + PU L#7 (P#7)
        L2 L#8 (512KB) + L1d L#8 (64KB) + L1i L#8 (64KB) + Core L#8 + PU L#8 (P#8)
        L2 L#9 (512KB) + L1d L#9 (64KB) + L1i L#9 (64KB) + Core L#9 + PU L#9 (P#9)
        L2 L#10 (512KB) + L1d L#10 (64KB) + L1i L#10 (64KB) + Core L#10 + PU L#10 (P#10)
        L2 L#11 (512KB) + L1d L#11 (64KB) + L1i L#11 (64KB) + Core L#11 + PU L#11 (P#11)
        L2 L#12 (512KB) + L1d L#12 (64KB) + L1i L#12 (64KB) + Core L#12 + PU L#12 (P#12)
        L2 L#13 (512KB) + L1d L#13 (64KB) + L1i L#13 (64KB) + Core L#13 + PU L#13 (P#13)
        L2 L#14 (512KB) + L1d L#14 (64KB) + L1i L#14 (64KB) + Core L#14 + PU L#14 (P#14)
        L2 L#15 (512KB) + L1d L#15 (64KB) + L1i L#15 (64KB) + Core L#15 + PU L#15 (P#15)
        L2 L#16 (512KB) + L1d L#16 (64KB) + L1i L#16 (64KB) + Core L#16 + PU L#16 (P#16)
        L2 L#17 (512KB) + L1d L#17 (64KB) + L1i L#17 (64KB) + Core L#17 + PU L#17 (P#17)
        L2 L#18 (512KB) + L1d L#18 (64KB) + L1i L#18 (64KB) + Core L#18 + PU L#18 (P#18)
        L2 L#19 (512KB) + L1d L#19 (64KB) + L1i L#19 (64KB) + Core L#19 + PU L#19 (P#19)
        L2 L#20 (512KB) + L1d L#20 (64KB) + L1i L#20 (64KB) + Core L#20 + PU L#20 (P#20)
        L2 L#21 (512KB) + L1d L#21 (64KB) + L1i L#21 (64KB) + Core L#21 + PU L#21 (P#21)
        L2 L#22 (512KB) + L1d L#22 (64KB) + L1i L#22 (64KB) + Core L#22 + PU L#22 (P#22)
        L2 L#23 (512KB) + L1d L#23 (64KB) + L1i L#23 (64KB) + Core L#23 + PU L#23 (P#23)
      HostBridge L#0
        PCIBridge
          PCI 15b3:1017
            Net L#0 "enp2s0f0"
          PCI 15b3:1017
            Net L#1 "enp2s0f1"
        PCIBridge
          PCI 19e5:1711
            GPU L#2 "controlD64"
            GPU L#3 "card0"
      HostBridge L#3
        2 x { PCI 19e5:a230 }
        PCI 19e5:a235
          Block(Disk) L#4 "sda"
      HostBridge L#4
        PCIBridge
          PCI 19e5:a222
            Net L#5 "enp125s0f0"
            OpenFabrics L#6 "hns_0"
          PCI 19e5:a221
            Net L#7 "enp125s0f1"
          PCI 19e5:a222
            Net L#8 "enp125s0f2"
            OpenFabrics L#9 "hns_1"
          PCI 19e5:a221
            Net L#10 "enp125s0f3"
    NUMANode L#1 (P#1 192GB) + L3 L#1 (24MB)
      L2 L#24 (512KB) + L1d L#24 (64KB) + L1i L#24 (64KB) + Core L#24 + PU L#24 (P#24)
      L2 L#25 (512KB) + L1d L#25 (64KB) + L1i L#25 (64KB) + Core L#25 + PU L#25 (P#25)
      L2 L#26 (512KB) + L1d L#26 (64KB) + L1i L#26 (64KB) + Core L#26 + PU L#26 (P#26)
      L2 L#27 (512KB) + L1d L#27 (64KB) + L1i L#27 (64KB) + Core L#27 + PU L#27 (P#27)
      L2 L#28 (512KB) + L1d L#28 (64KB) + L1i L#28 (64KB) + Core L#28 + PU L#28 (P#28)
      L2 L#29 (512KB) + L1d L#29 (64KB) + L1i L#29 (64KB) + Core L#29 + PU L#29 (P#29)
      L2 L#30 (512KB) + L1d L#30 (64KB) + L1i L#30 (64KB) + Core L#30 + PU L#30 (P#30)
      L2 L#31 (512KB) + L1d L#31 (64KB) + L1i L#31 (64KB) + Core L#31 + PU L#31 (P#31)
      L2 L#32 (512KB) + L1d L#32 (64KB) + L1i L#32 (64KB) + Core L#32 + PU L#32 (P#32)
      L2 L#33 (512KB) + L1d L#33 (64KB) + L1i L#33 (64KB) + Core L#33 + PU L#33 (P#33)
      L2 L#34 (512KB) + L1d L#34 (64KB) + L1i L#34 (64KB) + Core L#34 + PU L#34 (P#34)
      L2 L#35 (512KB) + L1d L#35 (64KB) + L1i L#35 (64KB) + Core L#35 + PU L#35 (P#35)
      L2 L#36 (512KB) + L1d L#36 (64KB) + L1i L#36 (64KB) + Core L#36 + PU L#36 (P#36)
      L2 L#37 (512KB) + L1d L#37 (64KB) + L1i L#37 (64KB) + Core L#37 + PU L#37 (P#37)
      L2 L#38 (512KB) + L1d L#38 (64KB) + L1i L#38 (64KB) + Core L#38 + PU L#38 (P#38)
      L2 L#39 (512KB) + L1d L#39 (64KB) + L1i L#39 (64KB) + Core L#39 + PU L#39 (P#39)
      L2 L#40 (512KB) + L1d L#40 (64KB) + L1i L#40 (64KB) + Core L#40 + PU L#40 (P#40)
      L2 L#41 (512KB) + L1d L#41 (64KB) + L1i L#41 (64KB) + Core L#41 + PU L#41 (P#41)
      L2 L#42 (512KB) + L1d L#42 (64KB) + L1i L#42 (64KB) + Core L#42 + PU L#42 (P#42)
      L2 L#43 (512KB) + L1d L#43 (64KB) + L1i L#43 (64KB) + Core L#43 + PU L#43 (P#43)
      L2 L#44 (512KB) + L1d L#44 (64KB) + L1i L#44 (64KB) + Core L#44 + PU L#44 (P#44)
      L2 L#45 (512KB) + L1d L#45 (64KB) + L1i L#45 (64KB) + Core L#45 + PU L#45 (P#45)
      L2 L#46 (512KB) + L1d L#46 (64KB) + L1i L#46 (64KB) + Core L#46 + PU L#46 (P#46)
      L2 L#47 (512KB) + L1d L#47 (64KB) + L1i L#47 (64KB) + Core L#47 + PU L#47 (P#47)
  Package L#1
    NUMANode L#2 (P#2 192GB)
      L3 L#2 (24MB)
        L2 L#48 (512KB) + L1d L#48 (64KB) + L1i L#48 (64KB) + Core L#48 + PU L#48 (P#48)
        L2 L#49 (512KB) + L1d L#49 (64KB) + L1i L#49 (64KB) + Core L#49 + PU L#49 (P#49)
        L2 L#50 (512KB) + L1d L#50 (64KB) + L1i L#50 (64KB) + Core L#50 + PU L#50 (P#50)
        L2 L#51 (512KB) + L1d L#51 (64KB) + L1i L#51 (64KB) + Core L#51 + PU L#51 (P#51)
        L2 L#52 (512KB) + L1d L#52 (64KB) + L1i L#52 (64KB) + Core L#52 + PU L#52 (P#52)
        L2 L#53 (512KB) + L1d L#53 (64KB) + L1i L#53 (64KB) + Core L#53 + PU L#53 (P#53)
        L2 L#54 (512KB) + L1d L#54 (64KB) + L1i L#54 (64KB) + Core L#54 + PU L#54 (P#54)
        L2 L#55 (512KB) + L1d L#55 (64KB) + L1i L#55 (64KB) + Core L#55 + PU L#55 (P#55)
        L2 L#56 (512KB) + L1d L#56 (64KB) + L1i L#56 (64KB) + Core L#56 + PU L#56 (P#56)
        L2 L#57 (512KB) + L1d L#57 (64KB) + L1i L#57 (64KB) + Core L#57 + PU L#57 (P#57)
        L2 L#58 (512KB) + L1d L#58 (64KB) + L1i L#58 (64KB) + Core L#58 + PU L#58 (P#58)
        L2 L#59 (512KB) + L1d L#59 (64KB) + L1i L#59 (64KB) + Core L#59 + PU L#59 (P#59)
        L2 L#60 (512KB) + L1d L#60 (64KB) + L1i L#60 (64KB) + Core L#60 + PU L#60 (P#60)
        L2 L#61 (512KB) + L1d L#61 (64KB) + L1i L#61 (64KB) + Core L#61 + PU L#61 (P#61)
        L2 L#62 (512KB) + L1d L#62 (64KB) + L1i L#62 (64KB) + Core L#62 + PU L#62 (P#62)
        L2 L#63 (512KB) + L1d L#63 (64KB) + L1i L#63 (64KB) + Core L#63 + PU L#63 (P#63)
        L2 L#64 (512KB) + L1d L#64 (64KB) + L1i L#64 (64KB) + Core L#64 + PU L#64 (P#64)
        L2 L#65 (512KB) + L1d L#65 (64KB) + L1i L#65 (64KB) + Core L#65 + PU L#65 (P#65)
        L2 L#66 (512KB) + L1d L#66 (64KB) + L1i L#66 (64KB) + Core L#66 + PU L#66 (P#66)
        L2 L#67 (512KB) + L1d L#67 (64KB) + L1i L#67 (64KB) + Core L#67 + PU L#67 (P#67)
        L2 L#68 (512KB) + L1d L#68 (64KB) + L1i L#68 (64KB) + Core L#68 + PU L#68 (P#68)
        L2 L#69 (512KB) + L1d L#69 (64KB) + L1i L#69 (64KB) + Core L#69 + PU L#69 (P#69)
        L2 L#70 (512KB) + L1d L#70 (64KB) + L1i L#70 (64KB) + Core L#70 + PU L#70 (P#70)
        L2 L#71 (512KB) + L1d L#71 (64KB) + L1i L#71 (64KB) + Core L#71 + PU L#71 (P#71)
      HostBridge L#6
        PCIBridge
          PCI 19e5:3714
        PCIBridge
          PCI 19e5:3714
        PCIBridge
          PCI 19e5:3714
        PCIBridge
          PCI 19e5:3714
      HostBridge L#11
        PCI 19e5:a230
        PCI 19e5:a235
        PCI 19e5:a230
    NUMANode L#3 (P#3 191GB) + L3 L#3 (24MB)
      L2 L#72 (512KB) + L1d L#72 (64KB) + L1i L#72 (64KB) + Core L#72 + PU L#72 (P#72)
      L2 L#73 (512KB) + L1d L#73 (64KB) + L1i L#73 (64KB) + Core L#73 + PU L#73 (P#73)
      L2 L#74 (512KB) + L1d L#74 (64KB) + L1i L#74 (64KB) + Core L#74 + PU L#74 (P#74)
      L2 L#75 (512KB) + L1d L#75 (64KB) + L1i L#75 (64KB) + Core L#75 + PU L#75 (P#75)
      L2 L#76 (512KB) + L1d L#76 (64KB) + L1i L#76 (64KB) + Core L#76 + PU L#76 (P#76)
      L2 L#77 (512KB) + L1d L#77 (64KB) + L1i L#77 (64KB) + Core L#77 + PU L#77 (P#77)
      L2 L#78 (512KB) + L1d L#78 (64KB) + L1i L#78 (64KB) + Core L#78 + PU L#78 (P#78)
      L2 L#79 (512KB) + L1d L#79 (64KB) + L1i L#79 (64KB) + Core L#79 + PU L#79 (P#79)
      L2 L#80 (512KB) + L1d L#80 (64KB) + L1i L#80 (64KB) + Core L#80 + PU L#80 (P#80)
      L2 L#81 (512KB) + L1d L#81 (64KB) + L1i L#81 (64KB) + Core L#81 + PU L#81 (P#81)
      L2 L#82 (512KB) + L1d L#82 (64KB) + L1i L#82 (64KB) + Core L#82 + PU L#82 (P#82)
      L2 L#83 (512KB) + L1d L#83 (64KB) + L1i L#83 (64KB) + Core L#83 + PU L#83 (P#83)
      L2 L#84 (512KB) + L1d L#84 (64KB) + L1i L#84 (64KB) + Core L#84 + PU L#84 (P#84)
      L2 L#85 (512KB) + L1d L#85 (64KB) + L1i L#85 (64KB) + Core L#85 + PU L#85 (P#85)
      L2 L#86 (512KB) + L1d L#86 (64KB) + L1i L#86 (64KB) + Core L#86 + PU L#86 (P#86)
      L2 L#87 (512KB) + L1d L#87 (64KB) + L1i L#87 (64KB) + Core L#87 + PU L#87 (P#87)
      L2 L#88 (512KB) + L1d L#88 (64KB) + L1i L#88 (64KB) + Core L#88 + PU L#88 (P#88)
      L2 L#89 (512KB) + L1d L#89 (64KB) + L1i L#89 (64KB) + Core L#89 + PU L#89 (P#89)
      L2 L#90 (512KB) + L1d L#90 (64KB) + L1i L#90 (64KB) + Core L#90 + PU L#90 (P#90)
      L2 L#91 (512KB) + L1d L#91 (64KB) + L1i L#91 (64KB) + Core L#91 + PU L#91 (P#91)
      L2 L#92 (512KB) + L1d L#92 (64KB) + L1i L#92 (64KB) + Core L#92 + PU L#92 (P#92)
      L2 L#93 (512KB) + L1d L#93 (64KB) + L1i L#93 (64KB) + Core L#93 + PU L#93 (P#93)
      L2 L#94 (512KB) + L1d L#94 (64KB) + L1i L#94 (64KB) + Core L#94 + PU L#94 (P#94)
      L2 L#95 (512KB) + L1d L#95 (64KB) + L1i L#95 (64KB) + Core L#95 + PU L#95 (P#95)
  Misc(MemoryModule)
  Misc(MemoryModule)
  Misc(MemoryModule)
  
  
Node Distance:
node 0 <------------ socket distance ------------> node 2
    | (die distance)                                  | (die distance)
node 1                                             node 3

图形化查看（打开大图，和前面的intel 对着看）

img

思考：看如上鲲鹏机器的结构你应该知道网卡、硬盘怎么插放的了吧，然后想就近搞点优化也是可以的

飞腾2500

飞腾的解读留给大家当作业

https://plantegg.github.io/2021/05/15/%E9%A3%9E%E8%85%BEARM%E8%8A%AF%E7%89%87(FT2500)%E7%9A%84%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
#dmidecode -t processor
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
# SMBIOS implementations newer than version 3.0 are not
# fully supported by this version of dmidecode.
Handle 0x0004, DMI type 4, 48 bytes
Processor Information
    Socket Designation: BGA3576
    Type: Central Processor
    Family: <OUT OF SPEC>
    Manufacturer: PHYTIUM
    ID: 00 00 00 00 70 1F 66 22
    Version: FT2500
    Voltage: 0.8 V
    External Clock: 50 MHz
    Max Speed: 2100 MHz
    Current Speed: 2100 MHz
    Status: Populated, Enabled
    Upgrade: Other
    L1 Cache Handle: 0x0005
    L2 Cache Handle: 0x0007
    L3 Cache Handle: 0x0008
    Serial Number: 1234567
    Asset Tag: No Asset Tag
    Part Number: NULL
    Core Count: 64
    Core Enabled: 64
    Thread Count: 64
    Characteristics:
        64-bit capable
        Multi-Core
        Hardware Thread
        Execute Protection
        Enhanced Virtualization
        Power/Performance Control
#lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                128
On-line CPU(s) list:   0-127
Thread(s) per core:    1
Core(s) per socket:    64
Socket(s):             2
NUMA node(s):          16
Model:                 3
BogoMIPS:              100.00
L1d cache:             32K
L1i cache:             32K
L2 cache:              2048K   //2M？太大了，不真实，估计和海光一样骚
L3 cache:              65536K
NUMA node0 CPU(s):     0-7
NUMA node1 CPU(s):     8-15
NUMA node2 CPU(s):     16-23
NUMA node3 CPU(s):     24-31
NUMA node4 CPU(s):     32-39
NUMA node5 CPU(s):     40-47
NUMA node6 CPU(s):     48-55
NUMA node7 CPU(s):     56-63
NUMA node8 CPU(s):     64-71
NUMA node9 CPU(s):     72-79
NUMA node10 CPU(s):    80-87
NUMA node11 CPU(s):    88-95
NUMA node12 CPU(s):    96-103
NUMA node13 CPU(s):    104-111
NUMA node14 CPU(s):    112-119
NUMA node15 CPU(s):    120-127
Flags:                 fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
node distances:
node   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
  0:  10  20  40  30  20  30  50  40  100  100  100  100  100  100  100  100
  1:  20  10  30  40  50  20  40  50  100  100  100  100  100  100  100  100
  2:  40  30  10  20  40  50  20  30  100  100  100  100  100  100  100  100
  3:  30  40  20  10  30  20  40  50  100  100  100  100  100  100  100  100
  4:  20  50  40  30  10  50  30  20  100  100  100  100  100  100  100  100
  5:  30  20  50  20  50  10  50  40  100  100  100  100  100  100  100  100
  6:  50  40  20  40  30  50  10  30  100  100  100  100  100  100  100  100
  7:  40  50  30  50  20  40  30  10  100  100  100  100  100  100  100  100
  8:  100  100  100  100  100  100  100  100  10  20  40  30  20  30  50  40
  9:  100  100  100  100  100  100  100  100  20  10  30  40  50  20  40  50
 10:  100  100  100  100  100  100  100  100  40  30  10  20  40  50  20  30
 11:  100  100  100  100  100  100  100  100  30  40  20  10  30  20  40  50
 12:  100  100  100  100  100  100  100  100  20  50  40  30  10  50  30  20
 13:  100  100  100  100  100  100  100  100  30  20  50  20  50  10  50  40
 14:  100  100  100  100  100  100  100  100  50  40  20  40  30  50  10  30
 15:  100  100  100  100  100  100  100  100  40  50  30  50  20  40  30  10

飞腾的核有点多，我省略了一些

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
#lstopo-no-graphics --logical
Machine (503GB total)
  Package L#0 + L3 L#0 (64MB)
    NUMANode L#0 (P#0 31GB)
      L2 L#0 (2048KB)  //4个物理core共享2M，是不是和AMD(海光)那个设计有点像
        L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
        L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
        L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2)
        L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3)
      L2 L#1 (2048KB)
        L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4 + PU L#4 (P#4)
        L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5 + PU L#5 (P#5)
        L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6 + PU L#6 (P#6)
        L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7 + PU L#7 (P#7)
      HostBridge L#0
        PCIBridge
          PCIBridge
            PCIBridge
              PCI 1000:00ac
                Block(Disk) L#0 "sdh"
                Block(Disk) L#1 "sdf"  // 磁盘挂在Node0上
            PCIBridge
              PCI 8086:1521
                Net L#13 "eth0"
              PCI 8086:1521
                Net L#14 "eth1"       //网卡挂在node0上
        PCIBridge
          PCIBridge
            PCI 1a03:2000
              GPU L#15 "controlD64"
              GPU L#16 "card0"
    NUMANode L#1 (P#1 31GB) //都被我省略了
    NUMANode L#2 (P#2 31GB)
    NUMANode L#3 (P#3 31GB)
    NUMANode L#4 (P#4 31GB)
    NUMANode L#5 (P#5 31GB)
    NUMANode L#6 (P#6 31GB)
    NUMANode L#7 (P#7 31GB) //第1个Socket的最后一个Node
      L2 L#14 (2048KB)
        L1d L#56 (32KB) + L1i L#56 (32KB) + Core L#56 + PU L#56 (P#56)
        L1d L#57 (32KB) + L1i L#57 (32KB) + Core L#57 + PU L#57 (P#57)
        L1d L#58 (32KB) + L1i L#58 (32KB) + Core L#58 + PU L#58 (P#58)
        L1d L#59 (32KB) + L1i L#59 (32KB) + Core L#59 + PU L#59 (P#59)
      L2 L#15 (2048KB)
        L1d L#60 (32KB) + L1i L#60 (32KB) + Core L#60 + PU L#60 (P#60)
        L1d L#61 (32KB) + L1i L#61 (32KB) + Core L#61 + PU L#61 (P#61)
        L1d L#62 (32KB) + L1i L#62 (32KB) + Core L#62 + PU L#62 (P#62)
        L1d L#63 (32KB) + L1i L#63 (32KB) + Core L#63 + PU L#63 (P#63)
  Package L#1 + L3 L#1 (64MB)   //第二个Socket，也是8个Node
    NUMANode L#8 (P#8 31GB)
      L2 L#16 (2048KB)
        L1d L#64 (32KB) + L1i L#64 (32KB) + Core L#64 + PU L#64 (P#64)
        L1d L#65 (32KB) + L1i L#65 (32KB) + Core L#65 + PU L#65 (P#65)
        L1d L#66 (32KB) + L1i L#66 (32KB) + Core L#66 + PU L#66 (P#66)
        L1d L#67 (32KB) + L1i L#67 (32KB) + Core L#67 + PU L#67 (P#67)
      L2 L#17 (2048KB)
        L1d L#68 (32KB) + L1i L#68 (32KB) + Core L#68 + PU L#68 (P#68)
        L1d L#69 (32KB) + L1i L#69 (32KB) + Core L#69 + PU L#69 (P#69)
        L1d L#70 (32KB) + L1i L#70 (32KB) + Core L#70 + PU L#70 (P#70)
        L1d L#71 (32KB) + L1i L#71 (32KB) + Core L#71 + PU L#71 (P#71)
      HostBridge L#7
        PCIBridge
          PCIBridge
            PCIBridge
              PCI 15b3:1015
                Net L#17 "eth2"   //node8 上的网卡，eth2、eth3做了bonding
              PCI 15b3:1015
                Net L#18 "eth3"
            PCIBridge
              PCI 144d:a808
            PCIBridge
              PCI 144d:a808

不知名的一款CPU

当练习看看,随便看看

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
#lscpu
Architecture:          aarch64
Byte Order:            Little Endian
CPU(s):                128
On-line CPU(s) list:   0-127
Thread(s) per core:    1
Core(s) per socket:    128
Socket(s):             1
NUMA node(s):          2
Model:                 0
BogoMIPS:              100.00
L1d cache:             64K
L1i cache:             64K
L2 cache:              1024K
L3 cache:              65536K
NUMA node0 CPU(s):     0-63
NUMA node1 CPU(s):     64-127

#free -g
              total        used        free      shared  buff/cache   available
Mem:           1007         160         511           0         335         840
Swap:             0           0           0

#lstopo-no-graphics
Machine (1008GB) + Socket L#0 (1008GB)
  NUMANode L#0 (P#0 504GB)
    L3 L#0 (64MB)
      L2 L#0 (1024KB) + L1d L#0 (64KB) + L1i L#0 (64KB) + Core L#0 + PU L#0 (P#0)
      L2 L#1 (1024KB) + L1d L#1 (64KB) + L1i L#1 (64KB) + Core L#1 + PU L#1 (P#1)
      L2 L#2 (1024KB) + L1d L#2 (64KB) + L1i L#2 (64KB) + Core L#2 + PU L#2 (P#2)
      L2 L#3 (1024KB) + L1d L#3 (64KB) + L1i L#3 (64KB) + Core L#3 + PU L#3 (P#3)
      L2 L#4 (1024KB) + L1d L#4 (64KB) + L1i L#4 (64KB) + Core L#4 + PU L#4 (P#4)
      L2 L#5 (1024KB) + L1d L#5 (64KB) + L1i L#5 (64KB) + Core L#5 + PU L#5 (P#5)
      L2 L#6 (1024KB) + L1d L#6 (64KB) + L1i L#6 (64KB) + Core L#6 + PU L#6 (P#6)
      L2 L#7 (1024KB) + L1d L#7 (64KB) + L1i L#7 (64KB) + Core L#7 + PU L#7 (P#7)
      L2 L#8 (1024KB) + L1d L#8 (64KB) + L1i L#8 (64KB) + Core L#8 + PU L#8 (P#8)
      L2 L#9 (1024KB) + L1d L#9 (64KB) + L1i L#9 (64KB) + Core L#9 + PU L#9 (P#9)
      L2 L#10 (1024KB) + L1d L#10 (64KB) + L1i L#10 (64KB) + Core L#10 + PU L#10 (P#10)
      L2 L#11 (1024KB) + L1d L#11 (64KB) + L1i L#11 (64KB) + Core L#11 + PU L#11 (P#11)
      L2 L#12 (1024KB) + L1d L#12 (64KB) + L1i L#12 (64KB) + Core L#12 + PU L#12 (P#12)
      L2 L#13 (1024KB) + L1d L#13 (64KB) + L1i L#13 (64KB) + Core L#13 + PU L#13 (P#13)
      L2 L#14 (1024KB) + L1d L#14 (64KB) + L1i L#14 (64KB) + Core L#14 + PU L#14 (P#14)
      L2 L#15 (1024KB) + L1d L#15 (64KB) + L1i L#15 (64KB) + Core L#15 + PU L#15 (P#15)
      L2 L#16 (1024KB) + L1d L#16 (64KB) + L1i L#16 (64KB) + Core L#16 + PU L#16 (P#16)
      L2 L#17 (1024KB) + L1d L#17 (64KB) + L1i L#17 (64KB) + Core L#17 + PU L#17 (P#17)
      L2 L#18 (1024KB) + L1d L#18 (64KB) + L1i L#18 (64KB) + Core L#18 + PU L#18 (P#18)
      L2 L#19 (1024KB) + L1d L#19 (64KB) + L1i L#19 (64KB) + Core L#19 + PU L#19 (P#19)
      L2 L#20 (1024KB) + L1d L#20 (64KB) + L1i L#20 (64KB) + Core L#20 + PU L#20 (P#20)
      L2 L#21 (1024KB) + L1d L#21 (64KB) + L1i L#21 (64KB) + Core L#21 + PU L#21 (P#21)
      L2 L#22 (1024KB) + L1d L#22 (64KB) + L1i L#22 (64KB) + Core L#22 + PU L#22 (P#22)
      L2 L#23 (1024KB) + L1d L#23 (64KB) + L1i L#23 (64KB) + Core L#23 + PU L#23 (P#23)
      L2 L#24 (1024KB) + L1d L#24 (64KB) + L1i L#24 (64KB) + Core L#24 + PU L#24 (P#24)
      L2 L#25 (1024KB) + L1d L#25 (64KB) + L1i L#25 (64KB) + Core L#25 + PU L#25 (P#25)
      L2 L#26 (1024KB) + L1d L#26 (64KB) + L1i L#26 (64KB) + Core L#26 + PU L#26 (P#26)
      L2 L#27 (1024KB) + L1d L#27 (64KB) + L1i L#27 (64KB) + Core L#27 + PU L#27 (P#27)
      L2 L#28 (1024KB) + L1d L#28 (64KB) + L1i L#28 (64KB) + Core L#28 + PU L#28 (P#28)
      L2 L#29 (1024KB) + L1d L#29 (64KB) + L1i L#29 (64KB) + Core L#29 + PU L#29 (P#29)
      L2 L#30 (1024KB) + L1d L#30 (64KB) + L1i L#30 (64KB) + Core L#30 + PU L#30 (P#30)
      L2 L#31 (1024KB) + L1d L#31 (64KB) + L1i L#31 (64KB) + Core L#31 + PU L#31 (P#31)
      L2 L#32 (1024KB) + L1d L#32 (64KB) + L1i L#32 (64KB) + Core L#32 + PU L#32 (P#32)
      L2 L#33 (1024KB) + L1d L#33 (64KB) + L1i L#33 (64KB) + Core L#33 + PU L#33 (P#33)
      L2 L#34 (1024KB) + L1d L#34 (64KB) + L1i L#34 (64KB) + Core L#34 + PU L#34 (P#34)
      L2 L#35 (1024KB) + L1d L#35 (64KB) + L1i L#35 (64KB) + Core L#35 + PU L#35 (P#35)
      L2 L#36 (1024KB) + L1d L#36 (64KB) + L1i L#36 (64KB) + Core L#36 + PU L#36 (P#36)
      L2 L#37 (1024KB) + L1d L#37 (64KB) + L1i L#37 (64KB) + Core L#37 + PU L#37 (P#37)
      L2 L#38 (1024KB) + L1d L#38 (64KB) + L1i L#38 (64KB) + Core L#38 + PU L#38 (P#38)
      L2 L#39 (1024KB) + L1d L#39 (64KB) + L1i L#39 (64KB) + Core L#39 + PU L#39 (P#39)
      L2 L#40 (1024KB) + L1d L#40 (64KB) + L1i L#40 (64KB) + Core L#40 + PU L#40 (P#40)
      L2 L#41 (1024KB) + L1d L#41 (64KB) + L1i L#41 (64KB) + Core L#41 + PU L#41 (P#41)
      L2 L#42 (1024KB) + L1d L#42 (64KB) + L1i L#42 (64KB) + Core L#42 + PU L#42 (P#42)
      L2 L#43 (1024KB) + L1d L#43 (64KB) + L1i L#43 (64KB) + Core L#43 + PU L#43 (P#43)
      L2 L#44 (1024KB) + L1d L#44 (64KB) + L1i L#44 (64KB) + Core L#44 + PU L#44 (P#44)
      L2 L#45 (1024KB) + L1d L#45 (64KB) + L1i L#45 (64KB) + Core L#45 + PU L#45 (P#45)
      L2 L#46 (1024KB) + L1d L#46 (64KB) + L1i L#46 (64KB) + Core L#46 + PU L#46 (P#46)
      L2 L#47 (1024KB) + L1d L#47 (64KB) + L1i L#47 (64KB) + Core L#47 + PU L#47 (P#47)
      L2 L#48 (1024KB) + L1d L#48 (64KB) + L1i L#48 (64KB) + Core L#48 + PU L#48 (P#48)
      L2 L#49 (1024KB) + L1d L#49 (64KB) + L1i L#49 (64KB) + Core L#49 + PU L#49 (P#49)
      L2 L#50 (1024KB) + L1d L#50 (64KB) + L1i L#50 (64KB) + Core L#50 + PU L#50 (P#50)
      L2 L#51 (1024KB) + L1d L#51 (64KB) + L1i L#51 (64KB) + Core L#51 + PU L#51 (P#51)
      L2 L#52 (1024KB) + L1d L#52 (64KB) + L1i L#52 (64KB) + Core L#52 + PU L#52 (P#52)
      L2 L#53 (1024KB) + L1d L#53 (64KB) + L1i L#53 (64KB) + Core L#53 + PU L#53 (P#53)
      L2 L#54 (1024KB) + L1d L#54 (64KB) + L1i L#54 (64KB) + Core L#54 + PU L#54 (P#54)
      L2 L#55 (1024KB) + L1d L#55 (64KB) + L1i L#55 (64KB) + Core L#55 + PU L#55 (P#55)
      L2 L#56 (1024KB) + L1d L#56 (64KB) + L1i L#56 (64KB) + Core L#56 + PU L#56 (P#56)
      L2 L#57 (1024KB) + L1d L#57 (64KB) + L1i L#57 (64KB) + Core L#57 + PU L#57 (P#57)
      L2 L#58 (1024KB) + L1d L#58 (64KB) + L1i L#58 (64KB) + Core L#58 + PU L#58 (P#58)
      L2 L#59 (1024KB) + L1d L#59 (64KB) + L1i L#59 (64KB) + Core L#59 + PU L#59 (P#59)
      L2 L#60 (1024KB) + L1d L#60 (64KB) + L1i L#60 (64KB) + Core L#60 + PU L#60 (P#60)
      L2 L#61 (1024KB) + L1d L#61 (64KB) + L1i L#61 (64KB) + Core L#61 + PU L#61 (P#61)
      L2 L#62 (1024KB) + L1d L#62 (64KB) + L1i L#62 (64KB) + Core L#62 + PU L#62 (P#62)
      L2 L#63 (1024KB) + L1d L#63 (64KB) + L1i L#63 (64KB) + Core L#63 + PU L#63 (P#63)
    HostBridge L#0
      PCIBridge
        PCIBridge
          PCI 1a03:2000
            GPU L#0 "controlD64"
            GPU L#1 "card0"
      PCIBridge
        PCI 1b4b:9235
    HostBridge L#4
      PCI 1ded:8001
      PCI 1ded:8003
  NUMANode L#1 (P#1 504GB)
    L3 L#1 (64MB)
      L2 L#64 (1024KB) + L1d L#64 (64KB) + L1i L#64 (64KB) + Core L#64 + PU L#64 (P#64)
      L2 L#65 (1024KB) + L1d L#65 (64KB) + L1i L#65 (64KB) + Core L#65 + PU L#65 (P#65)
      L2 L#66 (1024KB) + L1d L#66 (64KB) + L1i L#66 (64KB) + Core L#66 + PU L#66 (P#66)
      L2 L#67 (1024KB) + L1d L#67 (64KB) + L1i L#67 (64KB) + Core L#67 + PU L#67 (P#67)
      L2 L#68 (1024KB) + L1d L#68 (64KB) + L1i L#68 (64KB) + Core L#68 + PU L#68 (P#68)
      L2 L#69 (1024KB) + L1d L#69 (64KB) + L1i L#69 (64KB) + Core L#69 + PU L#69 (P#69)
      L2 L#70 (1024KB) + L1d L#70 (64KB) + L1i L#70 (64KB) + Core L#70 + PU L#70 (P#70)
      L2 L#71 (1024KB) + L1d L#71 (64KB) + L1i L#71 (64KB) + Core L#71 + PU L#71 (P#71)
      L2 L#72 (1024KB) + L1d L#72 (64KB) + L1i L#72 (64KB) + Core L#72 + PU L#72 (P#72)
      L2 L#73 (1024KB) + L1d L#73 (64KB) + L1i L#73 (64KB) + Core L#73 + PU L#73 (P#73)
      L2 L#74 (1024KB) + L1d L#74 (64KB) + L1i L#74 (64KB) + Core L#74 + PU L#74 (P#74)
      L2 L#75 (1024KB) + L1d L#75 (64KB) + L1i L#75 (64KB) + Core L#75 + PU L#75 (P#75)
      L2 L#76 (1024KB) + L1d L#76 (64KB) + L1i L#76 (64KB) + Core L#76 + PU L#76 (P#76)
      L2 L#77 (1024KB) + L1d L#77 (64KB) + L1i L#77 (64KB) + Core L#77 + PU L#77 (P#77)
      L2 L#78 (1024KB) + L1d L#78 (64KB) + L1i L#78 (64KB) + Core L#78 + PU L#78 (P#78)
      L2 L#79 (1024KB) + L1d L#79 (64KB) + L1i L#79 (64KB) + Core L#79 + PU L#79 (P#79)
      L2 L#80 (1024KB) + L1d L#80 (64KB) + L1i L#80 (64KB) + Core L#80 + PU L#80 (P#80)
      L2 L#81 (1024KB) + L1d L#81 (64KB) + L1i L#81 (64KB) + Core L#81 + PU L#81 (P#81)
      L2 L#82 (1024KB) + L1d L#82 (64KB) + L1i L#82 (64KB) + Core L#82 + PU L#82 (P#82)
      L2 L#83 (1024KB) + L1d L#83 (64KB) + L1i L#83 (64KB) + Core L#83 + PU L#83 (P#83)
      L2 L#84 (1024KB) + L1d L#84 (64KB) + L1i L#84 (64KB) + Core L#84 + PU L#84 (P#84)
      L2 L#85 (1024KB) + L1d L#85 (64KB) + L1i L#85 (64KB) + Core L#85 + PU L#85 (P#85)
      L2 L#86 (1024KB) + L1d L#86 (64KB) + L1i L#86 (64KB) + Core L#86 + PU L#86 (P#86)
      L2 L#87 (1024KB) + L1d L#87 (64KB) + L1i L#87 (64KB) + Core L#87 + PU L#87 (P#87)
      L2 L#88 (1024KB) + L1d L#88 (64KB) + L1i L#88 (64KB) + Core L#88 + PU L#88 (P#88)
      L2 L#89 (1024KB) + L1d L#89 (64KB) + L1i L#89 (64KB) + Core L#89 + PU L#89 (P#89)
      L2 L#90 (1024KB) + L1d L#90 (64KB) + L1i L#90 (64KB) + Core L#90 + PU L#90 (P#90)
      L2 L#91 (1024KB) + L1d L#91 (64KB) + L1i L#91 (64KB) + Core L#91 + PU L#91 (P#91)
      L2 L#92 (1024KB) + L1d L#92 (64KB) + L1i L#92 (64KB) + Core L#92 + PU L#92 (P#92)
      L2 L#93 (1024KB) + L1d L#93 (64KB) + L1i L#93 (64KB) + Core L#93 + PU L#93 (P#93)
      L2 L#94 (1024KB) + L1d L#94 (64KB) + L1i L#94 (64KB) + Core L#94 + PU L#94 (P#94)
      L2 L#95 (1024KB) + L1d L#95 (64KB) + L1i L#95 (64KB) + Core L#95 + PU L#95 (P#95)
      L2 L#96 (1024KB) + L1d L#96 (64KB) + L1i L#96 (64KB) + Core L#96 + PU L#96 (P#96)
      L2 L#97 (1024KB) + L1d L#97 (64KB) + L1i L#97 (64KB) + Core L#97 + PU L#97 (P#97)
      L2 L#98 (1024KB) + L1d L#98 (64KB) + L1i L#98 (64KB) + Core L#98 + PU L#98 (P#98)
      L2 L#99 (1024KB) + L1d L#99 (64KB) + L1i L#99 (64KB) + Core L#99 + PU L#99 (P#99)
      L2 L#100 (1024KB) + L1d L#100 (64KB) + L1i L#100 (64KB) + Core L#100 + PU L#100 (P#100)
      L2 L#101 (1024KB) + L1d L#101 (64KB) + L1i L#101 (64KB) + Core L#101 + PU L#101 (P#101)
      L2 L#102 (1024KB) + L1d L#102 (64KB) + L1i L#102 (64KB) + Core L#102 + PU L#102 (P#102)
      L2 L#103 (1024KB) + L1d L#103 (64KB) + L1i L#103 (64KB) + Core L#103 + PU L#103 (P#103)
      L2 L#104 (1024KB) + L1d L#104 (64KB) + L1i L#104 (64KB) + Core L#104 + PU L#104 (P#104)
      L2 L#105 (1024KB) + L1d L#105 (64KB) + L1i L#105 (64KB) + Core L#105 + PU L#105 (P#105)
      L2 L#106 (1024KB) + L1d L#106 (64KB) + L1i L#106 (64KB) + Core L#106 + PU L#106 (P#106)
      L2 L#107 (1024KB) + L1d L#107 (64KB) + L1i L#107 (64KB) + Core L#107 + PU L#107 (P#107)
      L2 L#108 (1024KB) + L1d L#108 (64KB) + L1i L#108 (64KB) + Core L#108 + PU L#108 (P#108)
      L2 L#109 (1024KB) + L1d L#109 (64KB) + L1i L#109 (64KB) + Core L#109 + PU L#109 (P#109)
      L2 L#110 (1024KB) + L1d L#110 (64KB) + L1i L#110 (64KB) + Core L#110 + PU L#110 (P#110)
      L2 L#111 (1024KB) + L1d L#111 (64KB) + L1i L#111 (64KB) + Core L#111 + PU L#111 (P#111)
      L2 L#112 (1024KB) + L1d L#112 (64KB) + L1i L#112 (64KB) + Core L#112 + PU L#112 (P#112)
      L2 L#113 (1024KB) + L1d L#113 (64KB) + L1i L#113 (64KB) + Core L#113 + PU L#113 (P#113)
      L2 L#114 (1024KB) + L1d L#114 (64KB) + L1i L#114 (64KB) + Core L#114 + PU L#114 (P#114)
      L2 L#115 (1024KB) + L1d L#115 (64KB) + L1i L#115 (64KB) + Core L#115 + PU L#115 (P#115)
      L2 L#116 (1024KB) + L1d L#116 (64KB) + L1i L#116 (64KB) + Core L#116 + PU L#116 (P#116)
      L2 L#117 (1024KB) + L1d L#117 (64KB) + L1i L#117 (64KB) + Core L#117 + PU L#117 (P#117)
      L2 L#118 (1024KB) + L1d L#118 (64KB) + L1i L#118 (64KB) + Core L#118 + PU L#118 (P#118)
      L2 L#119 (1024KB) + L1d L#119 (64KB) + L1i L#119 (64KB) + Core L#119 + PU L#119 (P#119)
      L2 L#120 (1024KB) + L1d L#120 (64KB) + L1i L#120 (64KB) + Core L#120 + PU L#120 (P#120)
      L2 L#121 (1024KB) + L1d L#121 (64KB) + L1i L#121 (64KB) + Core L#121 + PU L#121 (P#121)
      L2 L#122 (1024KB) + L1d L#122 (64KB) + L1i L#122 (64KB) + Core L#122 + PU L#122 (P#122)
      L2 L#123 (1024KB) + L1d L#123 (64KB) + L1i L#123 (64KB) + Core L#123 + PU L#123 (P#123)
      L2 L#124 (1024KB) + L1d L#124 (64KB) + L1i L#124 (64KB) + Core L#124 + PU L#124 (P#124)
      L2 L#125 (1024KB) + L1d L#125 (64KB) + L1i L#125 (64KB) + Core L#125 + PU L#125 (P#125)
      L2 L#126 (1024KB) + L1d L#126 (64KB) + L1i L#126 (64KB) + Core L#126 + PU L#126 (P#126)
      L2 L#127 (1024KB) + L1d L#127 (64KB) + L1i L#127 (64KB) + Core L#127 + PU L#127 (P#127)
    HostBridge L#5
      PCIBridge
        PCI 8086:0b60
    HostBridge L#7
      PCIBridge
        PCIBridge
          PCIBridge
            PCI 1af4:1001
          PCIBridge
            PCI 1ded:1001
            PCI ffff:ffff

总结

希望通过具体又不同的CPU案例展示，让你对CPU的结构有一些整体认识

请问：Hygon C86 7260 这块CPU每个Die的L2、L3分别是多大？

请思考，最近10年CPU的性能没啥大的进不了(如下图红色部分，每年3%)，但是这么多年工艺还在进步，集成的晶体管数量

img

//这张图每一本计算机体系结构的教材都有引用(没有的话这教材可以扔了)，你知道我博客里哪篇文章放了这图吗？从这个图你还能解析出来哪些东西？

0%