MAC 上面的 grep 大部分跟 Linux 上的一致, 但也有些差异.

1. 不能使用 -P 来使用正则, 它使用 -e

grep -e 'Abc.\{3,5\}' my.txt

上面的大括号前面使用反斜杠是因为 shell 的原因.

1. 不能使用贪婪模式, 要使用egrep

egrep -e 'Abc.*?Myrule' my.txt

最近开发 Python 应用, 使用 Flask框架, 启动 app 默认开启 5000 端口. 如下:

 * Debugger is active!
 * Debugger PIN: 529-552-853
(9079) wsgi starting up on http://127.0.0.1:5000

一开始的时候, 发现 localhost:5000 无法访问:

只能 127.0.0.1:5000 访问, 虽然无法解释, 但是启动日志写的 127.0.0.1:5000 也能暂时这么使用.

可是, 很快就发现了新问题, 一旦任何一个文件更改, 就会触发app重新load, 然后重启, 这个时候, 就发现连 127.0.0.1:5000 也无法访问了:

于是我想到了之前遇到的问题: 由于某些cookie过大, 导致某些Python框架处理不过来, 直接不能正常返回. 于是 - 我清理缓存 -> Chrome 浏览器 -> More Tools -> Clear Browsing Data -> Cookies and Site Data.

问题得以暂时解决. 可是, 这带来了副作用-> 每次清理完, 很多登录过的账号, 都要重新登录. 比如 chat.openai.com 和 公司里面的很多工具. 烦.

于是, 想去弄明白, 到底哪里出了问题. 我重新访问 127.0.0.1:5000, 然后去仔细观察请求/回应数据, 发现了端倪:

AirTunes/675.4.1 这是啥?

诊断

然后看谁打开了5000端口:

eric@host % sudo lsof -i -n -P | grep 5000
Password:
ControlCe   539         eric    7u  IPv4 0xbe799013704c3c99      0t0    TCP *:5000 (LISTEN)
ControlCe   539         eric    8u  IPv6 0xbe799009db509931      0t0    TCP *:5000 (LISTEN)

虽然不能看到完全的进程名, 但是可以看到进程号: 539. 然后打开 Activity Monitor, 然后查看这个进程, 然后看到进程名字是: Control Center, 还有那个熟悉的图标.

于是, 我尝试杀死这个进程, 它又自动重启了, 同时我启动了 Flask app, 于是这次我看到 5000 端口在 * 上面被 Control Center 占用了, 127.0.0.1 的5000端口, 被 Flask app 占用了:

eric@host % sudo lsof -i -n -P | grep 5000
ControlCe  9926         eric    7u  IPv4 0xbe79901362e29b39      0t0    TCP *:5000 (LISTEN)
ControlCe  9926         eric    8u  IPv6 0xbe799009db4de1b1      0t0    TCP *:5000 (LISTEN)
Python     9948         eric    8u  IPv4 0xbe799013679bab39      0t0    TCP 127.0.0.1:5000 (LISTEN)

解决办法

顺着上面找到的关键字, 我们Google 一下, 第一个就是这个官方问答: https://developer.apple.com/forums/thread/682332
原来是 Control Center 里的 AirPlay Receiver 监听在这个端口.

勾掉这个, 就发现不在监听 5000 端口了:

eric@host % sudo lsof -i -n -P | grep 5000
Python     9948         eric    8u  IPv4 0xbe799013679bab39      0t0    TCP 127.0.0.1:5000 (LISTEN)

当然, 从另外一个角度, 我们只要改改 Flask 的默认端口, 也能达到这个效果:

_app, _socketio = create_app()
_socketio.run(_app, host='0.0.0.0', port=5050)

最近在诊断一个问题的时候, 当时有件奇怪的事情: 所有的流量都是流向一个IP的, 再也没有其它流量.
为了查出为什么会连接timeout, 于是去抓包, 因为知道连接肯定是443 或 80, 于是使用下面的命令:

$ tcpdump port 80 or port 443 -w /tmp/tcpdump.pcap

可是抓到的结果却全是流向这个IP 的, 并且没有返回traffic:

最后发现, 这个机器上有2个接口: tunl0 和 eth0, 抓包时候, tcpdump 默认使用了 tunl0 接口:

$ 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: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.147.64.197/32 scope global tunl0
       valid_lft forever preferred_lft forever
22: eth0@if23: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e2:99:0b:96:46:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.147.166.192/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e099:bff:fe96:46a0/64 scope link
       valid_lft forever preferred_lft forever

