Linux查看系统配置用什么命令？，Linux查看系统配置命令大全

Linux系统配置查看是运维与开发工作的基石能力，掌握高效、精准的查询方法，远比死记硬背命令更重要。 本文基于多年一线实战经验，从硬件资源、内核参数、系统负载、软件环境四个维度，构建一套完整的排查与调优视角,并给出可直接落地的判断基准和优化建议。

硬件资源查看与瓶颈定位

查看配置不是单纯“跑命令”，而是要能读懂输出背后的性能含义，以下按CPU、内存、磁盘、网络四类核心资源展开。

CPU：从核数到上下文切换

最常用命令是 lscpu，它一次性输出架构、型号、核心数、线程数、NUMA节点等信息，判断性能瓶颈时，不能只看使用率，还要关注上下文切换次数与运行队列长度。

# 查看CPU信息
lscpu
# 动态观察负载与上下文切换
vmstat 1 5

• 若 r（运行队列）持续大于CPU核数,说明计算资源饱和。
• 若 cs（上下文切换）每秒超过10万次,需排查是否频繁创建线程或存在锁竞争。
• 经验案例：酷番云某客户业务高峰期出现卡顿，通过 vmstat 发现上下文切换飙升至20万次/秒，结合 pidstat -w 定位到是Nginx worker进程数配置过高导致，调整后性能提升40%。

内存：容量与分页缺页

free -h 只能看总量和剩余，判断内存是否充足要关注 available 值,它才是真正可被新程序使用的内存。

free -h
# 查看内存详细统计
cat /proc/meminfo

• 当 available 低于总内存10%时,存在OOM风险。
• si 和 so 字段持续非零，说明系统在频繁交换内存页,需要增加物理内存或优化应用内存占用。

磁盘：IOPS与等待时间

df -h 查看容量，iostat -x 1 查看IO性能。重点看 %util 和 await。%util 接近100%不代表磁盘一定饱和，需要结合

await（平均IO响应时间）判断，如果超过20毫秒,基本可以确定磁盘是瓶颈。

# 查看磁盘IO
iostat -x 1 3

经验案例：有一台酷番云云服务器数据库写入延迟高，通过 iostat 发现 await 高达35ms，而 %util 只有60%，确认是磁盘队列深度配置不当，调整为合适的调度算法后,延迟降低到8ms。

网络：带宽与连接状态

ip -s link 查看网卡收发流量，ss -s 查看TCP连接状态。重点关注TIME_WAIT和SYN_RECV数量。

• TIME_WAIT过多，适当开启 tcp_tw_reuse 可缓解，但Linux 4.12+ 不建议再使用 tcp_tw_recycle,会导致NAT环境连接异常。
• SYN_RECV过多，可能遭遇SYN Flood，检查 net.ipv4.tcp_max_syn_backlog 是否足够。

内核参数与系统信息

查看内核与发行版

uname -a          # 内核版本
cat /etc/os-release  # 发行版信息

关键内核参数优化

这些参数决定了系统能承载的最大并发能力,查看当前生效值：

sysctl -a | grep -E "tcp_max_syn_backlog|file-max|ip_local_port_range"

• fs.file-max 决定整个系统可打开文件数，默认值往往不够，建议调大至 6553560。
• net.ipv4.ip_local_port_range 默认为32768-60999，高并发场景建议扩展至1024-65535，否则端口耗尽会直接导致“Cannot assign requested address”错误。

经验案例：酷番云上一台API网关突然拒绝新连接，排查发现本地端口范围已耗尽，修改 ip_local_port_range 并调整 tcp_fin_timeout 为30后,连接数翻倍。

系统负载与性能诊断

负载均值读法

uptime 输出的三个数字分别代表1、5、15分钟平均负载。判断标准不是按核数简单比较，而是结合CPU核数与IO等待，如果负载高于核数，但CPU使用率低,则瓶颈可能在磁盘或锁等待。

uptime
# 查看每个CPU核心负载
mpstat -P ALL 1

使用 top 和 htop 快速定位

top 按 P 按CPU排序，按 M 按内存排序，注意 %CPU 超过100%表示进程使用了多核，用 htop 可以更直观地看到线程树和颜色区分。

软件环境配置核查

• 查看已安装软件包：rpm -qa（CentOS/RHEL）或 dpkg -l（Debian/Ubuntu）。
• 查看服务启动状态：systemctl list-units --type=service --state=running。
• 查看环境变量：env 或 cat /etc/profile。
• 查看JVM/应用参数：ps aux | grep java 之后，用 jinfo 或 jcmd 查看具体配置。

特别注意：检查环境变量时必须区分系统级与用户级，/etc/environment 对所有用户生效，~/.bashrc 只对当前用户生效,避免配置冲突。

高效查看配置的完整命令组合

实际工作中，建议一次性采集所有关键信息，形成系统配置基线，以下命令可直接保存为脚本,输出到文件后对比分析：

echo "===== CPU =====" && lscpu | grep -E "Model name|CPU(s)|Thread|Core|Socket|NUMA"
echo "===== 内存 =====" && free -h
echo "===== 磁盘 =====" && df -hT && iostat -x 1 1
echo "===== 网络 =====" && ip -s link && ss -s
echo "===== 内核 =====" && uname -a && sysctl -a | grep -E "fs.file-max|net.ipv4.ip_local_port_range"
echo "===== 负载 =====" && uptime && mpstat -P ALL 1

经验案例：酷番云为用户提供“配置体检”服务，就是基于以上采集脚本生成基线，再结合云监控数据，帮助用户快速识别三天内的配置变化或性能拐点,这个方法比单看某一刻的命令输出更能发现问题。

常见坑与专业建议

• 不要只看 free -h 的used列，Linux会占用空闲内存做缓存（buff/cache），这并不代表内存不足，应该看 available。
• 不要盲目调整内核参数，有些参数在不同版本间行为差异巨大，tcp_tw_recycle 在4.12+已被移除，修改前先确认 sysctl -w 的持久化方式（写入 /etc/sysctl.conf）。
• 使用云服务器时，IO性能取决于底层虚拟化驱动，用 lsblk -t 查看磁盘类型，如果是virtio且性能低于预期,先检查云平台是否限流。

相关问答模块

Linux查看系统配置时，如何区分究竟是CPU瓶颈还是内存瓶颈？

答：先看 uptime 的负载平均值，再结合 vmstat 的 r 队列和 si/so 字段。r 大于核数且CPU使用率高，是CPU瓶颈；si/so 持续非零且 free 的available很低，是内存瓶颈。 还有一种情况是CPU使用率不高但负载高，这时用 iostat -x 1 看磁盘 await，如果很高，则是磁盘IO瓶颈，简单记忆：先排除磁盘，再看内存,最后确认CPU。

为什么我配置了很大的swap，但系统还是OOM？

答：Swap是内存的补充，不是解决内存不足的根本方案，当内存耗尽时，内核会先尝试回收page cache，然后写swap，如果swap写入速度远低于内存释放需求，就会触发OOM Killer，更关键的是，OOM Killer选择的进程不一定是最占内存的，它受 oom_score 影响，而 oom_score 又和进程的 oom_score_adj 相关。建议通过 systemd 服务或 /proc/<pid>/oom_score_adj 为重要进程设置负值降低被杀概率，同时优化应用本身的内存使用,而不是依赖swap扩容。

您在日常查看Linux配置时，是否遇到过令人困惑的性能指标？欢迎在评论区留言，我会逐一解答。 如果本文对您有启发，也请分享给更多需要的同行,一起提升运维效率。