聊聊 Python 3.12 中 perf 的原生支持
好久没写 Python 相关的文章了，但是 Python 3.12 perf 原生支持的这个特性非常的棒，思路又新又好了属于是，所以写篇水文来聊聊这个特性 正文先聊聊 Python 的栈帧在聊今天的正式内容之前我们需要理解 Python 在内存中的布局 对于传统的 native application 而言，大家对于其内存布局应该是比较熟悉的，这里以 x86-64 的一张图来说明其栈帧结构 但是对于 CPython 来说，其 Native Code 执行的只是 VM 一层的代码。其在 VM 内单独抽象了一套类似 native 的栈帧结构。 其核心结构如下 1234567891011121314151617181920212223242526272829303132333435363738struct _frame { PyObject_HEAD PyFrameObject *f_back; /* previous frame, or NULL */ struct _PyInterpreterFrame *f_frame; /*...
关于 CPU Burst 在 K8s 中的一些设计想法
深夜看群友聊的我实在焦虑，起来随便写个水文压压惊 正文写这篇文章的原因是之前给 runc 提的 CPU Burst 支持的 PR [Carry #3205] libct/cg: add CFS bandwidth burst for CPU 终于开始有了新的动静了，这次换了一个国人的 reviewer，感觉要是运气好能在9月开始合并这个 PR。 如果这个 PR 被合并了，那么在 containerd/nerdctl 等其余项目上支持 CPU Burst 的工作就可以开始了。所以这篇文章就是想记录下我对于 CPU Burst 在 Kubernetes 内实现的一些想法，差不多可以当作自己写正式的 KEP(Kubernetes Enhancement Proposal) 草稿 主要分为两个部分来聊一下 CPU Burst 的一些背景 目前 Kubernetes 对于 CPU 资源切分的设计概要 CPU Burst 在 Kubernetes 中的一些设计想法 CPU Burst 的一些背景聊 CPU Burst 之前必须要先聊一下 Linux 里面关于 CGroup...
关于用户态栈回溯（Unwind）的一些杂记和想法
随手记录一些关于用户态栈回溯（Unwind）的一些杂记和想法。 正文昨晚三点过刚吃完药躺在床上休息的时候，突然想到了 @yihong0618 的之前在群里的一个想法 我在想 eBPF 能不能 trace libpq 的协议，好像还没有人做过 我最开始的一个想法是 现在主流做法还是 ptrace 系的东西（gdb 那套），你要用 eBPF 去 trace libpq 肯定没问题，就和 Grey 用 uprobe 去 trace go 一样，手算 cast。但是这里另外一个问题是 libpq 的符号信息不一定够。我倾向你可以这样试一下，你改一下 libpq 源码，关键地方走 USDT（我看你之前用过） 不过后续我师父出来有了一个提醒 如果目标是 trace libpq.so 的调用情况，那应该目前就可以做到。.so 相比 executable 有几个优势： 它一定有动态符号表 它一定有 .eh_frameuprobe 恰好又是 attach to the binary offset 而不是 process address，所以第一个优势完美匹配...
子进程退出后，父进程有可能会收不到信号吗？
最近工作强度有点大，写篇 Linux 相关的水文放松下 这个问题实际上是来源于在群里和人的一个讨论。一个基本常识是，子进程退出后，父进程会收到 SIGCHLD 信号，然后父进程可以通过 wait 或者 waitpid 等系统调用来获取子进程的退出状态。那么，子进程退出后，父进程有可能会收不到信号吗？答案毫无疑问是 yes 的 本文就来聊个其中一个比较好理解的场景 BTW 本文代码都基于最新分支的 Linux 源码 正文先来看一段代码Fuck，哦不，Shut up，我们先来看一段代码 123456789101112131415161718192021222324252627import osimport timeimport signalcount = 20result = 0print(os.getpid())def sigc_handler(*args): global result result+=1 os.waitpid(-1, 0) time.sleep(1)def sig_int(*args): passdef abc(): ...
聊聊公益和助学
很多时候，帮助人不需要那么多理由
为什么奥特曼是我的信仰
優しさを失わないでくれ。弱い者を労り互いに助け合い。
家庭 Homelab 升级计划
人生嘛，Homelab 图个乐子
简单聊聊 IaC：Infrastructure as Code
实际上 IaC 这个概念的出现已经很久了，所以写篇水文来简单聊聊 IaC 的过去，现在，和将来 IaC 的过去实际上 IaC 的历史其实足够悠久。首先来看一下 IaC 的核心的特征 最终的产物是 machine readable 的的产物。可能是一份代码，也可能是一份配制文件 基于 machine readable 的产物，可以进一步依赖已有的 VCS 系统（SVN，Git）等做版本管理 基于 machine readable 的产物，可以进一步依赖已有的 CI/CD 系统（Jenkins，Travis CI）等做持续集成/持续交付 状态的一致性，或者称为幂等性。即理论上来讲，基于同样一份 Code，同一套参数构建出的产物，其最终的行为应该是一致的 实际上通过 IaC 这样的一些核心特征，我们现在能明白 IaC 兴起的原因。IaC 实际上的兴起，大背景是在千禧年之后，互联网世界迭代的速度愈发的快速，这个时候传统的手工式的维护面临着几个问题 交互式变更所引入的人的因素太大，导致了变更的不可控性 人工变更面对愈发快速的 Infra...
从一个重构项目中能学到什么东西
本来这篇文章是要在 2022 最后一个工作日前写完的，但是拖延癌发作，到现在才写完。不过还是发出来，希望里面的内容能帮到大家 背景介绍这个重构项目如果从我第一个超大型重构 PR 算起（22年12月11日），到现在已经历史一个半月了。目前重构进度已经超过了 80%，超过6+位贡献者集体贡献。这绝对是个不小的工程了 那问题来了，我为什么要发起这个重构项目呢？ 在重构项目之前，nerdctl 项目存在一个很大的问题，即 command 的入口处，flag 的处理和逻辑耦合的问题，比如用 nerdctl apparmor 系列的代码来举一个例子 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687package mainimport...
蓝莲花公益小组简报
愿每个人心里，都盛开着永不凋零的蓝莲花 从2021年11月第一次发起刷题公益计划，到现在也一年多时间了。起初是为了让大家有一些特殊的动力去刷题，所以有了这样的基础规则 1题一元人民币，在打卡后向公益基金捐款。 基金池最开始由群主承担，后续有超过25位+群友集体捐款 再后来，这个群就发展成了基于技术的各种闲聊群，推荐番毒害群友群。 到目前也差不多一年多时间了，写个简报回顾一下 一、刷题公益计划截至目前，从2021年11月开始，到2022年6月作为一个阶段的结束。 共计捐款 1625 元人民币 在2022年6月，经过群友同意，再经过一轮扩资后，蓝莲花小组向一个村小项目捐款 6000 元人民币 前不久得到反馈，这笔钱已经用在应该用的地方了。开心 二. 技术分享从2022年6月开始，群友决定在群内以一周两次的频率进行分享，截至目前举行了八次分享 SRE 二三事 当前端在讨论字体时，我们在讨论什么 编译原理入门到出家 OLAP 入门出家 简单聊聊家庭网络 Homelab 101 稳定性建设101 物联网简介 三....
