Linux on 吾爱主机

Linux epoll I/O 多路复用：水平触发、边缘触发与工程实践

Tue, 28 Jul 2026 00:00:00 +0800

高并发服务里最常见的一类卡顿不是“CPU 不够”，而是 大量连接上只有少量真正可读/可写。若对每个连接开线程阻塞 read/write，上下文切换与内存开销会迅速失控；若用轮询扫所有 fd，又会把 CPU 烧掉。Linux 提供的 epoll 就是为“只在就绪时被唤醒”设计的 I/O 事件通知机制。

本文基于 Linux man-pages 的 epoll(7)、epoll_create(2)/epoll_create1(2)、epoll_ctl(2)、epoll_wait(2)，并结合 Python selectors 与 Nginx 连接处理文档，把 interest/ready 两张表、LT/ET 语义、ONESHOT、非阻塞与 EAGAIN、常见坑与排障 讲清楚，方便你在自研事件循环或排查 Nginx/Redis 类服务时按机制定位。

一、问题背景：为什么 select/poll 会“长不大”

传统 select(2) / poll(2) 也能多路复用，但工程上有两个长期痛点：

每次调用都要反复提交关注集合。调用者把“我关心哪些 fd、关心读还是写”整包传给内核；内核再线性扫描。连接数上来后，用户态↔内核态的拷贝与扫描成本随 N 增长。
就绪集合表达方式不友好。select 还有历史性的 fd 数量上限（与 FD_SETSIZE 相关），大规模长连接场景很难优雅扩展。

epoll 的定位不同：它在内核里维护一个 epoll 实例（本质是“容器 + 回调”），应用 只注册一次兴趣，之后用 epoll_wait 拉取当前就绪事件。man 页明确指出：epoll 既可作 水平触发（level-triggered, LT） 也可作 边缘触发（edge-triggered, ET），并且 能较好扩展到大量被监视的文件描述符。

二、核心机制：interest list 与 ready list

从用户视角看，一个 epoll 实例可理解为两张表（epoll(7) 原文概念）：

结构	含义
interest list（epoll set）	进程通过 `epoll_ctl` 注册、希望监视的 fd 集合
ready list	interest list 的子集（更准确：其中“就绪”的引用集合），由内核因 I/O 活动动态填充

配套系统调用职责清晰：

调用	作用
`epoll_create` / `epoll_create1`	创建 epoll 实例，返回 epoll 自身的 fd
`epoll_ctl`	对 interest list 做 `ADD` / `MOD` / `DEL`
`epoll_wait` / `epoll_pwait`	从 ready list 取回最多 `maxevents` 个事件；无事件时可阻塞

2.1 创建实例：优先 `epoll_create1`

epoll_create(size) 在 Linux 2.6.8 之后 忽略 size（但仍要求 size > 0）。更推荐 epoll_create1(flags)：可传 EPOLL_CLOEXEC，避免 fork+exec 时泄漏 epoll fd（与 open(2) 的 O_CLOEXEC 同理）。

2.2 注册兴趣：`epoll_ctl` 与事件掩码

struct epoll_event {
 uint32_t events; /* EPOLLIN | EPOLLOUT | ... */
 epoll_data_t data; /* 用户数据：常存 fd 或指针 */
};

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

常用 op：

EPOLL_CTL_ADD：加入 interest list
EPOLL_CTL_MOD：修改已有项的事件掩码/用户数据
EPOLL_CTL_DEL：从 interest list 删除

常见事件位（epoll_ctl(2)）：

标志	含义
`EPOLLIN`	可读（含对端数据、监听 socket 有新连接等）
`EPOLLOUT`	可写
`EPOLLRDHUP`	流式套接字对端关闭或关闭写半部（2.6.17+，ET 下检测对端关闭很有用）
`EPOLLPRI`	带外/异常条件（语义见 `poll(2)` 的 `POLLPRI`）
`EPOLLERR`	错误；无需在 `events` 里显式设置，`epoll_wait` 总会报告
`EPOLLHUP`	hang up；同样总会报告，不必手动设置
`EPOLLET`	请求边缘触发（默认是水平触发）
`EPOLLONESHOT`	通知一次后自动禁用该 fd，需 `MOD` 重新武装
`EPOLLEXCLUSIVE`	多 epoll 监听同一 fd 时的互斥唤醒（4.5+）

工程建议：监听 socket 与连接 socket 都建议设为非阻塞；读写方向若会频繁切换，可一次 ADD 时就挂 EPOLLIN|EPOLLOUT，避免来回 MOD 切换。

2.3 等待就绪：`epoll_wait`

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

要点：

maxevents 必须 > 0，表示输出数组容量。
timeout 单位毫秒：0 立即返回；-1 一直阻塞；正数限时等待。时间基准为 CLOCK_MONOTONIC。
返回值：就绪事件个数；0 表示超时；-1 出错（常见 EINTR）。
返回的 events[i].events 是 实际发生 的事件掩码；data 原样带回你在 ctl 时写入的用户数据。

epoll_wait 的返回策略还会尽量避免饥饿：若某次只处理“已经知道就绪”的一小撮 fd，而忽略其他已就绪 fd，系统可能长期“看不见”后者。应用层也应做 就绪队列 + 轮转处理，而不是在单次事件上无限 read 到饿死其它连接（man 页 “Starvation” 小节专门提醒）。

三、水平触发 vs 边缘触发：语义决定写法

这是 epoll 最容易写错的地方。epoll(7) 用管道例子讲得很直白：

