性能调优实战：数据库索引、JVM 参数、日志分析与瓶颈定位

1
2
3
4
5

1. 先测量，再优化（没有度量就没有改进）
2. 先找瓶颈，再对症下药
3. 一次只改一个变量
4. 改后验证，保留回退方案
5. 持续监控，不要一劳永逸

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

性能问题排查流程：
┌─────────────────────────────────────────┐
│ 1. 确认问题现象                          │
│    - 慢在哪里？（查询/页面/导入/导出）   │
│    - 什么时候慢？（高峰/特定操作）       │
│    - 影响范围？（全部用户/部分用户）     │
├─────────────────────────────────────────┤
│ 2. 收集性能数据                          │
│    - 系统监控（CPU/内存/磁盘/网络）      │
│    - 数据库监控（慢查询/锁等待）         │
│    - JVM 监控（GC 频率/堆内存）          │
│    - 应用日志（响应时间/错误率）         │
├─────────────────────────────────────────┤
│ 3. 定位瓶颈                              │
│    - CPU 瓶颈 → 算法优化/索引优化        │
│    - 内存瓶颈 → JVM 调优/缓存优化        │
│    - IO 瓶颈 → 存储优化/异步处理         │
│    - 网络瓶颈 → 压缩/缓存/CDN            │
├─────────────────────────────────────────┤
│ 4. 实施优化                              │
│    - 数据库层                            │
│    - 应用层                              │
│    - 网络层                              │
│    - 客户端层                            │
├─────────────────────────────────────────┤
│ 5. 验证效果                              │
│    - 对比优化前后指标                    │
│    - 确认无副作用                        │
│    - 记录优化方案                        │
└─────────────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

-- 开启慢查询日志（>2 秒的查询）
ALTER SYSTEM SET timed_statistics = TRUE;
ALTER SYSTEM SET sql_trace = TRUE;
ALTER SYSTEM SET max_dump_file_size = UNLIMITED;

-- 查找最慢的 SQL
SELECT sql_id, elapsed_time, executions,
       elapsed_time / NULLIF(executions, 0) as avg_time,
       sql_text
FROM v$sql
WHERE elapsed_time > 2000000  -- 2 秒
ORDER BY elapsed_time DESC
FETCH FIRST 20 ROWS ONLY;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

-- 开启慢查询日志
ALTER SYSTEM SET log_min_duration_statement = 2000;
ALTER SYSTEM SET log_statement = 'none';
SELECT pg_reload_conf();

-- 查看最慢查询
SELECT query, calls, total_time, mean_time, rows
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 20;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

-- Oracle：全表扫描的 SQL
SELECT sql_text, disk_reads, executions
FROM v$sql
WHERE sql_text LIKE '%FROM PITEM%'
  AND disk_reads > 1000
ORDER BY disk_reads DESC;

-- PostgreSQL：未使用索引的查询
SELECT relname, seq_scan, seq_tup_read,
       idx_scan, idx_tup_fetch
FROM pg_stat_user_tables
WHERE seq_scan > 0
ORDER BY seq_tup_read DESC
LIMIT 20;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

-- 常用查询字段索引
CREATE INDEX idx_item_object_string ON PITEM(object_string);
CREATE INDEX idx_item_last_mod ON PITEM(last_mod_date);
CREATE INDEX idx_item_release_status ON PITEM(release_status);

-- 组合索引（按查询频率排序）
CREATE INDEX idx_item_status_date ON PITEM(release_status, last_mod_date);

-- 唯一索引
CREATE UNIQUE INDEX idx_item_id_unique ON PITEM(item_id);

-- 注意：索引会增加写入成本，需权衡

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

-- Oracle：重建索引
ALTER INDEX idx_item_object_string REBUILD;

-- PostgreSQL：重建索引
REINDEX INDEX idx_item_object_string;

-- 分析统计信息
-- Oracle
EXEC DBMS_STATS.GATHER_TABLE_STATS('TC', 'PITEM');

-- PostgreSQL
ANALYZE PITEM;

1
2
3

-- 慢：全表扫描
SELECT * FROM PITEM
WHERE UPPER(object_string) LIKE '%电机%';

1
2
3
4
5
6

-- 快：使用前缀匹配
SELECT * FROM PITEM
WHERE object_string LIKE '电机%';

-- 或者创建函数索引
CREATE INDEX idx_item_string_upper ON PITEM(UPPER(object_string));

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

