dmesg -n 仅控制控制台输出级别，不抑制内核日志记录；降低高负载I/O的关键是减少控制台刷屏，如设为dmesg -n 3（仅错误）或-n 0（禁用控制台），日志仍完整保留在环形缓冲区。
dmesg -n 本身不配置“日志记录等级以降低 IO”，它只控制内核消息是否输出到控制台（console），不影响日志写入磁盘或环形缓冲区的保存行为。真正影响高负载下 I/O 的，是控制台日志级别过高导致大量消息被实时刷屏打印——比如设置 -n 7 后，内核调试信息高频涌向当前终端（尤其是串口、虚拟控制台），会触发频繁的字符设备写操作，增加 CPU 和 I/O 开销。
要降低高负载下的 I/O，核心思路是：减少控制台输出量，而非抑制内核日志本身。内核环形缓冲区（/dev/kmsg）仍正常记录，只是不往控制台“广播”。
以下是具体、安全、可落地的操作方式：
控制台日志级别设为更严格（推荐值：3 或 2）
sudo dmesg -n 3
- 级别
3（KERN_ERR）仅显示错误类消息（如驱动加载失败、硬件故障） - 级别
2（KERN_CRIT）只显示严重错误（如内存校验失败、PCIe link down） - 这能大幅减少控制台刷屏，避免
printk()触发底层 console 驱动（如ttyS0、hvc0、tty1）的频繁 I/O
验证是否生效：
cat /proc/sys/kernel/printk # 输出应类似：3 4 1 7 → 第一个数字即当前 console_loglevel
禁用控制台输出（彻底消除控制台 I/O）
若系统无需任何控制台日志（如云服务器、容器宿主机、headless 设备），可设为 0：
sudo dmesg -n 0
- 级别
0（KERN_EMERG）理论上只在系统崩溃前最后几条消息才输出，实际等效于关闭控制台日志 - 内核日志仍在环形缓冲区中，
dmesg、journalctl -k、/dev/kmsg均可正常读取 - 不会丢失日志，仅停止向 console 设备写入
⚠️ 注意：设为
0后，你将看不到启动过程中的任何控制台输出（包括 GRUB、内核解压、initramfs 消息），仅适用于已稳定运行且通过 SSH 管理的系统。
配合内核启动参数，避免运行时反复调整
临时 dmesg -n 在重启后失效。如需长期生效，应在内核启动时固化低控制台级别：
编辑 /etc/default/grub：
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash loglevel=3"
然后更新并重启：
sudo update-grub && sudo reboot
-
loglevel=3等效于dmesg -n 3，且在早期启动阶段即生效 -
quiet splash进一步屏蔽非关键启动信息，减少初始 I/O
补充：不推荐但需知晓的误区
- ❌
dmesg -n 8或更高：无效，内核日志级别最大为7 - ❌ 用
sysctl -w kernel.printk="3 3 1 7"单独调第一项：效果同dmesg -n 3，但不如直接用dmesg -n直观 - ❌ 关闭
klogd或rsyslog来减 I/O：现代系统多用journald，且dmesg本身不依赖它们；禁用日志服务反而丢失持久化能力
不复杂但容易忽略
