1. epoll事件模型基础认知

第一次接触epoll的开发者常会对LT(Level-Triggered)和ET(Edge-Triggered)两种工作模式产生困惑。这就像新手司机分不清自动挡汽车的"D"档和"S"档——虽然都是前进档，但换挡逻辑和适用场景截然不同。epoll作为Linux平台高性能I/O事件通知机制的核心，其模式选择直接影响着服务端程序的吞吐量和可靠性。

我在处理一个日均10亿请求的推送系统时，曾因误用ET模式导致消息丢失，最终通过深入分析ep_item_poll的源码实现才找到根因。本文将结合内核5.4.0源码，通过可复现的实验揭示两种模式在底层处理逻辑上的关键差异。

2. 事件触发机制原理拆解

2.1 ep_item_poll函数执行路径

当内核需要检查文件描述符状态时，会调用ep_item_poll函数。这个位于fs/eventpoll.c中的函数是理解epoll行为的关键：

static __poll_t ep_item_poll(struct epitem *epi, poll_table *pt, int depth) { struct file *file = epi->ffd.file; __poll_t res; pt->_key = epi->event.events; res = vfs_poll(file, pt); return res & epi->event.events; }

该函数通过vfs_poll获取文件描述符的实际就绪事件，并与用户注册时关注的事件做按位与运算。这里有个关键细节：返回值res可能包含更多事件类型，但最终只会返回用户订阅的事件集合。

2.2 LT模式的工作特征

LT模式下，只要文件描述符处于就绪状态，epoll_wait就会持续报告该事件。这就像教室里的举手提问——只要学生的手举着，老师每次巡视都会看到。

通过实验可以验证这个特性：

1. 创建非阻塞TCP套接字
2. 注册EPOLLIN事件（LT模式）
3. 客户端发送10字节数据
4. 服务端每次只读取1字节

# 监控epoll事件触发次数 strace -e epoll_wait ./lt_server

实验结果显示epoll_wait会被调用10次，对应每次读取后剩余的缓冲区数据量。这种设计降低了编程复杂度，但可能引发不必要的系统调用。

2.3 ET模式的边缘触发特性

ET模式只在状态变化时触发通知，就像电梯的楼层按钮——只有从"未按下"变为"按下"时才会亮灯。在内核实现中，这通过ep_send_events_proc函数的如下逻辑控制：

if (!(epi->event.events & EPOLLET)) { evlist = epi->event.events; } else { evlist = epi->event.events & event->events; }

我们通过修改内核添加调试打印，可以观察到ET模式下的事件过滤过程。当使用ET模式时：

1. 客户端发送"hello"报文
2. 服务端第一次epoll_wait返回EPOLLIN
3. 若未完全读取数据，后续epoll_wait将阻塞
4. 直到客户端发送新数据才会再次触发

3. 性能对比实验设计

3.1 测试环境搭建

使用两台物理服务器构建测试环境：

• 服务端：Intel Xeon Gold 6248R, 128GB内存
• 客户端：Intel Xeon Silver 4214, 64GB内存
• 网络：10Gbps直连，禁用TCP Nagle算法

测试工具参数：

# 服务端 taskset -c 0-7 ./epoll_server -m [LT|ET] -p 8080 # 客户端 wrk -t12 -c1000 -d60s --latency http://server:8080/

3.2 吞吐量测试数据

ET模式在高并发场景下展现出明显优势，主要得益于：

1. 减少epoll_wait调用次数（约40%下降）
2. 降低用户态-内核态切换开销
3. 更紧凑的CPU缓存利用率

3.3 内存使用对比

通过smem工具监控内存变化：

watch -n 1 'smem -P epoll_server -c "uss pss"'

ET模式的内存占用波动更小，因为其事件处理更集中，避免了LT模式下频繁的事件重新注册操作。

4. 生产环境应用建议

4.1 ET模式使用铁律

经过多次线上事故总结，使用ET模式必须遵守：

1. 必须设置文件描述符为非阻塞模式
2. 必须一次性处理完所有可用数据
3. 必须处理EAGAIN错误情况
4. 必须使用边缘触发感知新连接

示例代码框架：

while (1) { nfds = epoll_wait(epfd, events, MAX_EVENTS, -1); for (i = 0; i < nfds; i++) { if (events[i].events & EPOLLIN) { while ((n = read(fd, buf, BUF_SIZE)) > 0) { // 处理数据 } if (n == -1 && errno != EAGAIN) { // 错误处理 } } } }

4.2 连接处理优化技巧

对于accept连接处理，推荐采用三级缓冲策略：

1. 主线程ET模式监听listen_fd
2. 获取所有就绪连接后放入无锁队列
3. 工作线程批量处理队列中的连接

这种设计在某电商大促期间实现了单机百万级连接处理能力。

5. 内核参数调优指南

5.1 关键参数调整

# 增加epoll实例的文件描述符上限 sysctl -w fs.epoll.max_user_instances=8192 # 优化就绪列表处理 sysctl -w fs.epoll.max_user_watches=1048576 # 调整事件回调队列大小 sysctl -w fs.epoll.event_queue_size=65536

5.2 中断绑定优化

对于高性能场景，建议将网卡中断与epoll线程绑定到相同CPU核心：

# 查看网卡中断号 grep eth0 /proc/interrupts # 绑定中断到CPU0 echo 1 > /proc/irq/[中断号]/smp_affinity

这种配置在某金融交易系统中将网络延迟从80μs降至35μs。