性能调优 on 文艺技术笔记

FMS 文件管理系统深度解析：缓存策略、SSL 部署与性能调优

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

FMS 文件管理系统深度解析：缓存策略、SSL 部署与性能调优

本文参考 IMA Teamcenter 知识库中的 Siemens 官方培训资料《Deploying FMS with SSL Enabled》（Francis Yu & Scott Dong, Advanced Technical Services）以及 Teamcenter 系统管理文档，结合实战经验编写。

Teamcenter File Management System（FMS）是 Teamcenter PLM 平台的核心子系统之一，负责管理所有工程文件的存储、传输、缓存和分发。无论是 CAD 模型、技术文档还是仿真数据，都通过 FMS 进行统一管理。本文将深入解析 FMS 的架构原理、缓存策略、SSL 安全部署以及性能调优实战。

一、FMS 架构概览

1.1 FMS 的三大核心组件

FMS 由三个关键组件构成：

组件	全称	职责
FSC	File Server Cache	文件服务器缓存，存储实际文件数据
FCC	File Client Cache	客户端文件缓存，本地缓存加速访问
TCCS	Teamcenter Client Cache Service	轻量级客户端缓存服务（RAC 4-Tier 架构下）

┌───────────────────────────────────────────────────┐
│                    Client Machine                  │
│  ┌─────────┐    ┌─────────┐    ┌───────────────┐  │
│  │  RAC    │───>│   FCC   │───>│   HTTP/HTTPS  │  │
│  │ Client  │    │  Cache  │    │   FSC Server  │  │
│  └─────────┘    └─────────┘    └───────────────┘  │
└───────────────────────────────────────────────────┘

1.2 FMS 工作流程

客户端请求文件 → FCC 检查本地缓存
缓存命中 → 直接从 FCC 返回文件
缓存未命中 → FCC 向 FSC 发起请求
FSC 查找文件 → 从 Volume Server 获取或从其他 FSC 复制
文件传输 → FSC 将文件发送给 FCC，同时缓存
客户端获取 → FCC 将文件返回给 RAC 客户端

二、fmsmaster.xml 核心配置

2.1 配置文件结构

fmsmaster.xml 是 FMS 的主配置文件，位于 FMS Home 目录下。核心结构如下：

<?xml version="1.0" encoding="UTF-8"?>
<fmsmaster>
  <!-- FSC 定义 -->
  <fsc id="FSC_server01" address="http://server01:4550" ismaster="true">
    <connection id="sslCon" protocol="https" port="4551" />
  </fsc>

  <!-- 客户端映射 -->
  <clientmap subnet="192.168.1.0" mask="255.255.255.0">
    <assignedfsc fscid="FSC_server01" connectionid="default" priority="0" />
  </clientmap>

  <!-- FSC 组内通信 -->
  <entryfsc fscid="FSC_server01" connectionid="default" priority="0" />
</fmsmaster>

2.2 关键配置项说明

配置项	说明	示例值
`fsc id`	FSC 唯一标识符	`FSC_server01`
`address`	FSC 服务地址	`http://server01:4550`
`ismaster`	是否为主 FMS	`true` / `false`
`connection id`	连接标识（用于 SSL）	`sslCon`
`protocol`	传输协议	`http` / `https`
`clientmap subnet`	客户端子网匹配	`192.168.1.0`
`assignedfsc priority`	连接优先级（0最高）	`0`

2.3 客户端映射策略

FMS 通过 clientmap 条目将客户端定向到最近的 FSC 服务器：

<!-- 精确 IP 匹配 -->
<clientmap subnet="10.0.1.100" mask="255.255.255.255">
  <assignedfsc fscid="FSC_local01" connectionid="sslCon" priority="0" />
  <assignedfsc fscid="FSC_backup01" connectionid="sslCon" priority="1" />
</clientmap>

<!-- 子网范围匹配 -->
<clientmap subnet="10.0.2.0" mask="255.255.255.0">
  <assignedfsc fscid="FSC_branch01" connectionid="default" priority="0" />
</clientmap>