把管道读端 rfd 加入 epoll；
写端写入 2KB；
调用 epoll_wait → 报告 rfd 可读；
应用只读了 1KB，缓冲区仍剩数据；
再次 epoll_wait：
- LT（默认）：只要缓冲区仍“可读”，就会继续报告就绪；
- ET（EPOLLET）：只在状态 发生变化 时报告；若你没把数据读到“暂时不可读”，可能 不再通知，下一次 wait 会“卡住”，尽管缓冲里还有数据。

3.1 LT：像 poll，好写，易“吵”

语义接近 poll：条件成立就通知。
适合：业务逻辑简单、可接受重复通知、希望少踩坑。
风险：若某 fd 长期可读但你处理很慢，它会反复出现在 ready list，拖慢整个循环。

3.2 ET：变化才通知，必须“抽干 + 非阻塞”

man 页对 ET 的建议可压缩成两条硬规则：

fd 必须非阻塞。否则一次阻塞 read/write 可能饿死处理其它 fd 的任务。
只有在 read/write 返回 EAGAIN（或等价“暂时不可用”）之后，才回去 epoll_wait。也就是说，事件到来后要 循环读写直到资源暂时耗尽，不能“读一次就回 wait”。

ET 适合：超高连接数、希望减少重复唤醒、团队能严格遵守非阻塞与 drain 协议的场景。很多高性能网络库默认 ET + 非阻塞。

3.3 `EPOLLONESHOT`：一次性通知与重武装

设置 EPOLLONESHOT 后，某个 fd 被 epoll_wait 报告一次，就会在 interest list 中被禁用，直到你用 EPOLL_CTL_MOD 重新启用。它常用于：

多线程 worker：保证同一连接同一时刻只被一个线程处理；
防止在处理完成前被其它线程再次取到同一事件。

代价是：处理结束后 必须记得 rearm，否则该连接“静音”。

四、最小可运行实验：管道上的 LT vs ET

下面用 Python 演示 同一场景在 LT/ET 下的不同表现（Linux 上 selectors.EpollSelector；其它平台会落到 kqueue/select 等，行为不完全等价）。目标不是抄生产框架，而是把 man 页语义变成可观测实验。

#!/usr/bin/env python3
"""LT vs ET demo on a pipe (Linux)."""
import os, select, sys

def make_pipe():
 r, w = os.pipe()
 # set non-blocking on read end for ET-safe drain
 os.set_blocking(r, False)
 os.set_blocking(w, False)
 return r, w

def run(edge: bool):
 r, w = make_pipe()
 ep = select.epoll()
 flags = select.EPOLLIN
 if edge:
 flags |= select.EPOLLET
 ep.register(r, flags)

 os.write(w, b"A" * 2048)
 print("mode:", "ET" if edge else "LT")

 # first wait should fire
 ev = ep.poll(timeout=0.2)
 print(" first poll:", ev)

 # only read 1024, leave 1024 in buffer
 data = os.read(r, 1024)
 print(" partial read:", len(data))

 # second wait: LT should still report; ET often does not
 ev2 = ep.poll(timeout=0.2)
 print(" second poll:", ev2)

 # drain remaining
 rest = b""
 while True:
 try:
 chunk = os.read(r, 4096)
 if not chunk:
 break
 rest += chunk
 except BlockingIOError:
 break
 print(" drained rest:", len(rest))
 ep.close(); os.close(r); os.close(w)

if __name__ == "__main__":
 run(edge=False)
 print("---")
 run(edge=True)

预期现象（内核版本与缓冲细节可能略有差异，但方向稳定）：

LT：partial read 后第二次 poll 仍可能看到 EPOLLIN（缓冲仍可读）。
ET：partial read 后第二次 poll 往往 超时为空，直到再次有“新数据写入”或你换回 LT/ONESHOT 策略。

这正是生产代码里 “ET 下偶发假死：连接其实有数据，事件循环却不再被唤醒” 的最小复现。

4.1 监听 socket 的标准骨架（伪代码）

/* listener, conn 均为 nonblocking */
epoll_ctl(epfd, EPOLL_CTL_ADD, listener, &(struct epoll_event){
 .events = EPOLLIN | (use_et ? EPOLLET : 0),
 .data.fd = listener,
});

for (;;) {
 int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
 for (int i = 0; i < n; i++) {
 int fd = events[i].data.fd;
 if (fd == listener) {
 for (;;) { /* ET 下要循环 accept 到 EAGAIN */
 int c = accept(listener, ...);
 if (c < 0) { if (errno == EAGAIN) break; /* handle error */ }
 set_nonblocking(c);
 epoll_ctl(epfd, EPOLL_CTL_ADD, c, &(struct epoll_event){
 .events = EPOLLIN | EPOLLRDHUP | (use_et ? EPOLLET : 0),
 .data.fd = c,
 });
 }
 } else {
 do_use_fd(fd); /* ET: 读写到 EAGAIN；注意 EPOLLERR/HUP */
 }
 }
}

do_use_fd 在 ET 下必须把 可读数据读尽、可写缓冲区写满到 EAGAIN；半包协议要在用户态自己做缓冲拼装。

五、工程映射：语言运行时与 Nginx

5.1 Python `selectors`

标准库 selectors 把 epoll/kqueue/select 统一成高层 API：

DefaultSelector：当前平台最高效实现的别名（Linux 上通常是 EpollSelector）。
EVENT_READ / EVENT_WRITE：跨平台事件抽象。
register / unregister / modify / select：对应 ctl + wait 的职责拆分。

