<think>我们需要回答用户的问题："生产环境
查看历史过
高CPU线
程的方法"
根据用户提供的引用[1]和引用[2]，以及我们之前的回答，我们可以给出如下建议：
引用[1]提到：
top命令没有细分进
程的用户态
CPU和内核态
CPU，而pidstat可以分析每个进
程CPU使用情况。
引用[2]提到：用户级线
程和内核级线
程的调度。
但是用户现在关心的是：如何
查看历史过
高的
CPU线
程（即当
CPU突然过
高时，哪些线
程占用了过
高的
CPU，并且希望能够在事后排查）。
我们的思路：
1. 如果系统在
CPU过
高时已经捕获了线
程级别的快照（比如jstack、pstack等），那么可以直接分析这些快照。
2. 如果没有预先捕获，那么就要依赖系统监控工具记录的历史数据。
然而，常见的系统监控工具（如
top, pidstat）默认并不会持续记录每个线
程的历史数据。所以我们需要一些额外的方法。
解决方法：
方法一：使用监控工具定期采样并保存线
程状态（需要提前配置）
方法二：利用系统已有的性能日志（如sar，但它只能记录到进
程级别，不能记录线
程）
方法三：分析系统在
CPU过
高时间段内的系统日志和内核转储（如果有）
具体步骤：
1. **使用`pidstat`历史记录**：
`pidstat`命令可以记录进
程的
CPU使用情况，但是默认不会记录线
程。我们可以使用`pidstat`的`
-t`参数来记录线
程。不过，这需要我们在问题发生前已经配置了定期的采集任务。
例如，我们可以设置每10秒采集一次，并将输出重定向到文件中：
```
bash
pidstat
-t
-u 10 > pidstat.log
```
这样，在问题发生后，我们可以通过
查看这个日志文件，
找到对应时间段内
CPU使用率
高的线
程。
2. **使用`
top`命令的批处理模式**：
我们可以让`
top`在批处理模式下运行，定期输出线
程信息：
```
bash
top -H
-b
-d 10 >
top_threads.log
```
其中`
-H`表示显示线
程，`
-b`表示批处理模式，`
-d`指定间隔时间（秒）。这样，我们就可以获得线
程级别的历史数据。
3. **使用性能监控工具（如Perf）**：
Perf可以记录系统在一段时间内的性能数据，包括
函数调用和线
程的
CPU使用情况。我们可以使用：
```
bash
perf record
-g
-p <pid>
-o perf.data
```
然后使用`perf report`来分析。但是这种方法需要实时运行，如果当时没有运行，则无法回溯。
4. **事后分析系统日志**：
如果系统配置了`sysstat`工具，那么我们可以使用`sar`命令
查看历史
CPU使用情况（但只能到进
程级别）：
```
bash
sar
-u
-f /var/log/sa/saXX #
查看某天的
CPU使用历史
```
结合进
程级别的历史数据，我们可以定位到占用
CPU高的进
程，然后再结合应用
程序的日志（比如Java应用可以定期dump线
程栈）来推测当时线
程的情况。
5. **应用
程序自身的线
程栈历史**：
对于一些应用（如Java应用），可以通过配置在
CPU过
高时自动dump线
程栈。例如，使用jvm参数配置当
CPU使用超过阈值时触发jstack。或者使用外部工具监控，当
CPU使用率过
高时自动执行jstack。
6. **内核转储（coredump）**：
如果当时发生了崩溃，内核转储会保存进
程的内存映像，其中包含线
程信息。我们可以通过gdb等工具分析。
但是，如果这些都没有提前配置，那么事后
查看历史线
程信息几乎是不可能的。因此，我们建议：
**预防性监控配置**：
- 定期收集线
程级别的
CPU使用情况（如上面提到的
top或pidstat定期运行）。
- 使用APM（应用性能监控）工具，如Pinpoint、SkyWalking等，它们可以记录方法级别的执行时间和线
程状态。
- 设置
CPU使用率告警，并在告警时触发线
程栈快照的保存。
考虑到用户可能没有提前配置，我们只能尝试以下方法：
- **检查系统已有的日志**：
查看系统日志（/var/log/messages, dmesg等）看是否有OOM、死锁或其他异常。
查看应用日志，是否有大量错误或长时间等待。
- **基于进
程历史数据推测线
程问题**：
如果我们可以通过sar或者pidstat的历史数据知道是哪个进
程在问题时间段占用了过
高的
CPU，那么我们可以结合该进
程的特性来推断。例如：
- 如果是数据库进
程，可能是慢查询导致，需要检查慢查询日志。
- 如果是Web服务器（如Tomcat），可能是某些请求处理线
程卡在某个循环或阻塞操作，检查访问日志和线
程栈。
总结：
如果没有提前配置线
程级别的监控，事后很难直接获取历史线
程的
CPU使用情况。只能通过进
程级别的监控和应用
程序日志进行间接分析。
因此，我们强烈建议在生产环境中配置线
程级别的定期监控，或者配置在
CPU过
高时自动触发线
程栈快照。
下面给出一个自动捕获
高CPU线
程的脚本示例（每30秒检查一次，当发现进
程的
CPU使用率超过阈值时，捕获该进
程的线
程栈）：
```
bash
#!/bin/
bash
# 监控目标进
程的
CPU使用率，并在超过阈值时dump线
程栈
PID=$1 # 目标进
程的PID
THRESHOLD=80 #
CPU使用率阈值（百分比）
INTERVAL=30 # 检查间隔（秒）
while true; do
# 使用ps获取该进
程的
CPU使用率
CPU_USAGE=$(ps
-p $PID
-o %
cpu | grep
-v %
CPU | awk '{print int($1)}')
if [ $
CPU_USAGE
-ge $THRESHOLD ]; then
echo "$(date)
CPU使用率超过阈值: ${
CPU_USAGE}%"
# 使用jstack（如果是Java应用）捕获线
程栈
jstack
-l $PID > jstack_${PID}_$(date +%Y%m%d%H%M%S).log
# 或者使用
top捕获该进
程的所有线
程
top -H
-b
-n1
-p $PID >
top_threads_${PID}_$(date +%Y%m%d%H%M%S).log
# 也可以使用pidstat记录
pidstat
-t
-p $PID 1 10 > pidstat_threads_${PID}_$(date +%Y%m%d%H%M%S).log
fi
sleep $INTERVAL
done
```
注意：这个脚本只是一个示例，实际应用中需要考虑进
程可能重启（PID变化）以及磁盘空间等问题。
最后，我们生成相关问题：
§§相关问题§§
1. 如何配置自动化的线
程栈快照捕获以应对
CPU过
高问题?
2. 除了线
程栈，还有哪些方法可以分析历史
CPU使用
高峰?
3. 在生产环境中如何实时监控线
程级别的
CPU使用情况?
4. 如何分析Java应用
程序的线
程栈快照?
</think>### 生产环境
查看历史过
高CPU线
程的方法
即使
CPU使用率已恢复正常，仍可通过以下方法排查历史过
高CPU线
程问题（需提前配置监控）：
---
#### **1. 系统级线
程监控** 🔍
**核心工具**：
- **`pidstat`历史分析**
通过系统定时任务记录线
程级
CPU使用率（需提前配置）：
```
bash
# 每30秒记录所有进
程线
程的
CPU使用率
pidstat
-t
-u 30 > /var/log/pidstat_$(date +\%F).log # 引用[1][^1]
```
分析峰值时段
高负载线
程：
```
bash
grep "问题时间" /var/log/pidstat_*.log | sort
-k7
-rn | head
```
- **`perf`性能分析**
安装`linux
-perf`包后捕获
CPU热点：
```
bash
# 记录全系统
CPU使用(持续60秒)
perf record
-g
-a sleep 60
# 生成火焰图
perf script | FlameGraph/stackcollapse
-perf.pl | FlameGraph/flamegraph.pl >
cpu_flame.svg
```
---
#### **2. 应用级线
程捕获** ⚙️
**关键配置**：
- **Java应用**
通过`jstack`定时捕获线
程栈（结合`cron`）：
```
bash
*/5 * * * * jstack
-l <PID> > /logs/jstack_$(date +\%H\%M).log 2>&1
```
使用`tda`等工具分析线
程阻塞状态：
```
bash
grep
-A10 "问题时段" /logs/jstack_*.log | awk '/nid=0x[0
-9a
-f]+/ {print $0}'
```
- **C/C++应用**
通过`gdb`脚本定时捕获：
```python
# gdb_script.py
gdb
-p <PID>
-ex "thread apply all bt"
-ex "detach"
-ex "quit" > /logs/bt_$(date +\%s).log
```
---
#### **3. 内核级追溯**
**诊断方法**：
- **eBPF实时监控**
使用`bcc
-tools`追踪
CPU占用：
```
bash
/usr/share/bcc/tools/
cpudist
-p <PID>
-O > /logs/ebpf_
cpu.log
```
- **内核调度分析**
通过`trace
-cmd`捕获调度事件：
```
bash
trace
-cmd record
-e sched_switch
-o sched.dat sleep 60
trace
-cmd report sched.dat | grep "问题时间"
```
---
#### **4. 自动化监控方案** 🤖
| 工具 | 功能 | 配置示例 |
|
---------------------|
-------------------------------|
----------------------------|
| **Prometheus+Node_exporter** | 线
程级指标采集 | `node_exporter
--collector.processes` |
| **Grafana** | 可视化线
程CPU时序 | 配置`process_
cpu_seconds_total`面板 |
| **Elastic APM** | 自动捕获应用线
程栈 | 集成APM agent自动上报 |
> 📌 **关键点**：
>
- 用户级与内核级线
程监控需结合（引用[2]）[^2]
>
- 历史线
程追溯依赖事前监控配置
>
- 火焰图可直观显示$$ \sum \text{
CPU热点
函数} $$ 分布
---
Linux系统性能分析：top、gdb与线程排查
本文介绍了如何使用Linux命令`top`以线程视角分析系统资源占用，通过`gdb attach`定位进程，并利用`gdb info threads`查看线程调用栈，深入理解进程内部频繁调用的函数，从而进行性能瓶颈排查。
扫一扫
1111
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
