读唤醒阈值
SO_RCVLOWAT 设置套接字「可读」的判定门槛：接收缓冲中的可读字节数达到该值才认为可读。默认值为 1，也就是只要有 1 字节就会唤醒等待方。把它提高后，内核会等到数据累计够多再唤醒，从而减少小报文造成的频繁唤醒；代价是交互式场景的单次响应变慢，适合批量读取且更在意 CPU 效率的服务。
基本信息
| 适用平台 | Linux / Unix 通用套接字选项 |
|---|---|
| 默认值 | 1 字节 |
| 作用方向 | 只影响可读事件判定，不改变传输与确认行为 |
| 配套因素 | 读取缓冲大小、等待方式与触发模式 |
| 建议做法 | 与读取逻辑的批量大小保持一致 |
典型使用场景
- 高包量服务在压测中 CPU 被大量读唤醒消耗，希望减少唤醒次数。
- 批量拉取型协议：一次读取本就期望拿到成块数据。
- 排查数据量小于阈值时可读事件未触发的问题。
- 配合等待机制调整时，评估不同触发模式下的行为差异。
- 对比提高阈值前后的系统调用次数，验证收益是否真实。
C 用例
C 用例
int low = 4096; /* 与一次批量读取的大小保持一致更合理 */
if (setsockopt(fd, SOL_SOCKET, SO_RCVLOWAT, &low, sizeof(low)) < 0) {
perror("setsockopt SO_RCVLOWAT");
}验证效果
验证效果
strace -c -p 12345 -f -- sleep 10 # 对比读取类系统调用的次数变化
ss -tim | head # 查看接收队列与套接字内存使用情况
ss -s # 观察整体套接字与缓冲统计，判断有无积压阈值取舍
| 阈值设置 | 行为变化 | 代价 |
|---|---|---|
| 默认 1 | 有数据即触发可读事件 | 唤醒次数多，小包场景 CPU 偏高 |
| 适度提高 | 累计到阈值再唤醒 | 小数据量交互的响应延迟上升 |
| 高于典型报文 | 可能出现长时间不触发 | 交互协议容易表现为卡住 |
与水平触发方式配合时，小于阈值的数据可能推迟可读事件，需要与应用读取逻辑对齐，否则会出现「数据到了却迟迟没处理」。
交互式协议不要提高该阈值：请求本身就很小，凑不满阈值会让每一次往返都等待额外时间，问题现象会比原来的唤醒开销严重得多。