plm服务器 硬件性能,如何对PLM系统进行性能诊断与调优？

原标题：如何对PLM系统进行性能诊断与调优？

PLM系统是企业最重要的信息系统之一，尤其对于研发人员，PLM系统更是日常工作中非常重要的一环。随着时间的推移，企业对PLM系统的相关应用越来越深入，一方面系统中的数据量急剧增长，另一方面研发人员工作中对于PLM系统的依赖性越来越大。所以，提升PLM系统的性能就是节约研发人员的宝贵时间。

Teamcenter作为业界领先的PLM系统，提供了相关的工具与参数供性能诊断与优化使用，但是工具如何结合企业实际业务与系统环境，并配合相应的性能诊断与优化方法，达到定位性能问题，最终解决性能问题才是调优工作成功与否的决定因素。

1

分析与定位性能问题

要解决Teamcenter的性能问题，不能完全照搬其他运行顺畅的系统的参数直接大刀阔斧的上手进行调整，而是需要结合企业实际的业务与系统环境进行。因为每一个系统的业务与数据都不相同，应用的功能也是千差万别，直接照搬肯定会出现“水土不服”，造成性能无法提升，甚至可能由于参数调整的不合理，造成系统宕机等严重后果。所以在系统调优之前一定要进行相应的系统与业务情况访谈，建议系统性能诊断与优化的流程如下：

图1 系统诊断与优化流程

业务访谈分为最终用户访谈与IT管理员的访谈。最终用户访谈主要需要调研最终用户在应用的过程中对系统哪些业务场景使用频率较高，哪些业务场景性能较差。IT管理员访谈主要对系统整体可能对性能造成影响的数据数量级进行访谈，分析出相应的性能参考值，以便后续对系统进行整体评估。常见的业务访谈问题如下：

图2 业务访谈问题

根据最终用户访谈，根据用户描述或操作定制重现步骤，并制定一个业务重要程度(性能影响大)与功能调优难度的四象限图，以便后面制定调优范围与计划。因为有一些功能虽然存在性能存在瓶颈，但是可能使用的频度非常的低，类似这种问题就可以将优先级放低，以保障花最多的精力解决最重要的问题。下图是一个常见的调优四象限图示例：

图3 调优工作四象限

众所周知，Teamcenter采用的是分层架构，按照连接方式的不同分为两层架构与四层架构。结合以往的经验，并根据分层架构的特点，总结出常见的Teamcenter问题区域定位方式，可以通过不同层之间的性能存在问题定位到对应的性能瓶颈。

图4 Teamcenter架构与问题区域定位方法

对于性能的诊断不光需要感性的判断，同时还需要使用专业的工具进行检测，通过工具的检测主要包括网络的检测、数据库的检测、Teamcenter自身的检测以及服务器操作系统的检测。

网络的检测主要需要检测以下几个指标：

●网络通信延时情况。

●数据包组成结构分析(是否有大量的小于511的数据包影响网络传输效率)。

●TCP通信相应情况(慢应答、数据重传)。

●Teamcenter服务器是否接入核心网络。

数据库的检测主要需要检测以下几个指标：

●数据库SQL语句的执行效率。

●数据库游标缓存数量。

●数据库会话连接数。

●数据库索引是否合理建立。

Teamcenter自身的检测主要检测以下几个指标：

●典型操作场景执行时间(登陆、展开BOM、查询等)。

●用户反馈速度较慢的场景执行时间(特别是二次开发的功能)。

●后台日志输出监控。

操作系统的检测主要需要检测以下几个指标：

●高峰时期系统的资源占用情况(CPU、内存)。

●系统I/O情况，是否有阻塞等。

●系统等待时间检测。

通过上述的检测可以诊断出类似如下的性能瓶颈：

网络架构不合理造成网络瓶颈。

数据库相关参数不合理造成性能瓶颈。

Teamcenter整体性能是否在合理区间。

硬件无法符合造成系统整体性能瓶颈。

特定二次开发的功能操作较慢，可能是代码存在问题造成性能瓶颈。

操作系统参数不合理造成系统性能瓶颈。

2

性能优化解决思路

利用NX建模，实现了大轮拖驾驶室及底盘零件在Techviz立体可视化系统中进行产品样机的评审与交互。通过诊断我们找出了造成系统问题的相关瓶颈，接下来就需要针对已有症状与推断出的瓶颈制定解决性能问题的思路。

首先针对网络问题，我们建议采取如下优化思路：

1.将Teamcenter服务器接入核心层网络，提高Teamcenter网络通信效率。

2.建立企业软件白名单库，屏蔽一些使用广播造成网络拥塞的小软件。

3.提升网络带宽，尽量使研发人员的网络达到百兆到桌面以上。

针对数据库的参数不合理建议采用如下优化思路：

1.优化共享池与资源池参数，提高数据库的内存利用率。

2.数据库启用动态内存管理。

3.调整相应的游标缓存参数。

4.将常用的数据库小表放入内存中，提高基础操作性能。

图5 数据库常用小表放入内存