<!-- 默认路由（兜底） -->
<clientmap subnet="0.0.0.0" mask="0.0.0.0">
  <assignedfsc fscid="FSC_master01" connectionid="sslCon" priority="0" />
</clientmap>

优先级规则：priority=0 为最高优先级，客户端会优先尝试优先级最高的 FSC。当高优先级 FSC 不可用时，自动降级到次优先级。

三、SSL 安全部署实战

3.1 为什么需要 SSL？

在生产环境中，FMS 传输的文件可能包含敏感的设计图纸、专利文档等。SSL（Secure Socket Layer，现称 TLS）提供端到端加密，防止数据在传输过程中被窃听或篡改。

3.2 SSL 连接握手流程

客户端                                    FSC 服务器
  │                                          │
  │  1. 请求服务器身份证明                    │
  │ ───────────────────────────────────────> │
  │                                          │
  │  2. 发送 SSL 证书副本                     │
  │ <─────────────────────────────────────── │
  │                                          │
  │  3. 验证证书（信任则继续）                │
  │ ───────────────────────────────────────> │
  │                                          │
  │  4. 发送数字签名确认                      │
  │ <─────────────────────────────────────── │
  │                                          │
  │  5. 开始加密数据传输                     │
  │ <══════════════════════════════════════> │

3.3 分步部署指南

Step 1：生成自签名证书

在 FMS Volume Server 上，使用 Java keytool 工具生成 keystore：

# 确保 java keytool 在 PATH 中
cd $FMS_HOME

# 生成 keystore（RSA 算法，有效期365天）
keytool -genkey -keystore keystore -keyalg RSA -alias FSC_myhost -validity 365

# 交互提示：
# 您的名字与姓氏是什么? → 输入服务器完整主机名 (FQDN)，如 server01.company.com
# 您的组织单位名称是什么? → ESC
# 您的组织名称是什么? → SPLM
# 您所在的城市或区域名称是什么? → Beijing
# 您所在的省/市/自治区名称是什么? → Beijing
# 该单位的双字母国家/地区代码是什么? → CN
# CN=server01.company.com, OU=ESC, O=SPLM, L=Beijing, ST=Beijing, C=CN 是否正确? → y

⚠️ 关键注意：证书的 “First and Last Name” 必须是服务器的 FQDN（完全限定域名），否则客户端验证将失败。

Step 2：配置 FMS 使用 keystore

# 复制属性模板
cd $FMS_HOME
cp fsc.properties.template fsc.FSC_myhostid.properties

# 编辑属性文件，添加以下配置：
cat >> fsc.FSC_myhostid.properties << 'EOF'
com.teamcenter.fms.servercache.keystore.file=keystore
com.teamcenter.fms.servercache.keystore.password=your_keystore_password
com.teamcenter.fms.servercache.keystore.ssl.certificate.password=your_cert_password
EOF

Step 3：在 fmsmaster.xml 中添加 SSL 连接

<fsc id="FSC_server01" address="http://server01:4550" ismaster="true">
  <!-- 添加 SSL 连接 -->
  <connection id="sslCon" protocol="https" port="4551" />
</fsc>

⚠️ 重要：添加 sslCon 后，必须重启 FMS 进程。执行 ./config/reload 不会加载新的 SSL 连接配置。

Step 4：验证 FMS SSL 启动

# Linux：检查 HTTPS 端口是否开放
netstat -nap | grep 4551
# 或使用 ss 命令
ss -tlnp | grep 4551

# Windows
netstat -an | findstr 4551

# 使用 telnet 测试连接
telnet server01.company.com 4551

# 如果端口关闭 → 配置有误，检查 fmsmaster.xml 和 keystore 密码
# 如果端口开放 → telnet 会挂起（正常行为，等待 SSL 握手）

Step 5：客户端证书配置

# 在 FMS 服务器上导出证书
cd $FMS_HOME
keytool -export -keystore keystore -alias FSC_server01 -file FSC_server01.cer

