
大家好,我是刘叨叨,一个致力于让碎片化技术系统性的运维人。
你是否经历过这样的“惊魂时刻”:
在Linux这座精密运行的“城市”里,进程如同川流不息的车辆与行人,端口则是房屋的门牌与通道。今天,我们就来掌握运维的“火眼金睛”——进程与端口查看的三大核心命令:netstat、ps、lsof,让你对系统运行状态了如指掌。
在深入细节前,我们先理清这三个工具在运维“侦查”工作中的定位:
侦查目标 → 对应工具 → 核心任务
netstat → 网络状态统计(谁在监听?谁在连接?)ps → 进程状态快照(进程是谁?耗多少资源?)lsof → 列出打开文件(进程正操作什么?)🔗 组合使用流程示例:
发现异常端口 → netstat -tunlp | grep [端口号]
确认是哪个进程 → lsof -i:[端口号]
查看该进程详情 → ps -ef | grep [进程PID]netstat 是查看网络连接、路由表、接口统计的“瑞士军刀”。在较新的系统中,它可能默认未安装,需要先请它“出山”:
yum -y install net-tools # CentOS/RHEL
apt install net-tools # Ubuntu/Debian📋 经典使用场景与参数组合:
场景 | 命令示例 | 参数解读与输出关键 | ||
|---|---|---|---|---|
查看所有监听端口 | netstat -tunlp | -tTCP,-uUDP,-n数字形式,-l仅监听,-p显示程序名 | ||
查看指定服务/端口 | netstat -tunlp | grep 22netstat -tunlp | grep nginx | 快速过滤,22端口常为SSH,或直接搜索服务名 |
查看所有连接 | netstat -an | -a所有,-n数字形式。输出中0.0.0.0:*表示监听所有地址 | ||
统计协议数据 | netstat -s | -s按协议统计,可用于初步判断网络问题类型 | ||
持续监控 | netstat -c | -c持续输出,类似top命令的刷新效果 |
📊 典型输出示例:
# 执行命令:netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1234/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 5678/cupsd
tcp6 0 0 :::80 :::* LISTEN 9102/nginx: master
udp 0 0 0.0.0.0:68 0.0.0.0:* 3333/dhclient✅ 解读:可以看到SSH监听22端口,Nginx监听80端口,且0.0.0.0表示监听所有IPv4地址,::表示监听所有IPv6地址。
如果说netstat管“门”(端口),那ps就管“人”(进程)。它能给你一份系统进程的瞬时档案。
🆚 最常用的两组参数风格对比:
参数组合 | 特点与适用场景 | 常用命令示例 | ||
|---|---|---|---|---|
ps -ef | BSD风格,显示格式固定,信息全面。关键字段:UID, PID, PPID, C, STIME, TTY, TIME, CMD | ps -ef | grep nginxps -ef | grep 12345 |
ps aux | UNIX风格,更易阅读,尤其擅长查看资源占用。关键字段:USER, %CPU, %MEM, VSZ, RSS, STAT, START, COMMAND | ps aux | grep sshdps aux --sort=-%cpu | head -10 |
📊 典型输出示例:
# 执行命令:ps -ef | grep nginx
UID PID PPID C STIME TTY TIME CMD
root 9102 1 0 08:00 ? 00:00:00 nginx: master process /usr/sbin/nginx
nginx 9103 9102 0 08:00 ? 00:00:01 nginx: worker process
# 执行命令:ps aux | grep sshd
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1234 0.0 0.1 12345 6789 ? Ss 08:00 0:00 /usr/sbin/sshd -D
root 5678 0.0 0.0 8901 1234 ? S 09:30 0:00 sshd: alice [priv]✅ 解读:ps -ef清晰地显示了nginx进程的父子关系(PPID),而ps aux则列出了SSH进程的资源占用情况。
🚀 进阶技巧:使用 --sort 对结果排序,快速定位资源消耗大户:
ps aux --sort=-%mem | head -5 # 查看内存占用前5的进程
ps aux --sort=-%cpu | head -5 # 查看CPU占用前5的进程lsof(List Open Files)非常强大,在Linux中“一切皆文件”,网络连接、设备、目录都被视为文件。因此,它特别擅长回答 “这个端口/文件被哪个进程打开了?” 这类问题。
📋 常用场景速查表:
场景 | 命令示例 | 说明 | |
|---|---|---|---|
查看进程打开的文件 | lsof -p 1234 | 查看PID为1234的进程打开了哪些文件 | |
查看谁在占用端口 | lsof -i :80lsof -i tcp:5500 | -i查看网络连接,直接定位端口占用者 | |
查看用户打开的文件 | lsof -u root | 查看root用户的所有文件操作 | |
查看程序打开的文件 | lsof -c nginx | 查看所有nginx进程打开的文件 | |
恢复误删的文件 | lsof | grep deleted | 查找已被删除但进程仍持有的文件,有机会恢复 |
📊 典型输出示例:
# 执行命令:lsof -i :80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 9102 root 6u IPv4 54321 0t0 TCP *:http (LISTEN)
nginx 9103 nginx 6u IPv4 54321 0t0 TCP *:http (LISTEN)
# 执行命令:lsof -p 9102
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 9102 root cwd DIR 253,0 4096 2 /
nginx 9102 root rtd DIR 253,0 4096 2 /
nginx 9102 root txt REG 253,0 1234567 123456 /usr/sbin/nginx
nginx 9102 root mem REG 253,0 123456 654321 /lib64/libc.so.6
nginx 9102 root 6u IPv4 54321 0t0 TCP *:http (LISTEN)✅ 解读:第一个命令直接定位到占用80端口的进程是nginx;第二个命令详细列出了nginx主进程打开的所有文件、库和网络连接。
当遇到“端口5500被占用”这样的典型问题时,一个高效的排查流程如下:
# 1. 确认端口占用情况(netstat)
netstat -tunlp | grep 5500
# 2. 精准定位占用进程(lsof,更直接)
lsof -i :5500
# 输出会直接显示 COMMAND、PID、USER 等信息
# 3. 查看该进程的详细信息(ps)
ps -ef | grep <上一步查到的PID>
# 或查看资源占用
ps aux | grep <上一步查到的PID>
# 4. 做出决策(比如停止进程)
kill -9 <PID> # 强制终止,请谨慎使用
# 更温和的方式是先尝试:
kill -15 <PID> # 发送终止信号,允许程序做清理工作⚠️ 重要提示:kill -9(SIGKILL)是“强制拆除”,应作为最后手段。优先使用 kill -15(SIGTERM),给程序一个“礼貌告别”的机会。
命令 | 核心功能 | 擅长场景 | 一句话记忆 |
|---|---|---|---|
netstat | 网络连接与统计 | 查看端口监听、连接状态、路由 | “网络管家,管门又管路”🚪 |
ps | 进程状态快照 | 查看进程存在、资源占用、父子关系 | “进程相机,瞬间定格”📷 |
lsof | 列出打开文件 | 定位端口/文件被谁占用、进程文件操作 | “关联侦探,一查到底”🔍 |
你在日常运维中,遇到问题最习惯先用哪个命令?是 netstat、ps 还是 lsof?有没有什么让你印象深刻的排查经历或独家小技巧?欢迎分享!
熟练掌握这“三剑客”,你就能在服务器出现网络、进程、资源问题时迅速定位病灶,从被动救火转向主动运维。命令参数无需死记硬背,收藏此篇,用到时随手查阅,多用几次自然就熟了。
搜索关注【刘叨叨趣味运维】公众号,用有趣的方式,啃下最硬核的技术。咱们下期见!
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。