针对操作系统参数的不合理采用如下优化思路：

1.调整VMO参数，优化内存结构。

2.对操作系统与存储系统逻辑卷的不合理划分进行重构。

3.操作系统上对ORACLE启用大页面。

针对特定的二次开发功能操作慢的问题，采取如下的二次开发代码优化思路：

二次开发代码的优化方式分为时间复杂度分析、API是否优选、代码结构是否最优、隐患排查等几个方面。

图6 二次开发代码优化思路

时间复杂度分析：

分析代码的时间复杂度主要涉及算法中的时间复杂度，最终的分析要理论结合实际。比如：A算法有两层循环(时间复杂度n)，而B算法只有一层循环+若干操作(时间复杂度1)。这并不能说明B算法比A算法优，因为A算法在业务上可能n始终小于2，此时就需要分析加实验，根据多次实验结果进行选择。

API是否优选：

某些情况下，同一种功能可以通过不同的API进行具体实现，但是API可能内部有一些是通过遍历，而另一些可能是精确查找得出结果，此时就需要进行API的优选。

代码结构是否最优：

代码结构的优选是在代码实现的功能相同的情况下，对代码的结构进行优选。比如代码中的某一段先行执行，执行的结果可能在后面得到使用，则此时需要提升代码段到前面防止多次读取。

隐患排查：

隐患排查是需要排查代码中未考虑到，也不会马上产生恶劣效果的部分。比如内存释放的排查，内存释放未执行可能造成内存泄漏，用户在刚开始使用时并不会马上体现出来，但在使用一段时间后就可能造成一些性能影响。

3

性能优化实施

性能优化的实施由于是在生产系统上直接进行调整，具有较大的风险，所以在进行性能优化的实施前需要制定完整的实施计划、备份与回退策略。

调优准备阶段进行相应的系统备份是保证调优工作安全平稳进行的基础。对于系统备份建议分如下几部分进行：

图7 系统备份策略

数据库备份：数据库备份包括数据库全局备份与Teamcenter数据库实例备份。

文件服务器备份：文件服务器备份包括对Teamcenter的Volume进行备份，同时还包括对服务器的TCData目录备份。Volume用于存放Teamcenter系统中的相应图文档文件等，TCData用于存档相应的系统环境变量的信息。

操作系统备份：操作系统备份包括对AIX服务器上的操作系统进行备份，其中重点对一些配置文件进行备份。

调优参数记录：首先需要将一个调优周期内要调整的所有参数记录到一张Excel表中，将初始值放入表格中，每一次调整都要写上调整值与调整时间。如下表所示：

表1 调优参数记录

当调优参数未起作用或引起负面效果后，需要对受影响部分进行回退操作。回退方式分为参数回调、系统局部还原、系统整体还原。对整个环境的影响是系统整体还原>系统局部还原>参数回调。所以我们建议能使用参数回调解决的，就不要使用系统局部回调，能使用系统局部回调解决的，就不要使用系统整体还原。根据调优的常见情况，在调优前需要制定类似表2的回退策略表：

最后需要针对每一调优项按照时间顺序制定调优计划，并根据计划在测试机上进行一次完整的演练。

表2 回退策略表

系统调优采用的是迭代调整方式。因为参数的调整要结合实际的情况，大多数时候无法做到一步到位，对于某些参数最好也是适当的增加上去，起到降低风险的作用。具体的调优流程图如下：

图8 调优实施流程

4

性能优化效果检测

系统性能的最终结果需要反馈到数据上，通过与调优之前对应操作的数据进行比对，可以得出最终性能优化的效果，下面是在某企业中经过两次调优并增加内存后的结果：

1.系统基础操作性能得到提升，指标如下：

●展开Item性能提升79.8%。

●展开文件夹性能提升44.5%。

2.BOM相关操作性能提升，指标如下：

●发送一个较小的BOM到PSE的性能提升35.6%。

●展开同一个中小型BOM的性能提升30%。

3.登陆调优后两层客户端有一定提升，改为四层客户端后指标提升更为明显。

4.操作系统性能指标有较大提升：

●CPU的平均等待时间，由原来的31.5%降低到了20%，降幅达到36.5%。

●最高等待时间由原来的42%降低到了35.8%，降幅达到14.7。

●操作系统磁盘等待由80%左右降低到了1%以内。

●数据库表空间的磁盘的负荷由一块磁盘分摊到了4块磁盘上，I/O读写效率大幅提升。

5.通过优化二次开发代码，对业务部门抱怨最多的工艺模块性能提升明显：

表3 优化二次开发代码后工艺模块的性能提升幅度

5

总结

通过本文可以了解到，经过一系列的性能诊断，可以分析出造成Teamcenter性能问题的瓶颈。在条件允许的情况下根据适当的方法可以使Teamcenter的性能得到提升。在Teamcenter调优的实施过程中，一定要专业的团队根据环境进行特定分析并进行完整备份后进行，因为调优工作有较大的风险。同时由于不同的环境造成性能问题的原因各不相同，最终的调优效果肯定也会存在一定的差异。

END

责任编辑：