关键在于理解负载特性、定位瓶颈并针对性优化：用 pidstat/vmstat 识别 I / O 等待、上下文切换或单核锁死；通过 taskset 或 worker_cpu_affinity 实现 CPU 亲和性绑定；依据 MemAvailable 而非 free 评估内存，合理配置 swappiness 与 HugePages；每次调整后需用 perf、smem 等工具持续观测验证。
Linux 系统中提升 CPU 多核利用率和优化内存管理，关键不在于堆砌参数，而在于理解负载特性、定位瓶颈、针对性调整。盲目开启多线程或关闭 swap，反而可能引发调度抖动或 OOM Killer 误杀进程。
识别真实瓶颈：别让 top 骗了你
top 或 htop 显示 CPU 使用率低，不代表没瓶颈——可能是 I / O 等待（%wa 高）、上下文切换频繁（cs 值异常）、或单线程锁死在某个核上。用 pidstat -w -u 1 观察每进程的上下文切换和 CPU 分布；用 vmstat 1 看 r（运行队列）是否持续大于 CPU 核心数，这是多核未被有效分摊的明确信号。
- 若 r 值长期 > 总核数 × 0.7，说明任务排队严重，需检查应用是否支持并行或存在串行锁
- 若某几个核持续 100%，其余核空闲，大概率是进程未绑定 numa 节点或缺少 CPU 亲和性配置
- 注意区分“用户态 CPU 高”和“系统态 CPU 高”：后者常指向内核路径问题（如大量小文件读写、低效驱动）
释放多核潜力：从进程调度到底层绑定
默认调度器（CFS）适合通用场景，但对延迟敏感或计算密集型服务，需主动干预。重点不是“压满所有核”，而是让工作负载均匀、稳定、可预测地分布。
- 用 taskset -c 0-3 ./app 限制进程只在前 4 核运行，避免跨 NUMA 节点访问内存导致延迟飙升
- 对多线程服务（如 Nginx、Redis），启用worker_cpu_affinity auto（Nginx）或server_cpulist（Redis 7+），自动按物理核绑定线程
- 实时任务可用 chrt -f -p 50 PID 设为 SCHED_FIFO 策略，但仅限可信短时任务，避免霸占 CPU
内存不只看 free：回收机制与应用协同
Linux 的“可用内存”≠ free 字段，而是MemAvailable（/proc/meminfo 中），它已扣除不可回收缓存。过度依赖 swappiness 调优是误区——现代内核更应关注 page cache 行为与应用内存模式匹配度。
- swappiness=10 适用于多数服务器；设为 0 不等于禁用 swap，只是推迟到 OOM 前才换出匿名页
- 对数据库类应用，用 echo 1 > /proc/sys/vm/zone_reclaim_mode 强制本地 NUMA 节点优先回收，减少跨节点内存访问
- 大页（HugePages）对 KVM、Oracle、PostgreSQL 等效果显著：先预留sysctl vm.nr_hugepages=1024，再由应用显式申请，避免 TLB miss 开销
验证与持续观测：把优化变成闭环
改完配置不验证，等于没做。每次调整后至少观测 24 小时业务高峰时段，重点对比延迟 P99、吞吐波动、以及 /proc/pressure 下的 cpu/memory 压力值。
