← 返回面试总览

🐧 Linux 高频命令与性能分析面试题

从常用命令到线上性能排查的实战套路

📚 Linux 命令与性能核心知识(15 题)

1. Linux 下常见的文件/目录操作命令有哪些?各自的典型用法是什么?简单
命令作用示例
ls列出目录内容ls -lh 按人类可读方式显示大小
cd切换目录cd /var/log
pwd打印当前目录pwd
mkdir创建目录mkdir -p /data/logs/app
rm删除文件/目录rm -rf /tmp/cache
cp复制文件/目录cp -r src/ dest/
mv移动/重命名mv app.log app.log.bak
find查找文件find . -name "*.log" -size +10M

面试时可以结合「清理日志」「查找大文件」等场景来讲,更贴近实际。

2. 如何快速查看大型日志文件,并过滤出关键行?简单

常用命令组合

# 查看文件前/后几行
head -n 100 app.log
tail -n 100 app.log

# 实时查看日志(常用于线上排查)
tail -f app.log

tail -f app.log | grep "ERROR"

# 使用 less 支持翻页和搜索
less app.log    # /keyword 搜索, n 跳到下一个

# grep 过滤关键信息
grep "Exception" app.log

grep -i "timeout" app.log          # 忽略大小写
grep -r "orderId=123" logs/        # 递归目录

grep -E "ERROR|WARN" app.log       # 多个模式

大日志文件不要直接 cat,推荐用 lesstail -f 配合 grep

3. ps、top、htop 有什么区别?线上排查时分别怎么用?简单

ps

# 查看当前用户的进程
ps aux | grep java

# 按 CPU 使用率排序ps aux --sort=-%cpu | head

# 查看某个 PID 详细信息
ps -p 12345 -o pid,ppid,cmd,%cpu,%mem

top/htop

  • top:自带的实时监控工具,键盘交互
  • htop:增强版 top,可视化更好(需安装)
top 常用快捷键:
- P:按 CPU 排序
- M:按内存排序
- 1:展开每个 CPU
- k:杀进程
- q:退出

htop:支持鼠标操作、树状显示、颜色更友好。
4. 系统 CPU 占用飙高时,你的排查步骤是什么?中等

步骤一:确认系统整体情况

uptime          # 查看负载
vmstat 1 5      # 查看 CPU 上下文切换、中断
mpstat -P ALL 1 # 各 CPU 使用情况(需 sysstat)

步骤二:定位高 CPU 进程

top -c             # 实时看,按 P 排序
ps aux --sort=-%cpu | head

步骤三:进一步分析(以 Java 为例)

# 找到 Java 进程 PID
ps aux | grep java

# 导出线程栈(JVM)
jstack 12345 > jstack-12345.txt

# 将十进制线程 ID 转为十六进制,用 top 里的 tid 对应
printf "%x\n" 1234

面试时重点讲「先系统层、再进程层、再应用层」的分层思路。

5. 如何理解 free 命令输出中的内存字段?buffer/cache 是什么?中等

free -h 示例

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           32G         20G        1.0G        1.0G         11G         10G
Swap:           4G        512M        3.5G
  • used:当前已被进程和缓存占用
  • buff/cache:文件缓存 + 块缓冲,用于加速 IO,可被回收
  • available:真正还可以给新进程使用的内存(更重要)

面试回答中要强调:Linux 会尽量把空闲内存拿来做缓存,缓存不等于「被浪费」

6. 如何判断当前系统是不是被 IO 拖慢了?中等

iostat / vmstat

iostat -x 1 5   # 需 sysstat

vmstat 1 5
  • iowait 高:说明 CPU 大量在等 IO
  • 磁盘 util 接近 100%:磁盘已打满
  • 平均响应时间大:磁盘压力很大
7. 服务间调用很慢,你会用哪些命令先粗排网络问题?中等

常用命令

ping target-host        # 连通性 + RTT
traceroute target-host  # 路由路径

# 查看端口监听
ss -lntp | grep 8080