-- 慢：OFFSET 在大数据量时效率低
SELECT * FROM PITEM
ORDER BY last_mod_date DESC
OFFSET 10000 LIMIT 50;

-- 快：使用游标分页
SELECT * FROM PITEM
WHERE last_mod_date < '2026-06-01'
ORDER BY last_mod_date DESC
LIMIT 50;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

-- 增大 SGA
ALTER SYSTEM SET sga_target = 8G SCOPE=SPFILE;
ALTER SYSTEM SET pga_aggregate_target = 4G SCOPE=SPFILE;

-- 调整连接池
ALTER SYSTEM SET processes = 500 SCOPE=SPFILE;

-- 重启生效
SHUTDOWN IMMEDIATE;
STARTUP;

1
2
3
4
5
6

# postgresql.conf
shared_buffers = 4GB          # 约 25% 总内存
effective_cache_size = 12GB   # 约 75% 总内存
work_mem = 64MB               # 排序/哈希内存
maintenance_work_mem = 1GB    # 维护操作内存
max_connections = 200         # 最大连接数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

JVM 内存布局：
├── Heap（堆）
│   ├── Young Generation（年轻代）
│   │   ├── Eden（伊甸区）
│   │   ├── Survivor 0
│   │   └── Survivor 1
│   └── Old Generation（老年代）
├── Metaspace（元空间）
├── Thread Stack（线程栈）
└── Direct Buffer（直接缓冲）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# tc_profilevars.bat / tc_profilevars.sh

# 堆内存（根据服务器配置调整）
set JAVA_OPTS=%JAVA_OPTS% -Xms4g -Xmx8g

# 年轻代比例（默认 1:2，建议 1:3）
set JAVA_OPTS=%JAVA_OPTS% -XX:NewRatio=3

# Metaspace
set JAVA_OPTS=%JAVA_OPTS% -XX:MetaspaceSize=256m
set JAVA_OPTS=%JAVA_OPTS% -XX:MaxMetaspaceSize=512m

# GC 选择
# G1 GC（推荐，Java 11+）
set JAVA_OPTS=%JAVA_OPTS% -XX:+UseG1GC
set JAVA_OPTS=%JAVA_OPTS% -XX:MaxGCPauseMillis=200

# GC 日志
set JAVA_OPTS=%JAVA_OPTS% -Xlog:gc*:file=logs/gc.log:time,uptime,level,tags:filecount=5,filesize=10m

# 其他优化
set JAVA_OPTS=%JAVA_OPTS% -XX:+HeapDumpOnOutOfMemoryError
set JAVA_OPTS=%JAVA_OPTS% -XX:HeapDumpPath=logs/
set JAVA_OPTS=%JAVA_OPTS% -XX:+UseStringDeduplication
set JAVA_OPTS=%JAVA_OPTS% -XX:+UseCompressedOops

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 最大暂停时间
-XX:MaxGCPauseMillis=200

# 堆占用比例
-XX:G1HeapWastePercent=5

# 年轻代大小范围
-XX:G1NewSizePercent=20
-XX:G1MaxNewSizePercent=60

# 并发标记线程数
-XX:ConcGCThreads=4

1
2
3
4
5
6

# 使用 GCViewer 或 GCeasy 分析 gc.log
# 关注指标：
# - 平均暂停时间（应 < 200ms）
# - 最大暂停时间（应 < 500ms）
# - GC 频率（应 < 1 次/分钟）
# - 堆使用率（应 < 80%）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 线程栈大小
-Xss1m  # 默认 1MB，可根据需求调整

# 最大线程数
# Linux: ulimit -u
# Windows: 受限于系统资源

# 线程池配置（Tomcat）
# server.xml
<Executor name="tomcatThreadPool"
          namePrefix="catalina-exec-"
          maxThreads="200"
          minSpareThreads="25"
          maxQueueSize="100"/>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

日志文件位置：
├── TC_ROOT/logs/
│   ├── tc_server.log          # 服务器主日志
│   ├── tc_rac.log             # RAC 客户端日志
│   ├── fms.log                # FMS 日志
│   └── j2eeserver/
│       └── catalina.out       # Tomcat 日志
├── TC_DATA/logs/
│   └── syslog                 # 系统日志
└── 数据库日志
    └── (见各数据库文档)

1
2
3
4
5
6
7
8

# 实时查看错误日志
tail -f tc_server.log | grep -E "ERROR|WARN|Exception"

