前言

任何综合性的信息系统的部署实施都是以满足业务需求、提高作业效率为初衷，但随着系统升级扩容和使用年限的推移，系统的操作效率却呈逐年衰减的状态，甚至影响到用户的正常使用，PLM系统更是如此。

Teamcenter PLM系统不仅要管理各类业务对象元数据、主数据，还要管理大量的结构化数据、关系、实体文件（模型、图纸、技术文档等）和流程，以及几乎所有数据的历史记录或版本，这一点不同于传统ERP之类的纯粹数据库型的应用系统。作为一个覆盖了多种业务领域数据管理和流程管理需求的大型信息系统，Teamcenter具有复杂的系统设计，系统资源状态不佳将明显影响系统性能。

从Teamcenter系统部署架构看，Teamcenter采用了四层结构。西门子为系统提供了极大的部署灵活性。但是现实情况往往是受限于实施团队的经验不足、企业IT基础架构的知识不足，导致实施团队对Teamcenter部署方案的理解、选择和应用，存在不合理性，而不合理的方案可能对最终交付的作业系统性能也会造成明显影响。

正是由于Teamcenter系统的复杂度和部署方案的多样化，当作业系统出现系统性能问题时，需要经验丰富的专业调优顾问进行全方面排查，以确定合理的优化目标和调优方案。

 

1.Teamcenter系统性能不佳的受害者

Teamcenter系统运行性能不佳时，有三种角色的企业人员会成为“受害者”。

 

· Teamcenter系统运维部门

· Teamcenter系统的最终用户

· 企业高层管理层

 

Teamcenter系统运维部门

作为Teamcenter系统保驾护航的部门，运维团队时常因为系统运行的卡顿、闪退等问题遭受最终用户的质疑和挑战。而Teamcenter系统运行的卡顿、闪退等问题是专业性非常强的技术问题，需要从多维度去分析问题的根源性因素，这对于大部分Teamcenter系统运维部门来讲是很难独立解决的。

 

Teamcenter系统的最终用户

Teamcenter系统的最终用户是系统性能不佳的直接受害者，系统构建之初半小时可以完成的工作，现在需要一、两个小时才能完成，甚至要面对系统闪退造成的数据丢失的无奈。原本可以朝九晚五的节奏，因系统操作性能不佳，不得不通过加班来赶进度，整个人的生活节奏都被打乱了。

 

企业高层管理层

公司高层管理者（老板或研发高层管理人员）发现随着Teamcenter系统使用年限的拉长，研发部门的工作效率变低了，原本计划三天完成的协同开发，因系统运行效率的影响需要五天才能完成，甚至受到来自客户方的交付压力，一定程度上会影响公司业务的发展。

2.关于PLM交付系统的认知误区

从企业的角度看，可能存在对系统实施认知上的误区，即认为实施商交付的系统就是性能最优的系统。这可能对，也可能不对，答案在于实施身本身的专业能力， 在系统安装调试及最终交付时，对系统设置是否做了必要的优化调整，以保证初始交付系统的运行性能达成用户常态使用的预期。

但即便是遇到了专业的团队和专业的服务，大部分的系统在构建之初，无论是企业还是实施商都很难预见未来几年后的用户规模、数据量和使用场景的增长变化，也无法对未来可能出现的问题做全面的预判和智能化的应对调整，特别是企业规模快速成长， 产品数据爆发性增加的优秀企业。 只有适时对Teamcenter系统整体架构做全面的诊断和优化处理，才能确保PLM系统性能的平稳运行。

PLM系统性能优化不是PLM系统功能优化，这是两个属于不同维度的服务项目。PLM系统性能优化不仅需要高水准的PLM实施顾问， 还需要实施顾问和系统专家一起从系统资源全局思维的高度看待影响系统操作性能的复杂因素。

3.基于四层架构性能瓶颈分析