自研 asyncio 之外的小工具时，优先用 selectors，比直接 select.epoll 更易移植；但若你要精细控制 EPOLLET/ONESHOT，仍需回到平台原生接口。

5.2 Nginx 的连接处理方式

Nginx 文档 Connection processing methods 写明：Linux 2.6+ 使用高效的 epoll 方法，并支持 EPOLLRDHUP、EPOLLEXCLUSIVE 等标志。平台支持多种方法时，Nginx 会自动选最高效者，也可用 use 指令显式指定。这解释了为何“同一套配置在 Linux 与 FreeBSD 上行为细节不同”——底层分别是 epoll 与 kqueue。

六、常见坑与排查清单

症状	更可能的机制原因	排查/修复
ET 下连接“有数据但不再触发”	partial read 后未 drain 到 `EAGAIN`	循环读；确认非阻塞；对照 man 管道示例
单连接阻塞拖死整进程	阻塞 fd + 同步 `read`/`write`	全部 `O_NONBLOCK`；慢业务丢线程池/协程
某连接饿死其它连接	单 fd 上无限处理大流量	就绪列表 + 轮转；限制单次读写字节/次数
ONESHOT 后永久静音	处理完未 `EPOLL_CTL_MOD` rearm	统一在处理结束路径 rearm
对端已关仍不清理	只看 `EPOLLIN`，忽略挂断	处理 `EPOLLRDHUP`/`EPOLLHUP`/`EPOLLERR`，读到 0 关闭
`epoll_ctl ADD` 报 `EEXIST`	重复 ADD 同一 fd	用 `MOD` 改掩码，或先 `DEL`
`epoll_wait` 被信号打断	返回 `-1` + `EINTR`	循环重试，或使用 `epoll_pwait` 管理信号掩码
多进程抢同一监听 socket	惊群/重复唤醒	评估 `EPOLLEXCLUSIVE`、`SO_REUSEPORT` 等策略

排障时建议同时抓三份证据：

fd 是否非阻塞（fcntl 标志）；
interest 掩码是否含 EPOLLET/ONESHOT/RDHUP；
一次事件处理是否读/写到 EAGAIN，以及是否处理 hangup。

七、和 select/poll 的选型建议

小工具、fd 很少、要极致可移植：poll/select 或高层封装足够。
Linux 上万级长连接、自研事件循环：epoll（多数生产库默认 ET + 非阻塞）。
跨 Unix 可移植高性能库：用 libuv / netty / Go runtime 等已封装的多路复用层，而不是在业务里手写三套 epoll/kqueue/IOCP。
只做业务、不碰事件循环：理解 LT/ET 与非阻塞，是为了读懂框架文档和 flame graph，而不是 reinvent。

八、总结

epoll 在内核维护 interest list + ready list，用 create/ctl/wait 三件套把“注册”和“等待”拆开，从而在大规模 fd 上更省。
默认 LT：条件成立就通知，写法像 poll；ET：状态变化才通知，必须 非阻塞 + 读/写到 EAGAIN。
EPOLLONESHOT 适合多线程串行化处理，但务必 处理完 rearm；EPOLLRDHUP/HUP/ERR 是连接回收的关键信号。
饥饿、假死、惊群，大多不是“epoll 不灵”，而是 事件语义与读写协议不匹配。先复现 LT/ET 差异，再改生产代码。

掌握这些机制后，再看 Nginx worker、Redis 事件循环、Netty EventLoop 或自研网关，会发现它们都在同一套规则上做工程化封装。

参考资料

Linux man-pages: epoll(7) — interest/ready、LT/ET、ONESHOT、建议用法与陷阱
Linux man-pages: epoll_ctl(2) — 事件标志、ADD/MOD/DEL、EPOLLET/ONESHOT/EXCLUSIVE
Linux man-pages: epoll_wait(2) — timeout、maxevents、就绪返回语义
Linux man-pages: epoll_create(2) / epoll_create1(2) — 创建实例与 EPOLL_CLOEXEC
Python 3 Docs: selectors — High-level I/O multiplexing — EpollSelector / DefaultSelector
Nginx Docs: Connection processing methods — Linux 上 epoll 方法及 RDHUP/EXCLUSIVE 支持说明

Linux cgroup v2 内存控制与 OOM Killer：原理、观测与容器化实践

Thu, 16 Jul 2026 00:00:00 +0800

线上最棘手的一类故障，往往不是“服务报了明确业务错误”，而是进程突然消失：容器退出码 137、Pod 状态里出现 OOMKilled，或者主机 dmesg 里留下一行 Out of memory: Killed process。表象是“内存不够”，根因通常落在 内存如何被记账、如何被限制、以及内核如何选择牺牲者。

本文以 Linux cgroup v2 memory 控制器 与 OOM Killer 为主线，结合 Docker / Kubernetes 的常见映射，把“限多少、什么时候开始回收、什么时候杀进程、怎么排”讲清楚。

一、先建立两层模型：全局 OOM vs cgroup OOM

Linux 里至少要区分两种“内存不够”：

场景	典型触发	影响范围
全局内存压力	整机可用内存 + 可回收页不够，分配失败	OOM killer 在系统范围内按启发式选进程
cgroup 内存上限	某 cgroup 的 `memory.max` 触顶且回收失败	OOM 只发生在该 cgroup 内（不会跨出该 cgroup 去杀别人）

这解释了一个常见错觉：给容器设了 -m 512m，为什么还会拖垮宿主机？
因为：

