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

Fri, 12 Jun 2026 00:00:00 +0000

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

本文结合 Teamcenter 系统运维经验与 IMA 知识库中的性能优化资料编写。

Teamcenter 系统上线后，随着数据量增长和用户数增加，性能问题几乎是必然出现的。慢查询、页面卡顿、导入超时——这些问题的背后，往往不是单一原因，而是多个因素叠加的结果。

本文将从数据库调优、JVM 参数配置、日志分析和瓶颈定位四个维度，系统讲解 Teamcenter 性能调优的实战方法。

一、性能调优方法论

1.1 调优黄金法则

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

1.2 性能分析框架

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

二、数据库调优

2.1 慢查询分析

Oracle 慢查询日志：

-- 开启慢查询日志（>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;

PostgreSQL 慢查询：

-- 开启慢查询日志
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;

2.2 索引优化

查找缺失索引：

-- 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;

创建索引：

-- 常用查询字段索引
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);

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

索引维护：

-- 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;

2.3 查询优化

优化前：

1
2
3

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

优化后：

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

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

分页查询优化：

-- 慢：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;

2.4 数据库参数调优

Oracle：

-- 增大 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;

PostgreSQL：

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

三、JVM 参数调优

3.1 JVM 内存模型

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

3.2 Teamcenter JVM 推荐配置

# 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

3.3 GC 调优

G1 GC 关键参数：

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

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

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

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

GC 日志分析：

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

3.4 线程调优

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

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

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

四、日志分析

4.1 Teamcenter 日志体系

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

4.2 日志分析工具

实时日志监控：

# 实时查看错误日志
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

日志分析脚本：

#!/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

4.3 常见错误分析

错误	原因	解决
`OutOfMemoryError`	JVM 堆不足	增大 -Xmx
`ConnectionPoolExhausted`	数据库连接池满	增大连接池/优化慢查询
`LockWaitTimeout`	数据库锁等待	检查事务/减少锁竞争
`FMSDownloadFailed`	FMS 传输失败	检查 FMS 状态/网络
`AOM_SaveFailed`	保存失败	检查数据库/权限

4.4 性能日志配置

<!-- 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>

五、瓶颈定位实战

5.1 CPU 瓶颈

# 查找高 CPU 进程
top -c

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

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

5.2 内存瓶颈

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

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

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

5.3 IO 瓶颈

# 磁盘 IO
iostat -x 1 10

# 查找高 IO 进程
iotop

# 文件系统缓存
free -h

5.4 网络瓶颈

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

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

# TCP 连接数
ss -s

六、性能监控体系

6.1 监控指标

指标	正常范围	告警阈值
CPU 使用率	< 70%	> 85%
堆内存使用率	< 75%	> 85%
GC 暂停时间	< 200ms	> 500ms
数据库连接数	< 80% 上限	> 90% 上限
查询响应时间	< 2s	> 5s
FMS 传输速率	> 10MB/s	< 1MB/s

6.2 监控工具

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

6.3 Grafana 仪表盘示例

{
  "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"}]
      }
    ]
  }
}

七、调优案例

7.1 案例一：查询从 30s 降到 0.5s

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

7.2 案例二：JVM 频繁 Full GC

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

7.3 案例三：FMS 传输慢

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

八、总结

性能调优是一个系统工程，需要从多个维度入手：

数据库：索引优化、查询改写、参数调优
JVM：内存配置、GC 调优、线程管理
日志：监控分析、错误定位、性能追踪
监控：建立指标体系、设置告警阈值
流程：定期巡检、性能基线、持续优化

记住：性能调优不是一次性的工作，而是一个持续改进的过程。建立完善的监控体系，才能在问题出现时快速定位、及时解决。

JVM on 文艺技术笔记

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

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

一、性能调优方法论

1.1 调优黄金法则

1.2 性能分析框架

二、数据库调优

2.1 慢查询分析

2.2 索引优化

2.3 查询优化

2.4 数据库参数调优

三、JVM 参数调优

3.1 JVM 内存模型

3.2 Teamcenter JVM 推荐配置

3.3 GC 调优

3.4 线程调优

四、日志分析

4.1 Teamcenter 日志体系

4.2 日志分析工具

4.3 常见错误分析

4.4 性能日志配置

五、瓶颈定位实战

5.1 CPU 瓶颈

5.2 内存瓶颈

5.3 IO 瓶颈

5.4 网络瓶颈

六、性能监控体系

6.1 监控指标

6.2 监控工具

6.3 Grafana 仪表盘示例

七、调优案例

7.1 案例一：查询从 30s 降到 0.5s

7.2 案例二：JVM 频繁 Full GC

7.3 案例三：FMS 传输慢

八、总结