news 2026/5/23 0:25:22

Linux进程排查实战:strace和lsof救命指南

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Linux进程排查实战:strace和lsof救命指南

服务起不来,日志没报错。进程在跑,但就是不干活。

这种问题最恶心,看日志看不出问题,看监控也没异常。

这时候就需要strace和lsof这两个神器了。

strace:跟踪系统调用

strace能看到进程在做什么系统调用,相当于给进程装了个监控摄像头。

基本用法

# 跟踪一个命令stracels# 跟踪正在运行的进程strace-p<pid># 跟踪子进程strace-f -p<pid>

案例一:服务启动卡住

现象:Java服务启动后卡住,不打印任何日志。

# 找到进程号psaux|grepjava# 假设是12345# strace跟踪strace-p12345

输出:

futex(0x7f8a8c000000, FUTEX_WAIT_PRIVATE, 0, NULL

卡在futex,说明在等锁。

进一步看是什么锁:

strace-p12345-etrace=futex -T

结合jstack看线程栈:

jstack12345>thread.dumpgrep-A20"BLOCKED"thread.dump

发现是启动时连接数据库,数据库连不上,超时时间设太长了。

案例二:文件读写问题

现象:服务很慢,但CPU和内存都不高。

# 只看文件相关的调用strace-p12345-etrace=file# 或者看所有IOstrace-p12345-etrace=read,write,open,close

输出:

open("/data/logs/app.log", O_WRONLY|O_APPEND) = 3 write(3, "2024-12-23 10:00:00 INFO...", 1024) = 1024 close(3) = 0 open("/data/logs/app.log", O_WRONLY|O_APPEND) = 3 write(3, "2024-12-23 10:00:00 INFO...", 1024) = 1024 close(3) = 0 ...

每次写日志都open-write-close,频繁的文件操作导致性能差。

改成保持文件句柄打开,或者用异步日志。

案例三:网络问题

现象:服务偶尔超时。

# 只看网络相关strace-p12345-etrace=network -T

输出:

connect(5, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("10.0.0.1")}, 16) = -1 ETIMEDOUT (Connection timed out) <30.001234>

连接数据库超时30秒,问题找到了。

常用参数

# -f:跟踪子进程strace-f -p12345# -T:显示每个调用耗时strace-T -p12345# -t:显示时间戳strace-t -p12345# -c:统计系统调用次数和耗时strace-c -p12345# -o:输出到文件strace-o trace.log -p12345# 组合使用strace-f -T -t -o trace.log -p12345

统计分析

strace-c -p12345

输出:

% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 45.23 2.345678 234 10000 write 30.12 1.234567 1234 1000 read 20.11 0.987654 98 10000 futex 4.54 0.234567 23 10000 clock_gettime ------ ----------- ----------- --------- --------- ---------------- 100.00 4.802466 31000 total

一眼就能看出时间花在哪了。

lsof:列出打开的文件

Linux里一切皆文件,lsof能看到进程打开了什么文件、网络连接、设备等。

基本用法

# 查看进程打开的所有文件lsof-p<pid># 查看某个文件被谁打开lsof/var/log/app.log# 查看某个端口lsof-i :8080# 查看某个用户的所有打开文件lsof-u root

案例一:端口被占用

# 谁占用了8080端口lsof-i :8080

输出:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 12345 root 123u IPv6 123456 0t0 TCP *:8080 (LISTEN)

进程12345占用了8080端口。

案例二:文件句柄泄漏

现象:服务运行一段时间后报"Too many open files"。

# 查看进程打开的文件数lsof-p12345|wc-l# 按文件类型分组统计lsof-p12345|awk'{print$5}'|sort|uniq-c|sort-rn

输出:

5000 IPv4 3000 REG 1000 DIR

5000个网络连接?明显有连接泄漏。

# 看看都连了谁lsof-p12345-i|head-20
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 12345 root 123u IPv4 123456 0t0 TCP 10.0.0.1:54321->10.0.0.2:3306 (ESTABLISHED) java 12345 root 124u IPv4 123457 0t0 TCP 10.0.0.1:54322->10.0.0.2:3306 (ESTABLISHED) java 12345 root 125u IPv4 123458 0t0 TCP 10.0.0.1:54323->10.0.0.2:3306 (ESTABLISHED) ...

全是连数据库的,连接池用完没归还。

案例三:删除的文件还在占用空间

# 查看已删除但仍被引用的文件lsof+L1

输出:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME java 12345 root 10w REG 253,1 10737418240 0 12345 /var/log/app.log (deleted)

日志文件被删了,但进程还引用着,10G空间释放不掉。

解决:重启服务,或者truncate文件:

# 找到文件描述符路径ls-l /proc/12345/fd/10# 清空内容但不关闭句柄:>/proc/12345/fd/10

案例四:网络连接分析

# 查看所有网络连接lsof-i# 只看TCPlsof-i tcp# 只看某个状态lsof-i|grepESTABLISHED# 统计连接数lsof-i|grepESTABLISHED|wc-l# 按目标地址分组lsof-i|grepESTABLISHED|awk'{print$9}'|cut-d'>'-f2|cut-d':'-f1|sort|uniq-c|sort-rn