没设硬限制时，容器与宿主机共享整机内存；
即使设了 limit，仍可能有内核开销、page cache 统计差异、swap 配置、以及 宿主级其他进程 的压力；
Docker 默认会尽量保护 daemon 自身，但不会自动把所有容器都“隔离成绝对安全沙箱”。

因此工程上要同时看：

进程/容器是否撞到了 自己的 limit；
节点是否发生了 系统级 OOM / kubelet 驱逐。

二、cgroup v2 的内存阶梯：min / low / high / max

cgroup v2 memory 控制器把控制面拆成“保护、限速、硬顶”几层。官方接口里最核心的是这些文件（单位均为字节）：

接口	角色	关键语义
`memory.current`	观测	当前 cgroup 及其后代已用内存
`memory.min`	硬保护	在 effective min 内，内存不会被回收；若系统没有其他可回收内存，可能直接触发 OOM
`memory.low`	尽力保护	在 effective low 内，尽量不被回收；只有无保护可回收内存时才可能被碰
`memory.high`	节流线	超高后进程被 throttling，并承受很重的 direct reclaim；不会因此调用 OOM killer
`memory.max`	硬上限	用量到顶且无法压回时，在该 cgroup 内调用 OOM killer
`memory.oom.group`	策略	设为 `1` 时，把 cgroup 当不可分割工作负载：要么一起杀，要么都不杀（`oom_score_adj=-1000` 的任务例外）
`memory.events`	事件计数	`high` / `max` / `oom` / `oom_kill` 等，是最好的“快撞墙”信号
`memory.peak`	峰值	自创建或重置以来的最大用量

可以把它理解成一条阶梯：

usage
 │
 │ memory.min ── 硬保护（尽量不回收；保护过猛可能反噬）
 │ memory.low ── 软保护（有余量时优先回收别人）
 │ memory.high ── 开始重压回收 + 节流（通常还不杀）
 │ memory.max ── 硬顶；回收失败 → cgroup OOM
 ▼

1. 为什么要有 `high`，而不是只设 `max`？

memory.max 是“悬崖”：到顶就可能杀进程。
memory.high 是“缓坡”：先让工作负载变慢、开始回收，给外部控制器（或人）反应时间。内核文档明确：high 越界 never invokes the OOM killer，极端情况下甚至可能被短暂突破。

生产里更健康的模式往往是：

high 设在“可接受抖动”的水位；
max 设在“绝对不可越过”的水位；
用 memory.events 的 high/max 做告警，而不是等进程死了再看。

2. `min`/`low` 保护不是免费的

memory.min 是硬保护：保护区内页面在“任何条件下”都不应被回收；如果系统已经没有未保护可回收内存，就可能 直接 OOM。
memory.low 是 best-effort：优先保护，但仍可能在全局极端压力下被回收。

因此：

保护值叠加超过父 cgroup/整机能力时，会发生 overcommit of protection；
effective 边界还会受祖先 cgroup 限制；
把所有关键服务都设成很高的 min，等于在内存不够时更容易触发“保谁都保不住”的 OOM。

三、OOM Killer：它到底怎么选人

1. 评分：`oom_score` 与 `oom_score_adj`

当内核决定必须杀进程腾内存时，会给候选任务打 badness 分。man-pages 对 /proc/<pid>/oom_score / oom_score_adj 的说明可概括为：

分数大致落在 0（几乎不杀）到 1000（优先杀）；
主要依据是任务相对其 allowed memory 的用量比例（RSS/swap 等估计）；
用满允许内存 ≈ 1000，用一半 ≈ 500；
root 进程额外获得约 3% 的“更宽容”额度；
oom_score_adj 范围 -1000 ~ +1000，在启发式结果上再加减；
oom_score_adj = -1000 表示 OOM 保护（基本不会被选中）。

“allowed memory”取决于 OOM 上下文：

系统全局 OOM → 整机可分配资源；
cgroup/limit 触顶 → 该 limit 本身；
cpuset / mempolicy 节点耗尽 → 对应节点集合。

2. 系统级可调旋钮（`/proc/sys/vm/*`）

参数	默认（文档）	作用
`oom_dump_tasks`	`1`	OOM 杀进程时是否打印系统任务摘要（pid/rss/oom_score_adj 等），便于事后定位
`oom_kill_allocating_task`	`0`	`0`：扫描任务列表按启发式选“更该杀”的；`1`：直接杀触发分配失败的那个任务（省扫描）
`panic_on_oom`	`0`	`0` 杀进程求生；`1` 全局 OOM 可 panic（节点局部耗尽未必）；`2` 连 memory cgroup OOM 也整机 panic
`overcommit_memory`	`0`	`0` 启发式拒绝明显 overcommit；`1` 几乎总是允许，直到真正用完；`2` never overcommit 策略

大多数业务机保持默认即可；集群 failover / 取证 场景才会认真考虑 panic_on_oom + kdump。
不要把 oom_kill_allocating_task=1 当成“优化”随手打开：它可能杀掉“刚好申请最后一页”的 innocuous 任务，而放过真正的内存黑洞。

3. cgroup 内 OOM 的边界

cgroup v2 文档强调两点：

触达 memory.max 且无法回收时，OOM killer 在该 cgroup 内被调用；
一旦在某个 cgroup 触发 OOM，不会去杀该 cgroup 外的任务（与祖先 memory.oom.group 取值无关）。

memory.oom.group=1 适合“多进程必须同生共死”的工作负载（例如某个多 worker 服务希望要么整组重启，要么都不半残）。
但要注意：被 -1000 保护的任务仍是例外。

四、工程映射：Docker 与 Kubernetes

