关键在于理解负载特性、定位瓶颈并针对性优化：用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压力值。