组合使用

排查思路

  1. 先用top/htop看整体
  2. 用ps看进程状态
  3. 用lsof看打开了什么
  4. 用strace看在做什么

实战:服务假死排查

现象:服务进程在,但不响应请求。

# 1. 看进程状态psaux|grepjava# 状态是Sl,正常# 2. 看打开的文件和连接lsof-p12345|wc-l# 8000+,有点多# 3. 看网络连接lsof-p12345-i|grep-c ESTABLISHED# 5000+,太多了# 4. 看连接状态分布ss -tnp|grep12345|awk'{print$4}'|sort|uniq-c# 大量CLOSE_WAIT# 5. strace看在做什么strace-p12345-etrace=network# 卡在accept上,但新连接进不来

根因:连接池满了,CLOSE_WAIT状态的连接没有正确关闭。

实战:CPU 100%排查

# 1. top找到占用CPU的进程top-c# PID 12345 CPU 99%# 2. 看线程CPU使用top-H -p12345# TID 12346 CPU 99%# 3. 把线程ID转成16进制printf"%x\n"12346# 303a# 4. jstack看线程栈(Java)jstack12345|grep-A30"0x303a"# 5. 或者用strace看系统调用strace-p12346-c

远程排查

有时候问题机器在远程,需要登录排查。

我们有几台服务器在不同机房,之前用跳板机一层层跳很麻烦。现在用星空组网把所有机器组到一起,直接SSH过去就能用strace、lsof排查,效率高多了。

常用命令速查

# strace速查strace-p<pid># 跟踪进程strace-f -p<pid># 跟踪包括子进程strace-etrace=network -p<pid># 只看网络strace-etrace=file -p<pid># 只看文件strace-c -p<pid># 统计strace-T -p<pid># 显示耗时# lsof速查lsof-p<pid># 进程打开的文件lsof-i :<port># 谁占用端口lsof-i tcp# 所有TCP连接lsof+L1# 已删除但仍占用的文件lsof-u<user># 用户打开的文件

总结

工具用途典型场景
strace跟踪系统调用卡死、慢、报错看不出原因
lsof看打开的文件/连接端口占用、文件泄漏、连接泄漏

排查原则:

  1. 从宏观到微观
  2. 从现象到根因
  3. 不确定就多看几遍

这两个工具用熟了,大部分疑难杂症都能查出来。


有排查经验欢迎评论区分享~

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/5/20 11:23:48

边缘计算驱动的实时异常检测算法部署指南

边缘侧实时异常检测&#xff1a;从算法到部署的实战全解析在智能制造车间的一台旋转设备上&#xff0c;振动传感器每秒采集上百个数据点。某天凌晨&#xff0c;轴承开始出现微弱的周期性冲击信号——这种变化人耳无法察觉&#xff0c;云端监控系统也因采样间隔过长而错过。但就…

作者头像 李华
网站建设 2026/5/21 0:44:36

【AI时代新生产力工具】:Open-AutoGLM驱动电脑自动化的7个高阶应用场景

第一章&#xff1a;Open-AutoGLM驱动自动化的核心机制Open-AutoGLM 是一种基于生成式语言模型的自动化引擎&#xff0c;其核心在于将自然语言指令转化为可执行的工作流。该机制依赖于语义解析、任务调度与执行反馈三大模块的协同运作&#xff0c;实现从用户意图到系统操作的端到…

作者头像 李华
网站建设 2026/5/20 12:12:10

LangFlow事件循环机制解析

LangFlow事件循环机制解析 在构建大语言模型&#xff08;LLM&#xff09;应用的今天&#xff0c;开发者常常面临一个尴尬的局面&#xff1a;明明只是想快速验证一个想法&#xff0c;却不得不花大量时间写胶水代码、调试组件连接、反复重启服务查看输出。这种低效的开发流程严重…

作者头像 李华
网站建设 2026/5/21 5:50:31

开源Open-AutoGLM地址到底在哪?10分钟带你找到官方资源并部署上线

第一章&#xff1a;开源的Open-AutoGLM地址在哪Open-AutoGLM 是一个面向自动化自然语言处理任务的开源框架&#xff0c;由深度学习与大模型研究团队联合发布&#xff0c;旨在降低大语言模型在实际场景中的应用门槛。该项目已在主流代码托管平台公开源码&#xff0c;便于开发者查…

作者头像 李华
网站建设 2026/5/21 11:51:40

Open-AutoGLM落地实战(手机端大模型部署全攻略)

第一章&#xff1a;Open-AutoGLM落地实战&#xff08;手机端大模型部署全攻略&#xff09;在移动端部署大语言模型已成为智能应用开发的关键环节。Open-AutoGLM 作为开源的轻量化 GLM 架构推理框架&#xff0c;专为资源受限设备优化&#xff0c;支持在 Android 和 iOS 平台高效…

作者头像 李华