1. Docker：把 limit 落到 cgroup

Docker 官方资源限制文档给出了与内存相关的关键选项：

# 硬上限（最小允许约 6m）
docker run -d --name demo -m 512m your-image

# 内存 + swap 总预算（细节依赖 --memory-swap 语义）
docker run -d -m 512m --memory-swap 1g your-image

# 软预留（争用时更“敏感”，不保证不越界）
docker run -d -m 1g --memory-reservation 512m your-image

# 一般不要关 OOM killer；若关闭，必须同时设置 -m
docker run -d -m 512m --oom-kill-disable your-image

要点：

-m/--memory：容器可用内存上限；
--memory-reservation：软限制，需小于 --memory，争用时生效，不保证永不越界；
--oom-kill-disable：禁用容器内 OOM killer；文档要求 仅在同时设置了 -m 时使用，否则可能把压力转嫁给宿主机，拖垮整机；
Docker daemon 会调整自身 OOM 优先级，降低“杀 daemon 导致全盘崩溃”的概率；容器进程默认没有这种优待。

2. Kubernetes：request / limit / QoS / 驱逐

Kubernetes 文档把资源语义拆成两层：

调度与预留：requests 供 kube-scheduler 选型，kubelet 也会为容器预留至少 request 量；
运行时强制：limits 由 kubelet/容器运行时落到 cgroup；memory limit 由内核通过 OOM kill 强制。

与 CPU 不同：CPU 超限通常是节流；内存超限更可能直接被内核杀掉。文档也提醒：OOM 是 反应式 的——容器可能短暂超过 limit，但在内核感知到压力后才被终止。

QoS 类（Guaranteed / Burstable / BestEffort）主要影响 节点资源压力下的驱逐优先级：

节点资源不足时，通常先考虑驱逐 BestEffort，再 Burstable，最后 Guaranteed；
因资源压力驱逐时，候选对象通常是 超过 request 的 Pod；
Guaranteed（各容器 request=limit 且都 >0 的经典条件）最不容易被驱逐，但 不等于永远不被 OOM：一旦超过自己的 memory limit，仍可能 OOMKilled。

一个可复现的排查入口：

kubectl describe pod <pod> | sed -n '/Last State/,/Events/p'
# 常见：Reason: OOMKilled, Exit Code: 137

五、可复现观测：别等 dmesg 再救火

1. 先确认 cgroup v2 与容器路径

# 多数现代发行版默认 cgroup v2 统一层级
mount | grep cgroup
stat -fc %T /sys/fs/cgroup

# 看某个进程属于哪个 cgroup
pidof java | head -n1 | xargs -I{} cat /proc/{}/cgroup

2. 读 memory 接口（容器内或宿主机 cgroup 路径）

CG=/sys/fs/cgroup # 或容器对应的子路径，如 /sys/fs/cgroup/system.slice/docker-<id>.scope

cat $CG/memory.current
cat $CG/memory.max
cat $CG/memory.high
cat $CG/memory.peak
cat $CG/memory.events
# 关注：high / max / oom / oom_kill 是否持续上涨

解释事件：

`memory.events` 字段	含义（工程视角）
`high`	触碰 high 边界，被节流/强制回收的次数
`max`	用量几乎要越过 max；若 direct reclaim 失败，将进入 OOM 状态
`oom`	已到 limit，分配即将失败
`oom_kill`	实际发生了 OOM kill

3. 看谁更容易被杀

# 分数越高越危险
ps -eo pid,user,comm,rss,oom_score,oom_score_adj --sort=-oom_score | head

# 某个关键守护进程是否被错误保护/错误牺牲
cat /proc/$(pidof dockerd)/oom_score_adj

4. 对照内核日志

dmesg -T | egrep -i 'out of memory|killed process|oom'
journalctl -k -b --no-pager | egrep -i 'out of memory|killed process'

若 oom_dump_tasks=1（默认），日志里通常能看到候选任务的 rss、oom_score_adj 等信息，用来回答“为什么杀的是 A 不是 B”。

六、常见坑与排查清单

坑 1：只设 request，不设 limit

调度时“看起来能放下”，运行时可以吃爆节点；最终变成 节点级压力 + 驱逐/全局 OOM，故障面比单容器 OOM 更大。

坑 2：limit 设太紧，没有 `high` 缓冲与观测

应用启动峰值、JVM 堆外、page cache、临时解压都可能把 current 顶到 max。
结果是频繁 OOMKilled 重启，而不是平滑降速。优先补：

真实峰值观测（memory.peak、容器监控）；
合理 limit；
能用 high 水位告警就不要只用死亡事件告警。

坑 3：把 `oom_score_adj=-1000` 到处贴

保护数据库/核心 agent 合理；若把内存泄漏服务也保护起来，OOM killer 只能去杀更无辜的进程，整机稳定性更差。

坑 4：`--oom-kill-disable` 却没有硬上限

Docker 文档明确警告：关 OOM killer 时必须配合 -m。否则容器可把宿主内存吃穿。

坑 5：混淆“kubelet 驱逐”与“cgroup OOM”

现象	更像
Pod 事件里有 eviction、磁盘/内存 pressure	kubelet 驱逐
Container `Last State: OOMKilled` / exit 137	cgroup/内核 OOM
宿主 `dmesg` 出现 Killed process，且受害进程不一定是容器	全局 OOM 或选中了别的任务

坑 6：用错“内存用量”口径

RSS、cgroup memory.current、容器运行时 working set、JVM heap used 不是同一个数。
排 OOM 时以 cgroup 记账 + kernel 日志 为准，再用进程级工具交叉验证。