目前，大部分Teamcenter系统部署采用四层架构，即：用户层、Web层、Teamcenter应用层、资源层（数据库服务端和文件服务端），每个环节都有可能成为制约系统性能的瓶颈节点。

 

· 数据库服务器端

  数据库服务器端，需要关注CPU处理能力，内存利用率和I/O读写效率，数据库等待事件分析等。

· Teamcenter应用端

  Teamcenter应用端，需要考虑的是内存的大小及并发用户的数量。

  优化Teamcenter应用端，需要跟踪内存的使用效率。用户数到了一定规模，Teamcenter应用服务器需要做相应的应用集群。

· Web层

  Web层提供客户端与Teamcenter应用端握手进程，用户数多了，Web服务器需要做集群处理。

· 用户层

  客户端的优化，主要看每个企业的应用特点。比如，有的注重大型数模渲染，有的注重大规模BOM处理，需要从不同方面进行优化。

· Teamcenter文件服务器

  Teamcenter文件服务器存放大量的设计文档和图形文档，与Teamcenter客户端的操作休戚相关，并且实体文件量的增长也是最为迅速的。

  图文档的访问效率，受文件数的多少影响。

  解决图文档的访问效率问题，要选择合适的存储介质和Raid格式，同时要控制文档数量。

· 网络

  Teamcenter系统性能与网络组建方式也有很大关系。网络是数据流转的通道，采用合理的网络架构和硬件规格对系统性能有直接影响。

 

因此，Teamcenter系统优化，不是靠优化单一环节可以改善性能的。需要从系统构成的六个核心环节着手，确定关键瓶颈点和瓶颈要素。

4.数据说话的优化效果

Teamcenter系统的性能优化，以实际数据为依据，通过优化前后的数据对比，可以清晰地呈现优化的效果，并得到用户实际操作体验的验证。以下是UDS某企业客户的Teamcenter系统在经过专业团队的系统优化服务前后的部分实际数据对比。

· 数据库服务器端优化效果呈现

优化之前，数据库服务器的CPU利用率平均70%，%busy、%iowait和%user偏高，尤其%iowait对性能的影响尤为显著。

优化之后，数据库服务器的CPU利用率降至平均8%，%busy、%iowait和%user趋于合理。

 

· 磁盘访问优化效果呈现

经过对数据库对象的访问模式的调整，把工作时段原本100%的磁盘繁忙度降到20%以下，提高了系统响应效率。

当磁盘处于100%繁忙状态时，意味着客户端所有的操作在数据库服务器上都需要做I/O处理的排队，在数据获取操作的过程中，存在长时间等待。用户的直接体验就是获取数据需要长时间的等待。

优化之后，磁盘的繁忙度降到20%以下，并且是脉冲性的I/O繁忙，即磁盘交互性操作可以瞬间完成。磁盘的访问不再成为制约性能的瓶颈。

 

· 部分特征操作优化前后效果对比

 

通过对比部分用户特征操作在优化前后的效率，可以直观反映系统性能提升和用户体验的改善。例如登录Teamcenter、大型装配检入并生成JT、BOM展开、历史图纸查询、零部件引用关系查询，都得到了明显改善。

5.关于系统运行性能优化的投资回报

工程技术人员使用系统的工作效能提升，不再因系统慢遭受来自市场、工厂等内部协同部门对产出物时效性的质疑和挑战。

IT部门可以减少对为了满足系统运行性能而对新硬件和网络的投资

运维团队可以降低对系统运维的需求和人员负担

对于PLM系统的大宗投资的回报得到保证

 

 

结束语

我们从过往众多Teamcenter系统性能优化案例的实践经验回看，经过专家团队提供的系统性能调优专项服务一个周期后，用户系统性能均得到了明显改善，工作效率得到显著提高。当然用户系统性能的改善程度，还要取决于客户可以投入的系统资源配置和应用特性。

当系统的操作用户操作流畅度好了，系统应用得到更好推广，企业投资得到保护，也有助于企业继续规划和推进Teamcenter后期应用项目。