# 将证书文件复制到客户端的 JRE 安全目录
# Windows: %TC_ROOT%\install\install\jre\lib\security\
# Linux:   $TC_ROOT/install/install/jre/lib/security/

cd $TC_ROOT/install/install/jre/lib/security

# 备份原始 cacerts
cp cacerts cacerts.INIT

# 导入证书到 cacerts
keytool -import -trustcacerts -keystore cacerts -file FSC_server01.cer

# 输入 cacerts 密码（默认：changeit）
# 确认信任证书 → yes

Step 6：配置客户端 fcc.xml

<!-- 修改 FCC 的 fcc.xml 文件，将 http 改为 https -->
<!-- 修改前（非 SSL） -->
<parentfsc address="http://server01:4550/" priority="0" />

<!-- 修改后（SSL） -->
<parentfsc address="https://server01.company.com:4551/" priority="0" />

Step 7：更改首选项 FMS_BootStrap_Urls

在 Teamcenter 中修改首选项，使所有客户端通过 HTTPS 获取 FMS 配置：

1
2
3

首选项名称: FMS_BootStrap_Urls
旧值: http://server01:4550/tc/fms/
新值: https://server01.company.com:4551/tc/fms/

3.4 混合部署架构（HTTP + HTTPS）

在实际生产环境中，经常采用混合部署策略：

┌─────────────────────────────────────────────────────────────┐
│                    数据中心 A                                │
│                                                             │
│  ┌──────────┐    HTTP     ┌──────────┐                     │
│  │ FMS      │◄──────────►│ FSC A    │                     │
│  │ Master   │    (内部)   │          │                     │
│  │          │             │          │  HTTPS              │
│  └──────────┘    HTTP     │          │◄──────── 客户端     │
│                  ◄───────►│ FSC B    │                     │
│                           └──────────┘                     │
└─────────────────────────────────────────────────────────────┘
                            │
                        HTTPS（跨数据中心）
                            │
┌─────────────────────────────────────────────────────────────┐
│                    数据中心 B                                │
│                                                             │
│  ┌──────────┐    HTTP     ┌──────────┐                     │
│  │ FSC C    │◄──────────►│ FSC D    │                     │
│  │          │   (内部)    │          │                     │
│  └──────────┘             └──────────┘                     │
└─────────────────────────────────────────────────────────────┘

设计原则：

数据中心内部：FSC 之间使用 HTTP，节省 CPU 加解密开销
跨数据中心：使用 HTTPS 加密传输
客户端到 FSC：使用 HTTPS 保证安全性

四、FMS 缓存策略与调优

4.1 缓存层级

┌──────────────────────────────────────────────────┐
│                  L1: FCC 本地缓存                │
│                  位置: 客户端磁盘                 │
│                  速度: 最快                       │
├──────────────────────────────────────────────────┤
│                  L2: FSC 服务器缓存              │
│                  位置: 服务器磁盘/内存            │
│                  速度: 中等                       │
├──────────────────────────────────────────────────┤
│                  L3: Volume Server 存储          │
│                  位置: 网络存储/NAS/SAN           │
│                  速度: 最慢                       │
└──────────────────────────────────────────────────┘

4.2 缓存监控与统计

使用 fccstat 工具查看缓存状态：

1
2
3

# 在 FCC bin 目录下执行
cd $FCC_HOME/bin
./fccstat -status

输出示例：

Cache:
  segment: 1 files, 360448 bytes, 0 hits, 0 misses.
  read:    313 files, 98562662 bytes, 45 hits, 268 misses.
  write:   0 files, 0 bytes.
Clients:
  [客户端列表...]
Servers:
  [服务器列表...]
Assigned FSC 'https://server01.company.com:4551/tc/fms/...' is currently active.

关键指标解读：

hits：缓存命中次数（越高越好）
misses：缓存未命中次数
命中率 = hits / (hits + misses)，目标应 > 80%

4.3 缓存预热策略

对于大型装配体，可以预填充缓存以提升性能：

# 使用缓存预热工具
cd $FMS_HOME/bin
./fms_prepopulate -user=infodba -password=*** -site=site01