七、一套可执行的生产建议

每个有状态/高风险服务都要有 memory limit，并基于压测峰值留 20%–40% 余量（按语言运行时特性调整）。
优先监控 memory.events 与 working set 趋势，把 high/max 当预警，把 oom_kill 当事故。
K8s 上让关键链路尽量 Guaranteed 或至少 request≈实际稳态；limit 不要拍脑袋抄 CPU 倍数。
保护面要窄：-1000 只给真正的系统关键路径；业务进程靠 limit 与弹性，而不是全局免死金牌。
复盘时固定三件套：memory.current/max/events + oom_score(_adj) + dmesg/journal。
不要默认改 panic_on_oom / oom_kill_allocating_task，除非你清楚故障域与取证目标。

八、总结

cgroup v2 用 min/low/high/max 把内存控制从“一刀切 hard cap”扩展成“保护 + 节流 + 硬顶”。
high 负责让系统先变慢并回收；max 才是 OOM 悬崖。
OOM killer 按 badness/oom_score_adj 选人；cgroup OOM 默认 杀在组内，memory.oom.group 可改变是否整组同生共死。
Docker 的 -m、K8s 的 limits.memory 最终都落到内核 cgroup；CPU 超限多半被节流，内存超限更可能被杀。
可观测性的关键不是“死了没有”，而是 memory.events 是否在反复逼近上限。

把内存限制当成“开关”只会得到随机的 137；把它当成“阶梯 + 评分 + 事件流”，才能在容器化环境里稳定控风险。

参考资料

Linux Kernel Docs — Control Group v2（memory.current / min / low / high / max / oom.group / events）: https://docs.kernel.org/admin-guide/cgroup-v2.html
Linux Kernel Docs — Documentation for /proc/sys/vm/（oom_dump_tasks、oom_kill_allocating_task、panic_on_oom、overcommit_memory、swappiness）: https://docs.kernel.org/admin-guide/sysctl/vm.html
man-pages — proc_pid_oom_score(5): https://man7.org/linux/man-pages/man5/proc_pid_oom_score.5.html
man-pages — proc_pid_oom_score_adj(5): https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj.5.html
Docker Docs — Resource constraints（memory options、OOME、--oom-kill-disable）: https://docs.docker.com/engine/containers/resource_constraints/
Kubernetes Docs — Resource Management for Pods and Containers: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
Kubernetes Docs — Pod Quality of Service Classes: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

Linux 文件传输工具完全指南

Sun, 27 Apr 2025 15:02:24 +0800

以下是一篇详细讲解 Linux 文件传输方式的教程，涵盖主流工具及参数解析：

Linux 文件传输工具完全指南

一、引言

在 Linux 系统中，文件传输是日常操作的重要组成部分。不同场景下需选择合适的工具，本教程将详解 SCP、Rsync、SFTP、FTP、Netcat、HTTP 等工具的用法及核心参数。

二、工具详解

1. SCP（Secure Copy）

简介：基于 SSH 协议的安全传输工具，适合简单加密传输。

基本语法

scp [参数] 源文件 目标路径

核心参数解析

-P <端口>：指定 SSH 端口（默认 22）
-r：递归传输目录
-C：启用压缩传输
-l <速率>：限速（单位：Kbit/s，如 -l 1024）
-p：保留文件权限和时间戳

示例

# 本地 → 远程
scp -P 2222 file.txt user@remote:/path/

# 远程 → 本地
scp user@remote:/path/file.txt ./ 

# 目录传输
scp -r backup/ user@remote:/opt/

注意事项

目标路径需有写入权限
大文件传输建议配合 -C 压缩

2. Rsync（增量同步）

简介：支持增量同步，适合大文件或定期备份。

基本语法

rsync [参数] 源路径 目标路径

核心参数解析

-a：归档模式（保留权限、递归同步等）
-v：显示详细传输过程
-z：压缩传输数据
--delete：同步删除目标端多余文件（谨慎使用）
--progress：显示传输进度
-e "ssh -p 2222"：指定 SSH 端口

示例

# 本地同步目录
rsync -avz src/ dest/

# 远程同步（推送到远程）
rsync -avz -e "ssh -p 2222" /data/ user@remote:/backup/

# 限速传输（限制 500KB/s）
rsync --bwlimit=500 -avz largefile user@remote:/data/

注意事项

-a 包含递归操作，无需额外加 -r
--delete 会删除目标端多余文件，建议先测试

3. SFTP（SSH 文件传输）

简介：交互式安全传输工具，支持文件管理。

基本用法

sftp -P 2222 user@remote
sftp> put local_file.txt /remote/path # 上传
sftp> get /remote/file.txt ./ # 下载
sftp> ls # 列目录

常用命令

put：上传文件
get：下载文件
mkdir：创建目录
rm：删除文件

4. FTP（文件传输协议）

简介：传统明文传输协议，建议仅在内部网络使用。

安装与连接

sudo apt install ftp # Debian/Ubuntu
ftp 192.168.1.100 21 # 连接服务器

常用命令

put filename：上传文件
get filename：下载文件
binary：切换二进制模式（传输非文本文件）

5. Netcat（nc）直连传输

简介：通过 TCP/UDP 端口直接传输，无需认证。

接收端

nc -l -p 1234 > received_file

发送端

nc 192.168.1.100 1234 < send_file

参数说明

-l：监听模式
-p <端口>：指定端口
-v：显示详细过程

6. HTTP 下载工具

使用 curl

