IOSchedulingClass 是 systemd 服务单元中用于设置进程 I/O 优先级类别的配置项，分 Idle、Best-effort（默认）、Realtime 三类，通过 io_set_ioprio() 应用，不改变底层磁盘调度器；Nginx 场景通常无需配置，因其 I/O 轻量且现代 SSD/NVMe 下该选项常被忽略。
Systemd 管理 Nginx 服务时，IOSchedulingClass 并不是直接用于 Nginx 进程本身的磁盘 I/O 调度配置项，而是 systemd 服务单元中可为服务进程设置的 I/O 调度策略（需内核支持 CFQ/Deadline/NOOP 等传统调度器，且仅对使用 CFQ 的场景生效），现代 Linux（特别是使用 BFQ 或 kyber 的系统）中该选项行为受限或已弃用。
IOSchedulingClass 是什么？
这是 systemd 服务单元（.service 文件）中的一个可选配置项，属于 [Service] 段，用于向内核 hint 当前服务的 I/O 优先级类别：
- Idle：仅在系统空闲时执行 I/O，适合后台批处理类任务（如日志归档）
-
Best-effort：默认值，配合
IOSchedulingPriority（0–7）使用，影响 CFQ/BFQ 队列权重 - Realtime：最高优先级，强制抢占其他 I/O，一般禁止用于用户服务（需特权，易导致系统卡顿）
注意：它不改变磁盘物理调度算法（那是内核 block layer 决定的），也不等价于 ionice 命令——但 systemd 在启动服务时会调用 io_set_ioprio() 应用该策略。
Nginx 场景下是否需要配置 IOSchedulingClass？
通常不需要，原因如下：
- Nginx 主要负载是网络请求处理和小文件静态服务，I/O 量相对随机、轻量，极少成为系统 I/O 瓶颈
- 现代 SSD 和 NVMe 设备不依赖传统 I/O 调度器，
IOSchedulingClass在none或kyber调度器下被忽略 - 若 Nginx 真面临磁盘 I/O 压力（如大量 access_log 同步写入、频繁 SSL 会话缓存落盘），更有效的是优化日志缓冲（
access_log ... buffer=64k flush=5s）、关闭 access_log、使用 tmpfs 存 SSL session cache，而非调整 I/O 类别
如果仍想尝试配置（仅限调试或特殊场景）
编辑 Nginx 的 systemd 单元文件（推荐覆盖方式，避免修改 vendor 文件）：
sudo systemctl edit nginx.service
填入：
[Service] IOSchedulingClass=best-effort IOSchedulingPriority=4
然后重载并重启：
sudo systemctl daemon-reload sudo systemctl restart nginx
验证是否生效（需 procfs 支持）：
cat /proc/$(pgrep nginx)/io | grep -i ioprio
或查看进程实际 I/O 调度类：
ionice -p $(pgrep nginx)
替代方案：更实用的 I/O 相关优化
- 用
IOWeight=（cgroup v2）替代IOSchedulingClass：更现代、更可靠，适用于容器化或 cgroup v2 环境 - 限制 Nginx 日志写入频率与位置：将 access_log 放到独立 SSD 分区，或使用 syslog 转发
- 启用
sendfile on和tcp_nopush on减少内核态拷贝，间接降低 I/O 压力 - 检查磁盘队列深度与设备状态：
iostat -x 1观察await、%util、avgqu-sz