# 当前网络连接
tcpdump -nn port 8080   # 抓包(需 root)

面试时可顺带提到线上一般通过网关/监控平台看延迟分布,命令行只做初步确认。

8. 请给出一个你常用的「一条命令快速锁定问题进程」组合。中等

示例组合

# 按 CPU 排序,取前 5 个进程
ps aux --sort=-%cpu | head -n 5

# 按内存排序
ps aux --sort=-%mem | head -n 5

# 只看 Java 进程
ps aux | grep java | grep -v grep | sort -k3 -r | head

回答时顺带说「然后再针对这个 PID 继续用 jstack / strace 等深入」。

9. 磁盘快满了,如何快速找出哪些目录占用空间最多?简单
df -h             # 查看各挂载点磁盘使用率

# 查看当前目录下各子目录大小
du -sh *          # 粗略

# 找出大于 500M 的目录
du -sh * | sort -h
find . -type f -size +500M -exec ls -lh {} \;

常见场景:日志没滚动、临时文件没清理、备份文件没删。

10. 假设线上一台机器整体「很慢」,你会用哪些命令按什么顺序排查?困难

分层思路 + 命令清单

  1. 负载:uptime 看 load average 是否明显高于 CPU 数量
  2. CPU:top 看 %us/%sy/%wa、top 进程
  3. 内存:free -htop 看是否大量 swap
  4. IO:iostat -x 1 5vmstat 1 5 看 iowait、磁盘 util
  5. 网络:ss -sifstatping

面试中重点讲「先看哪层、再看哪层」,而不是背命令。

11. 你在排查问题时是否用过 strace 或 lsof?简单说说思路。困难

lsof(列出进程打开的文件/端口)

# 查看某端口被谁占用
lsof -i:8080

# 查看某进程打开了哪些文件
lsof -p 12345 | head

strace(跟踪系统调用)

# 跟踪一个进程在做什么系统调用
strace -p 12345 -f -o strace.log

# 跟踪某命令
strace -T -tt -o strace.curl.log curl http://example.com

面试时只要能说出「用它们看看进程在干嘛、是不是卡在某个系统调用」,就已经很加分。

12. 统计某个日志中不同错误码出现的次数,你会怎么写命令?中等
# 假设格式类似:time level code=500 msg=...
cat app.log \
  | grep "code=" \
  | sed -E 's/.*code=([0-9]{3}).*/\1/' \
  | sort \
  | uniq -c \
  | sort -nr

# 输出示例:
# 120 500
#  35 404
#  10 401

考察点:是否熟悉 grep | sed | sort | uniq 这类经典流水线。

13. 线上执行一个可能跑很久的脚本,如何防止 SSH 断开导致任务中断?中等
  • nohup:nohup ./script.sh > run.log 2>&1 &
  • screen/tmux:在会话里运行脚本,即使 SSH 断开,会话仍在
14. 线上日志时间和业务时间对不上,你会从哪些方面检查?简单
  • 检查时区:datetimedatectl
  • 检查 NTP 同步:timedatectl statusntpq -p
  • 检查应用层是否有时区转换(例如 JVM -Duser.timezone
15. 请结合具体经历,讲一次你用 Linux 命令排查线上性能问题的过程。困难

这一题主要考察你是否「真用过」,可以按 STAR 法则准备一个自己的故事:

S(Situation):
- 某次线上 CPU 飙高,接口 P99 延迟从 50ms 变成 2s

T(Task):
- 在不影响业务的前提下,快速定位问题进程和原因

A(Action):
- 用 top 定位到某 Java 进程 CPU 100%
- 用 ps 查看该进程启动参数,确认是订单服务
- 用 jstack dump 线程栈,发现大量线程卡在某个远程调用上
- 再用 tcpdump 抓该下游的 8080 端口包,发现大量重传

R(Result):
- 最终定位为下游服务部署了有问题的版本
- 回滚后指标恢复,同时在网关层加了超时和降级策略

面试时,把这个过程讲顺畅,就是一段非常加分的经历。