Linux系统运维中,查看配置命令是诊断问题、优化性能、保障安全的基础能力,掌握这些命令,不是为了背参数,而是为了在关键时刻快速定位瓶颈、验证配置、排查故障,本文从硬件资源、系统信息、网络配置、服务状态、日志与内核参数五个维度,梳理最实用、最易被忽视的查看命令,并给出真实场景下的使用经验。
硬件与资源:先看“底子”是否撑得住
排查任何性能问题,第一步是确认CPU、内存、磁盘、负载是否正常。
lscpu:查看CPU架构、核心数、频率、缓存,比解析/proc/cpuinfo更直观。free -h:内存总量、已用、可用、缓存,重点看available列,它才是真实可分配内存。df -hT:磁盘分区使用率与文件系统类型。-T显示类型,避免对xfs、ext4混用命令。iostat -x:需要sysstat包,查看每块磁盘的%util、await,判断是否存在I/O瓶颈。uptime:1/5/15分钟负载,负载高于CPU核数时,说明有排队,但不一定是CPU问题,要配合top看具体进程。
经验案例(酷番云)
我们曾接手一个客户,业务高峰时网站卡顿,通过free -h发现内存充足,但iostat -x显示%util接近100%,进一步用pidstat -d定位到是日志压缩进程疯狂读写磁盘。最终方案:将日志目录迁移到SSD数据盘,并用logrotate调整压缩时间,问题直接消除,建议Linux服务器务必开启sysstat服务,否则关键时刻拿不到历史性能数据。
系统信息与内核:确认“版本”和“参数”
很多软件安装或内核调优,必须先看清当前系统。

uname -a:内核版本、主机名、架构,判断是否支持特定模块或Docker特性。cat /etc/os-release:发行版名称与版本号,不同发行版的包管理方式差异很大。hostnamectl:集中显示主机名、系统版本、内核、虚拟化类型。sysctl -a:全部内核参数,常用sysctl vm.swappiness、net.core.somaxconn等针对性查看。dmesg -T:内核环形缓冲区消息,含硬件错误、OOM、设备识别,排查开机崩溃或硬件不识别时必看。
独立见解:不要用
cat /proc/version代替uname -a,前者只显示编译信息,后者才是当前运行内核的完整标识,调优前先sysctl -a | grep -E "tcp_.(rmem|wmem)",确认默认缓冲区再改,减少踩坑。
网络配置:不仅看IP,更要看连接与路由
网络问题最难排查,因为涉及链路、IP、端口、防火墙等多层。
ip addr:显示所有网卡IP、MAC、状态。ip -br addr更简洁,一行一块网卡。ip route:查看路由表,确认默认网关是否正常,路由错误会导致“上不了网但IP正常”。ss -tunlp:查看TCP/UDP监听端口及对应进程,替代已废弃的netstat,速度更快,信息更全。ss -s:汇总当前连接数、状态统计,快速判断是否有大量TIME_WAIT。ethtool eth0:查看网卡速率、双工模式、链路是否协商为千兆/万兆。
经验案例(酷番云)
客户反馈云服务器公网IP能ping通,但网站打不开,用

ss -tlnp发现80端口没有监听,但服务已启动,查ip route发现默认路由丢失,原因是多网卡配置时误删了网关。通过ip route add default via 网关IP临时恢复,随后修改/etc/sysconfig/network-scripts/ifcfg-eth0固定配置,所以排查顺序:端口→路由→防火墙,别一上来就重启服务。
服务与进程:分清“活着”和“正常服务”
服务进程存在不代表它健康,需要看其运行状态和资源占用。
systemctl status nginx:查看服务主进程PID、内存、日志路径、最近状态变化。ps -ef:全格式显示进程,找特定进程用pgrep -a nginx更精准。top -o %MEM:按内存排序查看进程,按CPU排序用top -o %CPU,交互按P/M也行。pidstat -p <PID> 1:连续查看某个进程的CPU、内存、线程上下文切换。lsof -i :8080:列出占用8080端口的进程,定位端口冲突或异常监听。
通俗解释:
systemctl status告诉你“它该不该活着”,top告诉你“它活得好不好”,如果CPU占用率持续100%且内存涨,就要考虑是否被入侵或代码死循环。
日志与内核参数:最后的“照妖镜”
系统不会平白无故出问题,日志里都有痕迹。
journalctl -xe:查看最近系统错误日志,自动定位到最后一次异常。journalctl -u nginx --since "today":只看某个服务的今日日志。tail -f /var/log/messages:实时跟踪系统日志,适合排查内核报错或硬件问题。dmesg -T | grep -i error:筛选内核错误,OOM、磁盘I/O错误都在这里面。

经验案例(酷番云)
一次客户数据库突然断开,但服务进程还在,我们立即查看journalctl -u mysqld,发现“Out of memory: Kill process”日志,确认是内存不足触发OOM Killer。最终通过增加Swap空间并调低vm.swappiness到10,同时给MySQL配置innodb_buffer_pool_size限制内存占用,彻底解决,建议所有云服务器保留vm.overcommit_memory=0默认值,不要乱改。
相关问答
问题1:free -h显示可用内存很少,但业务没卡,需要加内存吗?
解答:不一定,Linux会尽量利用空闲内存做缓存(buff/cache),这部分在需要时能自动释放,真正要看的是available列,它估算出在不触发Swap的情况下可分配给新进程的内存,如果available长期低于总内存的20%,且si/so(Swap读写)持续非零,才建议扩容,否则不要看到used高就加内存。
问题2:ss -tn发现大量TIME_WAIT连接,是不是攻击?
解答:TIME_WAIT多不等于攻击,短连接高并发的业务(如频繁请求API)必然会产生TIME_WAIT,这是TCP主动关闭的正常状态,通常几十秒后自动消失,如果TIME_WAIT数量持续数万且伴随ss -s中连接失败数上升,才要考虑排查恶意扫描或用net.ipv4.tcp_tw_reuse优化(仅对客户端生效,服务端不要开tcp_tw_recycle,内核4.12+已移除)。
欢迎在评论区分享你常用的查看命令,或遇到过的奇葩配置问题,我会逐一回复交流,如果你对酷番云服务器性能排查或配置调优感兴趣,也可以直接联系我们的技术团队,提供免费诊断建议。
图片来源于AI模型,如侵权请联系管理员。作者:酷小编,如若转载,请注明出处:https://www.kufanyun.com/ask/763572.html


评论列表(1条)
这篇文章的内容非常有价值,我从中学习到了很多新的知识和观点。作者的写作风格简洁明了,却又不失深度,让人读起来很舒服。特别是内存部分,给了我很多新的思路。感谢分享这么好的内容!