$ tcpdump port 80 or 443 -w /tmp/tcpdump.pcap
tcpdump: listening on tunl0, link-type RAW (Raw IP), capture size 262144 bytes
^C2 packets captured
16 packets received by filter
0 packets dropped by kernel

从上面ip a 的结果看, 除了 lo 之外, 它存在一个隧道接口和一个eth 端口, 可是使用 tcpdump 时候, 它默认使用了 tunl0 接口.

如果要抓取所有接口的流量, 可以使用

$ tcpdump -i any port 80 or port 443 -w /tmp/tcpdump.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

最近有个功能的某些数据特别适合图数据库, 一开始使用的是 MySQL 数据库, 但是在业务开发的过程中, 愈发觉得图数据库才是它的最终归宿, 于是先期先用 MySQL 做了一版, 顺利上线, 然后第二步准备迁移到图数据库.

之前小组内部有人用过 Neo4j, 用的还挺不错, 准备使用, 但是后来听说这个对于大企业要收费, 并且公司有个部门已经做好了一个基于 Janusgraph 的数据库, 统一管理, 保证稳定运行, 所以最后放弃 Neo4j, 转而准备上公司已经搭好并且有部门维护的这个图数据库. 但是一番打听下来, 要使用这个数据库, 有个复杂的流程, 关键的关键是: 如果你改任何一个图的schema(顶点, 边及其任何属性, 都要提ticket, 然后走review流程. 对于我们这种一开始还不确定到底有多少类型的顶点, 多少边, 时不时随时可以加边的实验性的项目, 这种流程简直就是灾难.

所以, 最可行的方案是: 我们先自己在开发, 测试, 生产环境搭一套基于 Janusgraph 的图数据库, 等我们的 schema 都稳定之后, 再考虑迁移到有稳定保障的, 有部门支持的图数据库.

首先, 在开发环境基于 Janusgraph 的 docker image 做了一个server, 并且搭了一个 graphexp 的 UI server. 脚本如下:

mkdir -p /home/supra/work/data/janusgraph/{data,index}
sudo chown -R 999:999 /home/supra/work/data/janusgraph
docker run --name janusgraph -p 8182:8182 --restart always -d --platform linux/amd64 -v /home/supra/work/data/janusgraph/data:/var/lib/janusgraph/data -v /home/supra/work/data/janusgraph/index:/var/lib/janusgraph/index janusgraph/janusgraph
docker run --name graphexp  -p 8183:80 --restart always -d --platform linux/amd64 ghcr.io/armandleopold/graphexp:0.8.3

大家注意到, 这里我们给 Janusgraph 的server 挂载了一个 volume, 还把这个挂载的文件夹的owner 改成了用户和组都是999的用户, 这里确实是偷懒. 这一切都是因为 Janusgraph 的 docker 文件里面新起了一个 janusgraph 的用户, 它的uid和gid都是 999. 在 Janusgraph server 里面, 都是以这个用户运行的. 都是因为这个用户和组, 导致我最后必须写下这篇记录.

本地环境这么起起来, 往里面灌入数据, 在用 graphexp 的UI 去访问, 一切顺利. 于是准备轰轰烈烈的去搞一个prod Janusgraph server 集群, 目标是1个小时搞定.

首先, prod 环境不能访问外网的 docker image, 于是拉下最新的外网image, 然后重新打一个 tag, 搞成内网的 image, 然后在生产环境的 k8s 环境做一个新的app, 然后一番乱搞, docker image 开始启动了.

但是呢, 总是启动不起来, 为啥, 因为:

chown: changing ownership of '/var/lib/janusgraph': Operation not permitted
chown: changing ownership of '/etc/opt/janusgraph': Operation not permitted
chmod: changing permissions of '/var/lib/janusgraph': Operation not permitted
chmod: changing permissions of '/etc/opt/janusgraph': Operation not permitted

仔细分析下来, 主要是:

1. 生产环境都是 rootless 的, 所以运行 container 的 uid 都不是 root, 是一个根据 namespace 预先定义好的用户.
2. 生产环境默认所有image 里面的文件都是read only, 所以对于日志, 数据文件必须通过 volume 挂载使用.
3. 给 Janusgraph server 用的 data 和 index 文件夹都是挂载的 volume, 而这些 volume 的owner 都是上面预先定义好的 rootless 用户;
4. 而一旦进入 Janusgraph, 它却以 Dockerfile 中自己新加的 janusgraph(999:999) 这个用户运行.

所以, 就造成了这种困境: 因为 image 里面的文件都是 read only, 和必须保存这些数据, 数据必须以 volume 的方式挂载, 然而挂载的文件夹的主人是预先定义好的非 root 账号, Janusgraph 的启动脚步里面却要改变这些数据文件夹的属主, 但是它使用的自己创建的账号janusgraph(999:999), 而这个账号有没有权限更改owner. 于是死了.

想解决这个问题, 有2种可能的方案:

1. 生产环境其实可以改变这个预先定义好的非root 账号, 我们的生产环境可以针对某个namespace 创建一个新的用户, 而这个用户必须绑定生产环境的 LDAP. 所以, 要先定义一个生产环境的 LDAP 账号, 规定它的uid/gid, 然后绑定某个 k8s 下面的namespace, 然后在运行这个 container 的 spec 里面的 SecurityContext 里面设置 fsgroup, runAsUser 等.
2. hack Janusgraph 的 Docker 文件, 去掉这个自己创建的用户, 像其它 image 一样, 用默认用户不香吗?

首先想去试试第一种方案. 去找了公司内部k8s的文档, 说是有这么一个创建posixuser 的流程, 可能是因为很少有人用, 搜了半个多小时, 没有找一个完整的文档, 能教会我怎么去做的. 更多的文档是说查看有了这么一个账号, 然后就可以以它运行container 了. 再加上更改任何生产环境的东西, 要走审批流程, 1个小时后, 我彻底放弃了.

第二种方案, 就是要大改看懂 Janusgraph 的Dockerfile 和 docker-entrypoint.sh 两个文件. 花了半个小时, 大改看到它就是想以一个service acount (janusgraph) 来运行这个服务, 然后启动前, 把相关的文件都给这个用户设置好, 然后就启动. 于是改了上述2个文件里面的关于这个用户的行, 然后加了一些日志, 然后本地做一个新的image, 然后push 到内部 image 仓库, 然后启动等好消息.

然而, 有没起来, 还以为是关于这个用户的错误, 又加调试代码, 做新image, 发布的流程再走一遍, 仍然起不来. 后来竟然发现是 刚起来, 就被 OOM kill 了. 哎, 命运多舛. 为啥 OOM 呢, 本地好好的. 因为 OOM 很快被 kill, 所以只有很短的时间, 能进入 container 去查看日志, 但是进入发现, 日志文件都是空.

于是进入本地启动好的 container 里面, 去查看它的启动参数(container 里面啥工具都没有, cat /proc/1/cmdline 才看到), 发现它启动的时候, 竟然就要求 heap 是4G, 那么再加点其它的 metaspace , 还有些辅助进程等, 岂不是5G打不住? 然而一开始我觉的它需要的内存很小, 只给了它1G的空间, 所以 OOM 也就很好理解了. 于是我就想问了, 为啥官方文档不告诉你最少需要5G呢???, 另外启动日志不能把这么重要的参数打印出来吗?

虽然心有不忿, 还是立马改了内存限制, 立马给他8个G, 然后再启动, 发现起来了, 可是有错:

Disk usage is not within je.maxDisk or je.freeDisk limits and write operations are prohibited

对了, 就是这个还在 open 的issue, 必将以后还要open: https://github.com/internetarchive/heritrix3/issues/340. 因为他们改变不了. 原来这个内存数据库, 需要至少5个G的磁盘空间, 否则, 它就生气. 而我给所有的 volume 的大小总共才2个G, 所以出这个错, 也就不难理解了.

于是, 我有给 volume 加到12个G. 于是重新部署, 大家都开心了, 你好, 我也好. 终于成功了. 至此, 本来打算要1个小时完成的工作, 终于通过12个小时(早上9点到晚上9点, 当然中间包括2顿饭的时间和1个多小时的开会)的努力, 画上句号了.

jcmd 的 GC.class_stats 子命令 输出 JVM 里metaspace (元数据)区的 class 相关的信息. 这里必须记住, 所有的 java.lang.Class 及其子类都在heap, 元数据区只是这些class的元数据, 元数据区存的也不是这些类编译后的字节码(bytescode).

GC.class_stats 能输出每个class 在 metaspace 空间占用的大小.

这个子命令在JDK 14 deprecated, 15去掉.

默认只输出下面这些列, 还有更多列可以显示, 需要指定列名称:

InstBytes,KlassBytes,CpAll,annotations,MethodCount,Bytecodes,MethodAll,ROAll,RWAll,Total

$ bin/jcmd <pid> GC.class_stats

由于类太多, 并且长度会折叠, 这里截图开头和结尾的截图:

最好结合 jcmd <pid> VM.metaspace 一起看

- 阅读剩余部分 -