关于 performance-profiling
performance-profiling 面向排查系统或应用性能问题的开发者与运维人员,涵盖内核和应用级分析、瓶颈定位及优化建议。
主要功能
- 01CPU、内存、I/O 和网络分析
- 02Linux 内核跟踪与性能分析
- 03应用和数据库分析
- 04瓶颈与性能回退检测
- 05性能报告与可视化
适用场景
- 01排查应用响应缓慢
- 02定位 Linux 系统资源瓶颈
- 03比较变更前后的性能
- 04分析生产环境性能回退
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ wojons/ skills --skill performance-profiling安装后在 Claude Code 中输入/performance-profiling确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
README.mdreferences/README.mdscripts/analyze-performance.sh详细介绍
性能剖析
使用全面的剖析技术分析系统和应用程序性能,包括 Linux 内核级工具(perf、ftrace、eBPF、SystemTap)、应用程序级剖析、瓶颈识别和优化建议,以提升系统响应速度、吞吐量和资源效率。
适用场景
在以下情况下使用此技能:
- 应用程序运行缓慢或性能下降
- 系统资源利用率过高
- 识别 CPU、内存、I/O 或网络瓶颈
- 优化应用程序响应时间
- 调试性能回退
- 进行容量规划和资源配置
- 比较变更前后的性能
- 分析生产环境中的性能问题
- 建立性能基准
- 调整系统和应用程序参数
我能做什么
1. 系统级剖析
- CPU 剖析:分析 CPU 使用率、上下文切换、中断和调度器延迟
- 内存剖析:分析内存使用情况、缺页、交换和内存泄漏
- I/O 剖析:分析磁盘 I/O、文件系统性能和存储延迟
- 网络剖析:分析网络吞吐量、延迟、丢包和连接
- 内核剖析:分析内核函数、系统调用和中断处理程序
2. 应用程序级剖析
- 应用程序 CPU 使用情况:剖析应用程序专属的 CPU 消耗
- 内存分配:跟踪堆分配、垃圾回收和内存泄漏
- 函数计时:测量函数执行时间和调用频率
- 数据库查询剖析:分析 SQL 查询性能并进行优化
- API 端点剖析:测量 API 响应时间和吞吐量
3. 工具集成
- Linux perf:CPU 剖析、硬件性能计数器和跟踪点
- eBPF/BCC:动态跟踪和自定义性能检测
- Ftrace:内核函数跟踪、事件跟踪和延迟测量
- SystemTap:系统范围的跟踪和剖析
- 应用程序剖析器:特定语言的剖析工具
- 容器剖析:Docker、Kubernetes 性能分析
4. 瓶颈识别
- 热点检测:识别频繁执行的代码路径
- 资源争用:检测锁争用、CPU 资源不足和 I/O 等待
- 延迟分析:测量并分析延迟分布
- 可扩展性分析:识别可扩展性限制和瓶颈
- 异常检测:检测性能异常和回退
5. 优化建议
- 代码优化:建议改进算法和缓存策略
- 配置调优:建议系统和应用程序调优参数
- 架构改进:建议通过架构变更提升性能
- 资源分配:建议最优的资源分配策略
- 监控设置:建议性能监控配置
6. 可视化与报告
- 火焰图:生成 CPU 和内存火焰图以进行可视化
- 热力图:创建延迟热力图以进行时间序列分析
- 性能仪表板:创建实时性能仪表板
- 趋势分析:分析随时间变化的性能趋势
- 对比报告:比较不同版本/环境之间的性能
涵盖的剖析工具
Linux 内核级工具
- perf:用于 CPU 剖析和硬件计数器的 Linux 性能事件
- eBPF/BCC:用于动态跟踪的扩展伯克利数据包过滤器
- bpftrace:用于 eBPF 的高级跟踪语言
- Ftrace:用于函数跟踪的 Linux 内核内部跟踪器
- SystemTap:系统范围的跟踪和剖析框架
- LTTng:Linux 跟踪工具包新一代
- ktap:轻量级内核跟踪
应用级工具
- Java:JProfiler、YourKit、VisualVM、Async Profiler
- Python:cProfile、py-spy、Scalene、line_profiler
- Node.js:clinic.js、0x、node --prof、v8-profiler
- Go:pprof、trace、delve、gops
- Ruby:ruby-prof、stackprof、rbspy
- .NET:dotnet-counters、dotnet-trace、PerfView
- PHP:Xdebug、Blackfire、Tideways
- C/C++:gprof、Valgrind、Intel VTune、perf
系统监控工具
- top/htop:进程监控
- vmstat:虚拟内存统计
- iostat:I/O 统计
- netstat/ss:网络统计
- sar:系统活动报告工具
- dstat:多用途资源统计
- nmon:Nigel 的性能监控工具
可视化工具
- FlameGraph:CPU 和内存火焰图
- perfetto:系统跟踪和性能可视化
- grafana:性能仪表板可视化
- prometheus:时间序列监控和告警
- jaeger:分布式跟踪可视化
分析技术
使用 perf 进行 CPU 性能分析
# Sample CPU usage for 30 seconds
perf record -F 99 -ag -- sleep 30
# Generate flame graph
perf script | stackcollapse-perf.pl | flamegraph.pl > flamegraph.svg
# Analyze hardware performance counters
perf stat -e cycles,instructions,cache-misses,branch-misses ./application
# Trace system calls
perf trace -e syscalls:sys_enter_* ./application
使用 BCC 进行 eBPF 跟踪
from bcc import BPF
# eBPF program to trace function calls
bpf_text = """
#include <uapi/linux/ptrace.h>
struct data_t {
u64 timestamp;
u32 pid;
char comm[TASK_COMM_LEN];
u64 duration_ns;
};
BPF_HASH(start, u32);
BPF_PERF_OUTPUT(events);
int trace_entry(struct pt_regs *ctx) {
u32 pid = bpf_get_current_pid_tgid();
u64 ts = bpf_ktime_get_ns();
start.update(&pid, &ts);
return 0;
}
int trace_return(struct pt_regs *ctx) {
u32 pid = bpf_get_current_pid_tgid();
u64 *tsp = start.lookup(&pid);
if (tsp == 0) {
return 0;
}
u64 duration = bpf_ktime_get_ns() - *tsp;
struct data_t data = {};
data.timestamp = bpf_ktime_get_ns();
data.pid = pid;
data.duration_ns = duration;
bpf_get_current_comm(&data.comm, sizeof(data.comm));
events.perf_submit(ctx, &data, sizeof(data));
start.delete(&pid);
return 0;
}
"""
# Attach to function entry and return
bpf = BPF(text=bpf_text)
bpf.attach_uprobe(name="application", sym="function_name", fn_name="trace_entry")
bpf.attach_uretprobe(name="application", sym="function_name", fn_name="trace_return")
内存泄漏检测
# Monitor memory allocations
valgrind --leak-check=full --show-leak-kinds=all ./application
# Track heap allocations with eBPF
/usr/share/bcc/tools/memleak -p $(pidof application)
# Analyze memory usage over time
cat /proc/$(pidof application)/smaps | grep -i pss | awk '{total+=$2} END {print total}'
# Monitor garbage collection (Java)
jstat -gc $(pidof java) 1s
延迟分析
def analyze_latency_distribution(latency_samples):
"""
Analyze latency distribution and identify outliers.
"""
import numpy as np
from scipy import stats
latencies = np.array(latency_samples)
analysis = {
'count': len(latencies),
'mean': np.mean(latencies),
'median': np.median(latencies),
'p90': np.percentile(latencies, 90),
'p95': np.percentile(latencies, 95),
'p99': np.percentile(latencies, 99),
'std_dev': np.std(latencies),
'min': np.min(latencies),
'max': np.max(latencies),
'outliers': []
}
# Identify outliers using IQR method
q1 = np.percentile(latencies, 25)
q3 = np.percentile(latencies, 75)
iqr = q3 - q1
lower_bound = q1 - 1.5 * iqr
upper_bound = q3 + 1.5 * iqr
outliers = latencies[(latencies < lower_bound) | (latencies > upper_bound)]
analysis['outliers'] = outliers.tolist()
analysis['outlier_percentage'] = len(outliers) / len(latencies) * 100
return analysis
示例
# Profile CPU usage for 60 seconds
npm run performance-profiling:cpu -- --duration 60 --output cpu-profile.json
# Generate flame graph
npm run performance-profiling:flamegraph -- --pid $(pidof application) --output flamegraph.svg
# Analyze memory leaks
npm run performance-profiling:memory -- --application myapp --leak-check
# Trace database queries
npm run performance-profiling:database -- --database postgresql --duration 300
# Profile API endpoints
npm run performance-profiling:api -- --endpoints "/api/*" --duration 60 --output api-performance.json
# Compare performance before/after changes
npm run performance-profiling:compare -- --before baseline.json --after new-version.json --output comparison.json
# Analyze system resource usage
npm run performance-profiling:system -- --metrics cpu,memory,disk,network --duration 300
# Create performance dashboard
npm run performance-profiling:dashboard -- --metrics all --interval 1s --duration 3600
# Detect bottlenecks in microservices
npm run performance-profiling:microservices -- --services auth,payment,notification --duration 600
# Optimize configuration based on profiling
npm run performance-profiling:optimize -- --profile profile.json --output optimizations.md
# Monitor production performance
npm run performance-profiling:monitor -- --production --alert-threshold p95:200ms
输出格式
性能分析报告:
Performance Profiling Report
────────────────────────────
System: payment-processing-service
Analysis Date: 2026-02-26
Duration: 300 seconds
Profiling Tools: perf, eBPF, Application Profiler
Executive Summary:
⚠️ Performance issues detected: 3 critical, 2 warnings
✅ System resources: Within normal limits
📊 Overall performance score: 72/100
Critical Issues:
1. ❌ Database query bottleneck (Severity: Critical)
• Query: SELECT * FROM transactions WHERE user_id = ?
• Average latency: 450ms (p95: 1200ms)
• Frequency: 1200 executions/minute
• Root cause: Missing index on user_id column
• Impact: 40% of API latency
• Recommendation: Add index on transactions.user_id
2. ❌ Memory leak in cache service (Severity: Critical)
• Service: redis-cache-service
• Memory growth: 2MB/minute
• Total leaked: 120MB over 1 hour
• Pattern: Cache entries not expired properly
• Recommendation: Implement TTL and LRU eviction
3. ❌ CPU contention in payment processor (Severity: Critical)
• Function: processPayment() in payment-service
• CPU usage: 85% during peak
• Bottleneck: Cryptographic operations
• Recommendation: Implement caching or hardware acceleration
Warnings:
1. ⚠️ API endpoint latency degradation (Severity: Warning)
• Endpoint: POST /api/v1/payments
• p95 latency increase: 150ms → 320ms (+113%)
• Timeframe: Last 7 days
• Recommendation: Profile endpoint and optimize
2. ⚠️ Garbage collection pauses (Severity: Warning)
• Application: notification-service (Java)
• GC pauses: 45ms average, 120ms max
• Frequency: Every 30 seconds
• Recommendation: Tune JVM garbage collector
System Resource Analysis:
┌────────────────────┬────────────┬────────────┬────────────┐
│ Resource │ Usage │ Threshold │ Status │
├────────────────────┼────────────┼────────────┼────────────┤
│ CPU │ 65% │ 80% ✅ Normal │
│ Memory │ 72% │ 85% ✅ Normal │
│ Disk I/O │ 45% │ 70% ✅ Normal │
│ Network │ 38% │ 60% ✅ Normal │
│ Database Connections│ 85% │ 90% ⚠️ Warning │
└────────────────────┴────────────┴────────────┴────────────┘
Application Performance:
• API Response Times:
- p50: 85ms ✅
- p95: 320ms ⚠️
- p99: 1200ms ❌
- Success Rate: 99.8% ✅
• Database Performance:
- Query Cache Hit Rate: 65% ⚠️
- Average Query Time: 85ms ✅
- Slow Queries (>100ms): 12% ⚠️
- Connection Pool Usage: 85% ⚠️
• Cache Performance:
- Redis Hit Rate: 92% ✅
- Cache Latency: 3ms ✅
- Memory Usage: 78% ⚠️
- Eviction Rate: 5% ✅
Flame Graph Analysis:
• Hot Functions:
1. processPayment() - 35% CPU time
2. validateTransaction() - 22% CPU time
3. updateDatabase() - 18% CPU time
4. sendNotification() - 8% CPU time
5. logActivity() - 5% CPU time
• Optimization Opportunities:
1. Cache validation results (potential 15% improvement)
2. Batch database updates (potential 10% improvement)
3. Async notifications (potential 8% improvement)
Memory Analysis:
• Heap Usage: 2.4GB
• Stack Usage: 320MB
• Native Memory: 450MB
• Garbage Collection:
- Young GC: 45ms every 30s
- Full GC: 120ms every 5min
- Throughput: 98.5%
I/O Analysis:
• Disk Read: 45MB/s (average)
• Disk Write: 28MB/s (average)
• File Descriptors: 1250/4096 (31%)
• Network Throughput:
- Inbound: 85Mbps
- Outbound: 120Mbps
- Connections: 850 active
Bottleneck Timeline:
┌─────────────────────────────────────────────────────────────┐
│ Bottleneck Timeline (Last 60 minutes) │
│ │
│ 00:00 ┼───────┬──────────────┬─────────────┬────────────── │
│ │ CPU │ Database │ Memory │ Network │
│ 15:00 ┼───────┼──────────────┼─────────────┼────────────── │
│ │ ███ │ █████████ │ ███ │ ██ │
│ 30:00 ┼───────┼──────────────┼─────────────┼────────────── │
│ │ █████ │ ████████████ │ █████ │ ███ │
│ 45:00 ┼───────┼──────────────┼─────────────┼────────────── │
│ │ ██████│ █████████████│ ███████ │ ████ │
│ 60:00 ┼───────┴──────────────┴─────────────┴────────────── │
│ 0% 50% 100% │
└─────────────────────────────────────────────────────────────┘
Optimization Recommendations:
1. Immediate (High Impact):
• Add database index on transactions.user_id
• Implement cache TTL for redis-cache-service
• Optimize processPayment() cryptographic operations
2. Short-term (Medium Impact):
• Implement connection pooling for database
• Add query caching for frequent queries
• Batch database writes where possible
3. Long-term (Architectural):
• Implement read replicas for database
• Add CDN for static assets
• Implement circuit breakers for external services
Performance Metrics Baseline:
• CPU Usage: < 70% target
• Memory Usage: < 80% target
• API p95 Latency: < 200ms target
• Database Query Time: < 100ms target
• Cache Hit Rate: > 90% target
Monitoring Configuration:
• Alert on: p95 latency > 200ms
• Alert on: CPU usage > 80% for 5 minutes
• Alert on: Memory usage > 85%
• Alert on: Error rate > 1%
• Dashboard: Real-time performance metrics
Next Steps:
1. Implement database index (estimate: 2 hours)
2. Fix memory leak in cache service (estimate: 4 hours)
3. Optimize payment processor CPU usage (estimate: 8 hours)
4. Deploy optimizations with feature flags
5. Monitor performance for 24 hours
6. Schedule performance regression tests
JSON 输出格式:
{
"analysis": {
"system": "payment-processing-service",
"analysis_date": "2026-02-26",
"duration_seconds": 300,
"profiling_tools": ["perf", "ebpf", "application_profiler"],
"overall_score": 72
},
"critical_issues": [
{
"id": "issue-db-001",
"description": "Database query bottleneck",
"severity": "critical",
"component": "database",
"metric": "query_latency",
"average_value": 450,
"p95_value": 1200,
"unit": "ms",
"frequency": "1200 executions/minute",
"root_cause": "Missing index on user_id column",
"impact": "40% of API latency",
"recommendation": "Add index on transactions.user_id",
"estimated_effort_hours": 2,
"priority": "high"
},
{
"id": "issue-memory-001",
"description": "Memory leak in cache service",
"severity": "critical",
"component": "cache",
"metric": "memory_growth",
"average_value": 2,
"unit": "MB/minute",
"total_leaked": 120,
"total_leaked_unit": "MB",
"timeframe": "1 hour",
"pattern": "Cache entries not expired properly",
"recommendation": "Implement TTL and LRU eviction",
"estimated_effort_hours": 4,
"priority": "high"
}
],
"system_resources": {
"cpu": {
"usage_percentage": 65,
"threshold": 80,
"status": "normal",
"breakdown": {
"user": 45,
"system": 20,
"iowait": 8,
"steal": 2
}
},
"memory": {
"usage_percentage": 72,
"threshold": 85,
"status": "normal",
"breakdown": {
"heap": 2400,
"stack": 320,
"native": 450,
"cached": 1200
}
},
"disk_io": {
"usage_percentage": 45,
"threshold": 70,
"status": "normal",
"read_mbps": 45,
"write_mbps": 28
},
"network": {
"usage_percentage": 38,
"threshold": 60,
"status": "normal",
"inbound_mbps": 85,
"outbound_mbps": 120,
"connections": 850
}
},
"application_performance": {
"api_response_times": {
"p50_ms": 85,
"p95_ms": 320,
"p99_ms": 1200,
"success_rate": 99.8
},
"database_performance": {
"query_cache_hit_rate": 65,
"average_query_time_ms": 85,
"slow_queries_percentage": 12,
"connection_pool_usage": 85
},
"cache_performance": {
"hit_rate": 92,
"latency_ms": 3,
"memory_usage_percentage": 78,
"eviction_rate": 5
}
},
"flame_graph_analysis": {
"hot_functions": [
{
"function": "processPayment",
"cpu_percentage": 35,
"optimization_opportunity": "Cache validation results"
},
{
"function": "validateTransaction",
"cpu_percentage": 22,
"optimization_opportunity": "Batch validation"
}
],
"optimization_opportunities": [
{
"description": "Cache validation results",
"estimated_improvement": 15,
"effort_hours": 8
},
{
"description": "Batch database updates",
"estimated_improvement": 10,
"effort_hours": 6
}
]
},
"optimization_recommendations": {
"immediate": [
"Add database index on transactions.user_id",
"Implement cache TTL for redis-cache-service",
"Optimize processPayment() cryptographic operations"
],
"short_term": [
"Implement connection pooling for database",
"Add query caching for frequent queries",
"Batch database writes where possible"
],
"long_term": [
"Implement read replicas for database",
"Add CDN for static assets",
"Implement circuit breakers for external services"
]
},
"performance_baseline": {
"cpu_usage_target": 70,
"memory_usage_target": 80,
"api_p95_latency_target": 200,
"database_query_time_target": 100,
"cache_hit_rate_target": 90
},
"next_steps": [
{
"action": "Implement database index",
"estimate_hours": 2,
"priority": "high"
},
{
"action": "Fix memory leak in cache service",
"estimate_hours": 4,
"priority": "high"
},
{
"action": "Optimize payment processor CPU usage",
"estimate_hours": 8,
"priority": "medium"
}
]
}
性能仪表板:
Performance Dashboard
────────────────────
Status: ACTIVE
Last Update: 2026-02-26 19:45:00
Update Interval: 1 second
Real-time Metrics:
┌────────────────────┬────────────┬────────────┬────────────┐
│ Metric │ Current │ 1min Avg │ Trend │
├────────────────────┼────────────┼────────────┼────────────┤
│ CPU Usage │ 65% │ 62% │ ↗️ Rising │
│ Memory Usage │ 72% │ 71% │ → Stable │
│ API Latency (p95) │ 320ms │ 310ms ↗️ Rising │
│ Database Latency │ 85ms │ 82ms → Stable │
│ Cache Hit Rate │ 92% │ 91% ↘️ Falling │
│ Error Rate │ 0.2% │ 0.3% ↘️ Falling │
└────────────────────┴────────────┴────────────┴────────────┘
Alerts:
• ⚠️ API p95 latency above threshold (200ms): 320ms
• ✅ CPU usage within limits
• ✅ Memory usage within limits
• ⚠️ Database connections approaching limit (85%)
Hotspots:
1. processPayment(): 35% CPU (🔥 Hot)
2. validateTransaction(): 22% CPU (⚠️ Warm)
3. updateDatabase(): 18% CPU (⚠️ Warm)
Resource Utilization Trend:
CPU: ████████████████████████████████████░░░░ 65%
Memory: ██████████████████████████████████████░░ 72%
Disk: █████████████████████░░░░░░░░░░░░░░░░░░░ 45%
Network:████████████████░░░░░░░░░░░░░░░░░░░░░░░░ 38%
Recent Events:
• 19:40: Database query slowdown detected
• 19:35: Cache miss rate increased by 15%
• 19:30: API latency spike (p95: 450ms)
• 19:25: Memory usage increased by 2%
Recommendations:
1. Add index on transactions.user_id (pending)
2. Implement cache TTL (in progress)
3. Optimize payment processor (planned)
Performance Score: 72/100
Status: Needs Improvement
注意事项
- 在类似生产环境中进行性能分析,以获得准确结果
- 使用恰当的采样率,平衡开销与准确性
- 与基线进行比较,以识别性能回退
- 监控性能分析开销,避免影响生产性能
- 使用火焰图直观识别性能瓶颈
- 结合使用多种工具,进行全面分析
- 对符合生产环境使用情况的代表性工作负载进行性能分析
- 考虑在生产环境中进行性能分析的安全影响
- 记录性能分析方法,以确保结果可复现
- 在 CI/CD 流水线中自动化性能回归测试
评论
支持 Markdown