curl -O http://example.com/file.zip # 下载文件
curl -C - -O http://example.com/file # 断点续传

使用 wget

wget http://example.com/file.zip
wget --limit-rate=1m http://example.com/largefile # 限速下载

7. Tar + SSH 管道传输

适用场景：传输整个目录并保留权限。

# 本地打包 → 远程解压
tar czf - /data | ssh user@remote "tar xzf - -C /backup"

# 远程打包 → 本地解压
ssh user@remote "tar czf - /var/log" | tar xzvf - -C ./logs

三、工具对比表

工具	加密支持	增量传输	交互式	适用场景
SCP	✅ SSH	❌	❌	快速安全的小文件
Rsync	✅ SSH	✅	❌	大文件/定期备份
SFTP	✅ SSH	❌	✅	交互式文件管理
FTP	❌	❌	✅	内网临时传输
Netcat	❌	❌	❌	无认证快速传输
HTTP	可选	✅	❌	公网文件分发

四、安全建议

优先使用 SSH 相关工具（SCP/Rsync/SFTP）
禁用 FTP 明文传输，改用 FTPS 或 SFTP
使用 ssh-keygen 配置密钥认证，避免密码泄露
敏感数据通过 -z 或 -C 参数压缩加密

五、总结

根据传输场景选择工具：

快速加密传输 → SCP
增量备份/同步 → Rsync
交互式操作 → SFTP
无认证环境 → Netcat
公网分发 → HTTP + wget/curl

掌握参数组合可显著提升效率，如 rsync -azP 实现带进度显示的压缩同步。

在Linux 中添加swap教程

Fri, 28 Mar 2025 15:27:09 +0800

在 Linux 中添加 swap 空间通常需要以下步骤：

1. 创建 swap 文件

例如，如果您想创建 1G 的 swap 文件，可以使用下面的命令（也可使用 dd 命令，但 fallocate 更快）：

sudo fallocate -l 1G /swapfile

如果您的系统不支持 fallocate，可以使用 dd 命令：

sudo dd if=/dev/zero of=/swapfile bs=1M count=1024

2. 修改文件权限

为了安全起见，需要设置正确的权限：

sudo chmod 600 /swapfile

3. 将文件格式化为 swap

使用 mkswap 命令将文件设置为 swap 空间：

sudo mkswap /swapfile

4. 启用 swap

使用 swapon 命令来启用刚才创建的 swap 文件：

sudo swapon /swapfile

可通过 free -h 或 swapon -s 查看当前 swap 状态。

5. 设置开机自动挂载

为确保系统重启后 swap 依然有效，需要将其添加到 /etc/fstab 文件中。编辑该文件并添加以下内容：

/swapfile none swap sw 0 0

通过以上步骤，您就可以成功在 Linux 系统中添加并启用 swap 空间。如果需要调整 swap 大小，只需修改相应步骤中的文件大小即可。

如何正确的编写cron表达式

Wed, 12 Mar 2025 11:26:34 +0800

正确编写cron表达式需要遵循特定的结构和规则。以下是分步指南：

1. 确定cron实现环境

标准cron（如Linux crontab）：5个字段，格式为 分钟小时日期月份星期。
扩展实现（如Quartz、Spring）：可能包含6个字段（秒分钟小时日期月份星期）。

2. 字段顺序与取值范围

字段	取值范围	支持的特殊字符
分钟	0-59	`* , - /`
小时	0-23	`* , - /`
日期	1-31	`* , - / ? L W`（部分系统支持）
月份	1-12 或 JAN-DEC	`* , - /`
星期	0-7（0和7均为周日，1=周一）	`* , - / ? L #`（部分系统支持）
秒（扩展）	0-59	`* , - /`

3. 特殊字符用法

*：所有值（如每分钟）。
,：分隔多个值（如 1,3,5 表示1、3、5）。
-：定义范围（如 10-20 表示10到20）。
/：步长（如 */15 表示每15分钟）。
?：不指定值（用于日期或星期字段，避免冲突）。
L：最后一天（如 L 在日期字段表示月末）。
W：最近工作日（如 15W 表示最接近15号的工作日）。
#：第几个星期几（如 1#3 表示第三个周一，仅部分系统支持）。

4. 编写规则

避免冲突：日期和星期字段通常不同时指定具体值，用 ? 忽略其中一个。
转义字符：部分系统需转义特殊字符（如 \%）。
大小写：月份/星期缩写通常不区分大小写（如 MON 或 mon）。

5. 常用示例

每5分钟执行一次：*/5 * * * *
每天中午12点：0 12 * * *
每周一上午9点：0 9 * * 1
每月1号0点：0 0 1 * *
工作日（周一至周五）上午9点：0 9 * * 1-5
每季度最后一天的午夜（Quartz）：0 0 0 L 3,6,9,12 ?

6. 验证工具

使用在线工具检查表达式（如 Crontab Guru 或 Cron Expression Generator）。

7. 常见错误

字段顺序错误：如混淆分钟和小时。
超出取值范围：如小时设为24。
不支持的字符：在标准cron中使用 ? 或 L（需确认系统支持）。

示例解析

0 0/30 9-17 ? * MON-FRI（Quartz）
含义：工作日9:00到17:30之间，每30分钟执行一次（含9:00和17:30）。

通过明确环境、遵循字段规则、合理使用特殊字符，即可编写准确的cron表达式。

Debian中设置 IPv4 优先

Sat, 09 Mar 2024 19:05:00 +0800

