接手过不少“莫名其妙卡得要死”的CentOS 7服务器第一反应基本都是加内存、换硬盘、重启大法三连。但做多了就会发现很多问题不是硬件不够而是系统装好之后一直用默认配置在硬扛。CentOS 7虽然已经进入生命周期尾声可大量存量服务器、内网环境和虚拟机里它依然是主力系统系统优化与性能调优这套基本功短期之内不会过时。这篇文章是我这些年折腾CentOS 7的实战笔记主要覆盖从虚拟机安装、yum源替换、内核参数、文件系统、服务裁剪到MySQL这类典型应用调优的完整链路。不管是刚接触Linux的新手还是想把手头服务器性能再压榨一轮的运维老手里面提到的思路和命令都能直接用尤其适合那些“不敢乱动生产环境但虚拟机可以先练练手”的人。1. 安装层面的优化先把底子打对很多人觉得性能调优是从系统装完以后才开始的其实安装阶段就已经决定了后面一大半的上限。选错镜像、分区不合理、多余组件装了一堆后面再怎么调都别扭。1.1 VirtualBox 上创建 CentOS 7 虚拟机镜像、分区与初始配置最近折腾测试环境我习惯用 VirtualBox 配合 CentOS 7 x86_64 minimal 2009.iso 这个镜像。2009 是 7.x 的最终版本号minimal 镜像只有几百 MB装出来就是一个干干净净的最小系统没有图形界面、没有一堆用不上的办公软件。很多人装系统喜欢装 DVD 版图省事结果光系统自带的乱七八糟服务就吃掉几百 MB 内存这对性能调优来说是从起点就输了。创建虚拟机的时候几个关键参数我是这么给的内存建议至少 2GB。低于这个值后面跑 MySQL 或者编译软件时会频繁触发 swap负载看着不高但卡成 PPT。CPU按宿主机核心数分配但不要超过物理核心数的一半否则虚拟机调度开销反而拖累性能。磁盘动态分配即可但建议预留 40GB 以上别只给 20GB因为 yum 缓存、日志、数据库文件这些东西涨起来比你想象的快得多。网络默认 NAT 可以如果要模拟生产环境建议加一张桥接网卡。分区这一步是重点。生产环境我强烈建议用 LVM后面扩容就不用重新分区了这是我在生产上踩过几次坑之后养成的习惯。最小化安装时手动分区推荐这样规划/boot 分区512MB 到 1GB放内核和引导文件不需要大。swap 分区内存 2GB 以下的机器给内存的 1.5 到 2 倍内存 8GB 以上反而不用给太多给 4GB 到 8GB 足够swap 太大容易让人忽略内存不足的问题。剩余空间全部给根分区/用 LVM 创建。还有个小细节安装时选择最小化安装但建议在“软件选择”里勾选“开发工具”。很多人漏了这一步后面想装编译工具或者虚拟机增强功能的时候发现 gcc、make 全都没有还得重新挂载光盘折腾 yum非常麻烦。1.2 aarch64 架构 CentOS 7 更换 yum 源的完整方法很多人在 ARM 机器上装 CentOS 7 之后第一件事就被 yum 源卡住了因为默认官方源要么慢要么已经停止维护。网上搜“arrch64 centos 7 更换yum源”实际应该是 aarch64 架构也就是 ARM 64 位跟 x86_64 的源路径不一样不能直接用 x86 的源。以清华源为例aarch64 的 CentOS 7 要使用的是 altarch 路径操作步骤先备份原配置再写入新源cp -a /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak然后编辑 /etc/yum.repos.d/CentOS-Base.repo把 baseurl、gpgkey 都指到 aarch64 对应路径下。关键就是安装架构字段不能写错x86_64 对应的是 /centos/7/x86_64/而 aarch64 对应的是 /centos-altarch/7/aarch64/。写完之后清理缓存验证yum clean all yum makecacheaarch64 架构下epel 源也要用 altarch 路径不能安装 x86 版的 epel-release。这一点容易忽略但不管你是 x86 还是 ARM装完系统第一件事先把源换掉后面装软件的速度会提升非常明显。实测下来从官方源换成国内镜像源单纯 yum 更新这一步的时间能从半小时缩短到几分钟这也是最立竿见影的基础优化。2. 内核参数与系统层调优系统装好之后先别急着装业务软件内核参数才是性能调优的主战场。CentOS 7 默认内核参数照顾的是通用场景对高并发、高磁盘 IO 或高连接数的业务来说默认值往往太保守。但内核参数也不能乱改改错一个轻则服务异常重则直接宕机。2.1 真正值得改的几个内核参数及原因我调内核参数最常用的配置文件是 /etc/sysctl.conf改完执行sysctl -p生效。下面这几个参数是经过生产环境验证的也是调优收益最高的。首先是文件句柄也就是 fs.file-max。默认值经常只有几十万但高并发业务下文件句柄很快会被耗尽表现就是日志里报 “Too many open files”。我一般会调高但要结合机器内存来定fs.file-max 6553560然后是网络连接相关的几个参数。net.core.somaxconn默认 128对于接入层或者代理服务器来说太低排队连接会被丢弃。我通常调到 65535。net.ipv4.tcp_max_syn_backlog是 SYN 队列长度并发高的时候建议也调大。net.ipv4.ip_local_port_range控制本地可用端口范围默认 32768 到 60999短连接多的服务很容易把端口用光。可以扩大到 1024 到 65000。有个参数我要特别提醒net.ipv4.tcp_tw_recycle一定不要开启。CentOS 7 基于 3.10 内核这个参数在 NAT 环境下会造成丢包很多用户反馈“网页一会儿能开一会儿打不开”排查下来就是有人开了这个参数。在 CentOS 7 里sysctl -p不会报错但实际坑了不少人。TIME_WAIT 连接多的话优先用net.ipv4.tcp_tw_reuse1这个安全得多。内存层面的参数最常见的是 vm.swappiness默认 30代表系统在内存还有 70% 空闲时就可能开始换页。对数据库服务器来说我一般调到 10 左右让内存尽量留给业务但对内存本来就吃紧的机器强行调到 0 反而容易触发 OOM。提示调内核参数之前先sysctl -a /tmp/sysctl_before.txt保存一份原始配置方便出问题时回滚。2.2 文件系统挂载与磁盘 IO 调度器调整磁盘性能是整个系统优化里最容易被人忽略的一环。很多人看性能只盯着 CPU 和内存其实很多“假 CPU 高”都是磁盘 IO 卡出来的。先看当前磁盘用的 IO 调度器cat /sys/block/sda/queue/schedulerCentOS 7 默认一般是 deadline 或者 cfq。根据磁盘类型有不同的选择机械硬盘建议用 deadline它能减少单个请求的延迟对数据库这种随机读写多的场景更友好。SSD 或 NVMe建议用 none也就是 noop因为 SSD 内部已经做了大量调度优化内核再排队反而是多余的。虚拟机里的虚拟磁盘大多数场景建议 none 或 noop特别是 VirtualBox 和 VMware 这类虚拟化磁盘物理磁盘调度已经由宿主机处理了。修改调度器可以用 udev 规则或者直接改 /sys 下的文件但后者重启就失效。我一般用 grub2 的内核引导参数来持久化编辑 /etc/default/grub在 GRUB_CMDLINE_LINUX 中加上elevatornone或elevatordeadline然后重新生成引导配置grub2-mkconfig -o /boot/grub2/grub.cfg这里要注意如果是 UEFI 启动的机器输出路径要改成 /boot/efi/EFI/centos/grub.cfg。改错路径会导致重启后配置没生效这是个很隐蔽的坑。挂载参数方面我强烈建议给数据分区加上 noatime。Linux 默认每次读取文件都会更新 atime 时间戳这会产生额外的写 IO。在 /etc/fstab 的挂载选项里加上 noatime可以显著减少无意义的磁盘写入。2.3 服务裁剪用最少的进程干最多的活装完系统默认会启动一大堆服务但大部分场景下它们只是单纯占内存和 CPU。查看开机自启的服务systemctl list-unit-files --typeservice --stateenabledCentOS 7 里我通常会关掉这些postfix邮件服务内网机器基本用不上、abrtd 和 abrt-journal-core崩溃报告工具占了内存还经常误报、kdump 服务如果不是做内核调试可以关掉但它會预留一块内存关之前要慎重。还有 avahi-daemon这是个局域网设备发现服务数据中心环境里没必要开。裁剪服务前先确认依赖关系再动手。比如直接systemctl disable postfix没问题但如果你跑的是邮件相关应用关了就会出大事。我的原则是先systemctl status看谁在跑、跑的是什么确认无害再关而不是一上来就批量 disable。另外CentOS 7 自带 tuned 调优服务它可以根据系统类型套用不同的优化方案。运行tuned-adm recommend查看推荐方案比如数据库服务器推荐 throughput-performance 或 latency-performance。如果不想手动调内核参数可以用 tuned 做基础调优但要注意它可能会覆盖你在 /etc/sysctl.conf 里手动设置的参数。我之前就吃过这个亏手动配的参数重启后全部失效最后发现是 tuned 在启动时把我的配置覆盖了。如果你要手动调内核参数记得systemctl disable tuned。3. 应用层瓶颈与 MySQL 性能调优系统层优化做完之后你会看到服务器负载明显下降但这只是把基础路面修好了。真正让业务卡顿的往往是应用层的配置问题。MySQL 是最典型的场景网上关于 mysql 性能调优的内容很多但大多数都停留在“抄参数”层面实际效果因人而异。3.1 MySQL 性能调优的正确顺序很多人一上来就改 innodb_buffer_pool_size以为内存给得越大越好。其实 MySQL 性能调优的正确顺序应该是先看慢查询日志和当前状态再定位瓶颈最后才改参数。开启慢查询日志先找出那些拖后腿的 SQLSET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;慢查询日志一旦打开通常能发现两类问题一种是没走索引的全表扫描这种是 SQL 本身的问题改参数没用得优化查询或加索引另一种是数据库本身资源不足高并发下连接数被打满表现就是大量查询排队等锁。确认是资源问题之后再调整关键参数。以 CentOS 7 上常见的 MySQL 5.7 为例这几个参数是收益最明显的innodb_buffer_pool_sizeInnoDB 的缓冲池建议设置为物理内存的 50% 到 70%。比如 8GB 内存的机器设成 5GB 左右。注意不是随便填设置前要看监控里 InnoDB 的缓存命中率如果命中率不到 95%说明缓冲池太小。innodb_flush_log_at_trx_commit默认是 1意味着每次事务提交都要刷盘安全性最高但磁盘 IO 压力大。对可容忍秒级数据丢失的场景可以改成 2性能提升非常显著。max_connections默认 151很多业务跑着跑着就报 “Too many connections”。但也不要盲目调到 10000每个连接都要占用线程栈内存数值过大反而适得其反。我一般根据当前连接数的峰值再加 50% 余量。table_open_cache如果表数量多打开表的缓存默认值容易不够日志里会出现 “Table open cache is full”。建议根据SHOW GLOBAL STATUS LIKE Open_tables的实际值来调整。还有一个参数很多人忽略innodb_log_file_size。redo log 太小会导致刷盘频繁写性能上不去。5.7 里面这个参数在配置文件里设置后需要重启并清理 redo log 文件改动有风险要先做好备份再操作。3.2 监控工具组合先定位再动手调优之前没有数据支撑等于闭着眼睛开车。我常用的组合方案是 top、iostat、vmstat 三个命令交叉验证。top 看整体负载和进程状态如果 CPU 使用率很高但 IO 等待 wa 也很高那瓶颈很可能在磁盘加 CPU 是没用的。iostat -x 1 看磁盘利用率重点看 %util、await、svctm。%util 接近 100% 但 await 不高说明磁盘吞吐到了上限await 很高但 %util 只有二三十说明可能有随机 IO 或锁等待。vmstat 1 看内存换页和上下文切换si/so 长期不为 0说明内存不足在频繁换页。cs 列数值特别大说明系统在疯狂切换上下文可能是线程数设置不合理。CentOS 7 上 sysstat 包里的 sar 也是长期监控的好帮手。我一般会配置 cron 定期采集 sar 数据出问题的时候回看历史曲线比事后拍脑袋猜原因靠谱得多。4. 常见问题与真实排错记录系统优化和性能调优这两个词听起来很玄但落地过程中遇到的问题往往很具体。我挑三个出现频率最高的问题把排查过程写清楚也算给后来人排雷。4.1 系统优化配置不生效到底怎么排查很多人遇到“未开启系统优化”的问题其实不是没做优化而是做了配置之后没有生效。我见过最多的几种情况第一种是改了 /etc/sysctl.conf 但没执行sysctl -p或者执行了但报错没注意。这种情况最简单地解决改完立即sysctl -p然后sysctl -a | grep 参数名验证。第二种是被 tuned 或其他工具覆盖了。tuned 服务如果开着启动时会读取自己的方案重新应用内核参数手动改的配置在重启后会被重置。解决方法是systemctl disable tuned或者把参数同时写进 tuned 的配置里。第三种是文件句柄限制的问题这个特别隐蔽。你改了 fs.file-max但你的应用和进程的实际句柄限制还受 /etc/security/limits.conf 以及 systemd 服务单元里的 LimitNOFILE 控制。CentOS 7 上 systemd 管理的服务直接在 /etc/security/limits.conf 改可能不生效要在服务单元文件里加[Service] LimitNOFILE65535我之前帮人排查过一个 Nginx 报 “too many open files” 的案例sysctl 配了、limits.conf 也改了就是不生效最后发现是 nginx.service 单元文件里默认 LimitNOFILE 只有 1024加上了才真正解决。4.2 虚拟机里 VMware Tools 和 VirtualBox 增强工具安装的坑在虚拟机里跑 CentOS 7很多人遇到分辨率调不了、剪贴板不共享、网卡性能差的问题这时候就要装虚拟机增强工具。CentOS 7 里 VMware Tools 安装不算复杂但有几个坑非常典型。先在 VMware 的虚拟机菜单里点击“安装 VMware Tools”然后挂载光驱mkdir /mnt/cdrom mount /dev/cdrom /mnt/cdrom tar zxf /mnt/cdrom/VMwareTools-*.tar.gz -C /tmp cd /tmp/vmware-tools-distrib ./vmware-install.pl -d最大的坑是安装前没有装 kernel-devel 和 gcc导致 VMware Tools 编译内核模块失败。CentOS 7 内核升级过之后kernel-devel 版本必须和当前内核版本严格一致先确认uname -r yum install -y kernel-devel-$(uname -r) gccVirtualBox 上类似安装增强工具要用 VBoxGuestAdditions运行 VBoxLinuxAdditions.run 之前同样需要先装好 kernel-devel 和 build 工具链。另外增强工具装完之后建议重启一次不然新模块不会完全加载。很多人装完没重启发现剪贴板还是不能用以为安装失败其实重启就好。4.3 我见过的三种最坑的调优方式这些年看别人调优也接手过不少被优化搞坏的服务器发现三个反复出现的坑。第一个是照抄互联网上的所谓“万能优化脚本”。从网上复制了一段 sysctl 参数里面把vm.swappiness0、net.ipv4.tcp_tw_recycle1全给配上了结果在高并发 NAT 环境下出现随机丢包排查一整天。内核参数必须根据业务场景来配没有放之四海而皆准的“万能参数”。第二个是只调数据库不调系统。MySQL 把 max_connections 调到 2000但系统 open files 限制还是 1024连接一多照样报错。做 MySQL 调优之前先确认系统层文件句柄、swap、TCP 连接参数都配合到位否则永远差一口气。第三个是改完不做验证。生产环境改了 innodb_buffer_pool_size确认没问题但没做压测过两天业务高峰期直接内存不足OOM 把数据库进程杀了。任何参数改动之后至少要观察一个业务周期并且准备好回滚方案。这是责任心问题不是技术问题。我个人做系统优化的习惯是每个改动之前先把原值记下来严格按“监控、分析、小步调整、验证、回滚预案”这套流程走。系统优化拼的不是谁参数堆得猛而是谁能在一个又一个不起眼的小配置里提前把未来可能出现的坑填掉。最后再分享一个小技巧调优告一段落后把所有改动项整理成一份清单保存到 /root/optimization_notes.txt。下次系统重启或者迁移环境这份清单就是你最有价值的参考比任何网上抄的优化教程都可靠。