# 统计错误频率
grep -c "ERROR" tc_server.log

# 查找特定时间段的错误
awk '/2026-06-12 10:00/,/2026-06-12 11:00/' tc_server.log | grep ERROR

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#!/bin/bash
# analyze_tc_logs.sh
LOG_FILE="tc_server.log"

echo "=== Teamcenter 日志分析 ==="
echo ""

echo "总行数: $(wc -l < $LOG_FILE)"
echo "错误数: $(grep -c 'ERROR' $LOG_FILE)"
echo "警告数: $(grep -c 'WARN' $LOG_FILE)"
echo ""

echo "错误类型分布:"
grep 'ERROR' $LOG_FILE | \
  grep -oE '[A-Z][a-zA-Z]*Exception' | \
  sort | uniq -c | sort -rn | head -10

echo ""
echo "慢请求 TOP 10:"
grep 'response time' $LOG_FILE | \
  grep -oE '[0-9]+ms' | \
  sed 's/ms//' | \
  sort -rn | head -10

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

<!-- logback.xml -->
<appender name="PERF" class="ch.qos.logback.core.FileAppender">
  <file>logs/performance.log</file>
  <encoder>
    <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %msg%n</pattern>
  </encoder>
</appender>

<logger name="com.teamcenter.performance" level="DEBUG">
  <appender-ref ref="PERF"/>
</logger>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 查找高 CPU 进程
top -c

# 查找高 CPU 线程
top -H -p <PID>

# Java 线程分析
jstack <PID> > jstack.txt
# 将 top 中的线程 ID 转为 16 进制
printf "%x\n" <TID>
# 在 jstack.txt 中搜索该线程

1
2
3
4
5
6
7
8
9

# 堆内存快照
jmap -dump:live,format=b,file=heap.hprof <PID>

# 分析堆快照
jhat heap.hprof
# 或使用 Eclipse MAT

# 实时内存监控
jstat -gcutil <PID> 1000 10

1
2
3
4
5
6
7
8

# 磁盘 IO
iostat -x 1 10

# 查找高 IO 进程
iotop

# 文件系统缓存
free -h

1
2
3
4
5
6
7
8

# 网络连接状态
netstat -an | grep :7001 | awk '{print $6}' | sort | uniq -c

# 网络延迟
ping -c 100 <server_ip>

# TCP 连接数
ss -s

1
2
3
4
5
6

推荐工具：
├── Prometheus + Grafana（系统监控）
├── JMX Exporter（JVM 监控）
├── pg_stat_statements（PostgreSQL）
├── Oracle Enterprise Manager
└── ELK Stack（日志分析）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
  "dashboard": {
    "title": "Teamcenter 性能监控",
    "panels": [
      {
        "title": "CPU 使用率",
        "targets": [{"expr": "process_cpu_seconds_total"}]
      },
      {
        "title": "JVM 堆内存",
        "targets": [{"expr": "jvm_memory_bytes_used{area=\"heap\"}"}]
      },
      {
        "title": "GC 暂停时间",
        "targets": [{"expr": "rate(jvm_gc_pause_seconds_sum[5m])"}]
      },
      {
        "title": "数据库连接数",
        "targets": [{"expr": "jdbc_connections_active"}]
      }
    ]
  }
}

1
2
3
4
5
6
7

问题：BOM 展开查询耗时 30s+
分析：执行计划显示全表扫描
解决：
  1. 为 BOMLine 的父项 ID 添加索引
  2. 优化查询条件，减少关联层数
  3. 启用查询结果缓存
结果：查询时间降至 0.5s

1
2
3
4
5
6
7
8

问题：每小时 2-3 次 Full GC，每次暂停 5s+
分析：堆内存不足，老年代占满
解决：
  1. 增大堆内存从 4GB 到 8GB
  2. 调整 NewRatio 从 2 到 3
  3. 启用 G1 GC
  4. 排查内存泄漏（发现未关闭的数据库连接）
结果：Full GC 频率降至每天 1 次，暂停 < 1s

1
2
3
4
5
6
7
8

问题：大文件（>100MB）上传/下载超时
分析：FMS 带宽不足，单线程传输
解决：
  1. 增加 FMS 服务器数量（负载均衡）
  2. 调整 FCC 缓存大小
  3. 优化网络带宽（千兆→万兆）
  4. 启用 FMS 压缩传输
结果：传输速度从 5MB/s 提升至 50MB/s