# 预热指定项目
./fms_prepopulate -user=infodba -password=*** \
  -items="part001/part002/part003" \
  -revisions="A/latest"

⚠️ 注意：缓存预热使用 HTTP 传输（即使配置了 SSL），因为预热通常发生在数据中心内部。

五、常见故障排查

5.1 SSL 连接失败静默问题

症状：客户端无法连接 FMS，但无明显错误提示。

根因：Java 客户端（FCC/FSC）如果证书颁发机构不在 cacerts 中，连接会静默失败。

排查方法：

# 1. 检查 FCC/FSC 日志
tail -f $FCC_HOME/log/fcc.log
tail -f $FMS_HOME/log/fsc.log

# 2. 启用 Java SSL 调试
export JAVA_OPTS="-Djavax.net.debug=ssl"
./startfcc

# 3. 验证证书是否正确导入
keytool -list -keystore $TC_ROOT/install/install/jre/lib/security/cacerts

5.2 证书过期问题

症状：FMS 突然停止工作，所有客户端连接失败。

排查：

# 检查证书有效期
keytool -list -v -keystore keystore -alias FSC_server01

# 输出示例：
# 有效期: Thu Jan 26 09:03:41 PST 2012 到 Fri Jan 25 09:03:41 PST 2013
# ⚠️ 如果当前日期超过有效期，连接将失败！

解决方案：重新生成证书并重新分发到所有客户端。

5.3 FMS 启动失败

# 检查 FMS 启动日志
tail -f $FMS_HOME/log/fms.log

# 常见原因：
# 1. keystore 密码错误
# 2. fmsmaster.xml 格式错误（XML 语法）
# 3. 端口被占用
# 4. Java 版本不兼容

六、WAN 加速器集成

6.1 与 WAN 加速器配合使用

FMS 可以与主流 WAN 加速器配合：

Cisco WAAS
Riverbed SteelHead

⚠️ 关键配置：

不要同时启用 FMS 自带的 WAN 加速（多流传输）和外部 WAN 加速器
不要启用 FMS 压缩功能（与 WAN 加速器的压缩冲突）

<!-- fmsmaster.xml 中关闭 FMS 压缩 -->
<fsc id="FSC_server01" address="https://server01:4551" ismaster="true">
  <connection id="sslCon" protocol="https" port="4551" compression="false" />
</fsc>

七、性能调优最佳实践

7.1 JVM 参数调优

FMS 基于 Java 运行，适当的 JVM 参数可显著提升性能：

1
2
3

# 在 fsc.properties 中添加
com.teamcenter.fms.jvm.options=-Xms2g -Xmx4g -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError

7.2 网络调优

# Linux 网络参数优化
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

7.3 存储优化

FSC 缓存目录应放在 SSD 或高速存储上
Volume Server 建议使用 SAN/NAS 存储
定期清理过期缓存文件

八、安全加固建议

使用 CA 签发的证书而非自签名证书（生产环境）
定期轮换证书（设置日历提醒，避免过期）
限制 FMS 端口访问（防火墙规则）
启用审计日志（记录所有文件传输操作）
定期备份 fmsmaster.xml 和 keystore 文件

九、总结

FMS 作为 Teamcenter 的文件管理核心，其稳定性直接影响用户体验。掌握以下关键要点：

领域	核心要点
配置	理解 fmsmaster.xml 结构，正确设置 clientmap 和 entryfsc
SSL	证书 FQDN 必须匹配，cacerts 必须导入，重启而非 reload
缓存	关注命中率，合理预热，定期清理
排障	启用 SSL 调试日志，检查端口，验证证书有效期
性能	JVM 调优、SSD 缓存、关闭冲突的压缩功能

参考资料：Siemens PLM Software — “Deploying FMS with SSL Enabled” (Francis Yu & Scott Dong, ATS, 2013)

性能调优实战：数据库索引、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 调优、线程管理
日志：监控分析、错误定位、性能追踪
监控：建立指标体系、设置告警阈值
流程：定期巡检、性能基线、持续优化

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