AIO与worker进程无固定比例，关键在于协同减少I/O等待：AIO实现非阻塞读写，worker负责请求调度；worker过少致AIO积压，过多则加剧资源竞争。
文件异步 I/O（AIO）与 worker 进程数量之间没有固定“比例”，关键在于让两者协同减少 I/O 等待、避免资源争用，而不是机械配比。核心逻辑是：AIO 负责把单次磁盘读写操作“非阻塞化”，而 worker 进程负责调度请求和响应；若 worker 太少，AIO 请求积压；若太多，反而加剧文件描述符、内存页、磁盘队列等底层竞争。
先明确各自角色，避免误配
• AIO 是内核或数据库/服务器内部的 I/O 执行机制（如 Linux io_uring、PostgreSQL 的 io_workers、Nginx 的 aio 指令），它不依赖 worker 进程数，而是由独立线程池或内核队列驱动
• worker 进程是请求处理主体（如 Nginx worker、PostgreSQL backend），它发起 I/O 请求，但不亲自执行物理读写——真正执行交给 AIO 子系统
• 因此，“协同比例”本质是：worker 并发请求能力 ≤ AIO 吞吐能力 ≤ 底层存储实际服务能力
按服务类型分别调优
静态文件服务（Nginx 场景）
• 优先启用 sendfile on + tcp_nopush on，此时大部分小文件走零拷贝路径，AIO 几乎不参与，worker 数设为 CPU 物理核心数即可
• 对大文件（>1MB）且需 range 请求或校验场景，可开启 aio threads（Linux ≥5.1 + XFS），并配置 worker_processes = CPU核心数，aio_threads 8（线程数 ≈ 2×物理核，上限不超过 16）
• 不建议盲目提高 worker 数来“匹配”AIO 线程数——过多 worker 会挤占 page cache、加剧 inode 查找锁争用
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
数据库服务（PostgreSQL / 神通 Oscar）
• PostgreSQL 18 默认 io_method = worker，io_workers = 3 已覆盖多数 OLTP 场景；SSD 环境下一般无需调高，机械盘可试设为 5～7
• worker（即 backend 进程）数量由连接数决定，与 io_workers 无直接比例关系；重点是确保 max_connections × 平均并发 I/O 请求率 ≤ io_workers × 单线程吞吐（可通过 iostat -x 1 观察 aqu-sz 是否持续 > io_workers）
• 神通数据库需确认 ENABLE_NATIVE_AIO = true，否则即使配置了 16 个 AIO 线程也退化为同步行为
看指标，不看公式
真正判断是否协同时，盯住三个实时指标：
• CPU %wa（I/O wait） 长期 >15%：说明 I/O 延迟高，可能 AIO 未生效、存储慢、或 worker 在等磁盘，而非 CPU 不足
• iostat -x 的 aqu-sz（平均请求队列深度） 持续 > io_workers 或 > 4：表明 AIO 处理不过来，需检查磁盘调度器（SSD 用 none）、文件系统挂载参数（noatime,nodiratime）、或增加 io_workers（仅限机械盘）
• worker 进程的上下文切换（cs/s）和空闲率（%idle）：若 cs/s 异常高（>50K/s）且 %idle 低，说明 worker 数过多，应减少
硬件与部署约束必须前置考虑
• NUMA 架构服务器：将 AIO 线程与 worker 进程绑定在同一 NUMA 节点（如 PostgreSQL 的 pg_bind，Nginx 的 worker_cpu_affinity），避免跨节点内存访问拖慢 I/O 路径
• 容器环境：worker_processes 和 io_workers 都应以 cgroup 可用 CPU 核数为准，而非宿主机总核数；例如容器限制 4 核，则 Nginx 设 worker_processes 4，PostgreSQL 设 io_workers 3 即可
• SSD vs HDD：SSD 随机读写延迟低，AIO 效益主要在高并发大块读；HDD 则更依赖 AIO 缓解寻道等待，此时可适度提高 io_workers（+2～4），但 worker 进程仍保持物理核数