在 Debian 12 中设置 IPv4 优先，可以通过调整 gai.conf（GetAddrInfo 配置）来修改地址解析的优先级。以下是具体步骤：

方法 1：修改 `gai.conf`（推荐）

编辑配置文件：
```
sudo nano /etc/gai.conf
```
取消注释或添加以下行（设置 IPv4 优先）：
```
precedence ::ffff:0:0/96 100
```
- 这会让 IPv4 映射的地址（即 IPv4 连接）获得更高优先级。
保存文件并退出编辑器。
无需重启系统，配置会立即生效（对新建立的连接有效）。

方法 2：调整路由 Metric（可选）

如果某些网络接口需要强制优先使用 IPv4，可以通过设置更低的路由 Metric 值实现（值越小优先级越高）。

编辑网络接口配置文件（如使用 ifupdown）：
```
sudo nano /etc/network/interfaces
```

在接口配置中添加 metric 参数：

auto eth0
iface eth0 inet dhcp
 metric 100 # IPv4 的 Metric 值

iface eth0 inet6 dhcp
 metric 200 # IPv6 的 Metric 值

重启网络服务：
```
sudo systemctl restart networking
```

方法 3：禁用 IPv6（极端情况）

如果不需要 IPv6，可以直接禁用它（不推荐，仅作备选）：

编辑内核参数：
```
sudo nano /etc/sysctl.conf
```

添加以下行：

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

应用配置：
```
sudo sysctl -p
```

验证配置

检查地址解析优先级：
```
getent hosts example.com
```
- 输出中 IPv4 地址应位于 IPv6 之前。

测试连接：

curl -4 ifconfig.co # 强制使用 IPv4
curl -6 ifconfig.co # 强制使用 IPv6

通过以上任一方法，即可实现 IPv4 优先。推荐优先使用 方法 1，因为它仅影响地址解析策略，无需禁用 IPv6 或修改路由。

Linux on 吾爱主机

Linux epoll I/O 多路复用：水平触发、边缘触发与工程实践

一、问题背景：为什么 select/poll 会“长不大”

二、核心机制：interest list 与 ready list

2.1 创建实例：优先 epoll_create1

2.2 注册兴趣：epoll_ctl 与事件掩码

2.3 等待就绪：epoll_wait

三、水平触发 vs 边缘触发：语义决定写法

3.1 LT：像 poll，好写，易“吵”

3.2 ET：变化才通知，必须“抽干 + 非阻塞”

3.3 EPOLLONESHOT：一次性通知与重武装

四、最小可运行实验：管道上的 LT vs ET

4.1 监听 socket 的标准骨架（伪代码）

五、工程映射：语言运行时与 Nginx

5.1 Python selectors

5.2 Nginx 的连接处理方式

六、常见坑与排查清单

七、和 select/poll 的选型建议

八、总结

参考资料

Linux cgroup v2 内存控制与 OOM Killer：原理、观测与容器化实践

一、先建立两层模型：全局 OOM vs cgroup OOM

二、cgroup v2 的内存阶梯：min / low / high / max

1. 为什么要有 high，而不是只设 max？

2. min/low 保护不是免费的

三、OOM Killer：它到底怎么选人

1. 评分：oom_score 与 oom_score_adj

2. 系统级可调旋钮（/proc/sys/vm/*）

3. cgroup 内 OOM 的边界

四、工程映射：Docker 与 Kubernetes

1. Docker：把 limit 落到 cgroup

2. Kubernetes：request / limit / QoS / 驱逐

五、可复现观测：别等 dmesg 再救火

1. 先确认 cgroup v2 与容器路径

2. 读 memory 接口（容器内或宿主机 cgroup 路径）

3. 看谁更容易被杀

4. 对照内核日志

六、常见坑与排查清单

坑 1：只设 request，不设 limit

坑 2：limit 设太紧，没有 high 缓冲与观测

坑 3：把 oom_score_adj=-1000 到处贴

坑 4：--oom-kill-disable 却没有硬上限

坑 5：混淆“kubelet 驱逐”与“cgroup OOM”

坑 6：用错“内存用量”口径

七、一套可执行的生产建议

八、总结

参考资料

Linux 文件传输工具完全指南

Linux 文件传输工具完全指南

一、引言

二、工具详解

1. SCP（Secure Copy）

基本语法

核心参数解析

示例

注意事项

2. Rsync（增量同步）

基本语法

核心参数解析

示例

注意事项

3. SFTP（SSH 文件传输）

基本用法

常用命令

4. FTP（文件传输协议）

安装与连接

常用命令

5. Netcat（nc）直连传输

接收端

发送端

参数说明

6. HTTP 下载工具

使用 curl

使用 wget

7. Tar + SSH 管道传输

三、工具对比表

四、安全建议

五、总结

在Linux 中添加swap教程

如何正确的编写cron表达式

2.1 创建实例：优先 `epoll_create1`

2.2 注册兴趣：`epoll_ctl` 与事件掩码

2.3 等待就绪：`epoll_wait`

3.3 `EPOLLONESHOT`：一次性通知与重武装

5.1 Python `selectors`

1. 为什么要有 `high`，而不是只设 `max`？

2. `min`/`low` 保护不是免费的

1. 评分：`oom_score` 与 `oom_score_adj`

2. 系统级可调旋钮（`/proc/sys/vm/*`）

坑 2：limit 设太紧，没有 `high` 缓冲与观测

坑 3：把 `oom_score_adj=-1000` 到处贴

坑 4：`--oom-kill-disable` 却没有硬上限

方法 1：修改 `gai.conf`（推荐）