涨知识 | Teamcenter系统性能优化方法总结（诊断篇）- 大数跨境

天圣华信息

2021-12-30

物流技术装备的发展趋势

前言

Teamcenter作为世界上应用最广泛的主流的PLM平台之一，在国内也得到了广泛的实施部署，积累了大量的客户。但在Teamcenter系统上线使用过程中，随着客户企业业务的不断扩展、研发人员的不断加入、产品数据量的不断增加等，必然会对Teamcenter系统的运行效率、性能产生影响。为此，我们经常会收到这样的客户反馈：系统在某一时间段或持续出现运行变慢，系统性能正在逐步下降等情况发生，有些时候甚至影响到了正常业务的开展。此时，则需要考虑对系统进行全面的性能优化，本期重点介绍如何对系统性能瓶颈进行诊断。

物流技术装备的发展趋势

正文

当Teamcenter系统性能出现瓶颈时，其症状往往表现在以下几方面：

系统登录变慢，有时会弹出一些错误提示框。
BOM展开缓慢，完全展开BOM用时几分钟或更长时间。
可视化查看器视图加载缓慢。
客户端操作卡顿、界面频繁报错和弹框。
客户端经常卡死或异常退出。
报表输出时间过长。
客制化开发程序运行缓慢。

首先，我们可以利用排除法完成以下思考：

项目实施前期是否对Teamcenter系统的架构进行了合理的设计和规划，如果前期规划不到位，未考虑系统用户数量的激增和产品数据量的激增，都有可能导致原有系统架构无法满足现有业务的开展。
系统上线运行一段时间后，对它的各项使用、运维和管理做得不到位，主要表现在系统运行期间产生了大量的垃圾数据，这些数据未能得到及时的清理，另外系统的备份策略不合理，这会导致系统进程与备份进程同时争用硬件资源的情况发生。
硬件资源消耗过大，致使资源紧张不够用。Teamcenter系统对服务器的硬件CPU、内存和磁盘的占用还是非常大的，当服务器上的硬件资源消耗过大，要及时考虑扩容或增加硬件资源的数量。
突发网络安全事件，比如，增加了新的网络安全设备、配置了新的网络安全策略、安装了新的安全防护软件等情况，上述这些情况都会导致Teamcenter服务器运行变慢。
数据库对于客制化代码产生了大量的硬解析，Java端的数据库连接基本上是JDBC方式，由于java.sql.Statement类不支持绑定变量、游标重用和客户端语句缓存，需使用java.sql.PreparedStatement类重写相应代码。同时，也应尽可能的减少SQL语句的软解析，即，将创建和关闭预备语句的代码移到循环外。

物流技术装备的发展趋势

定位与诊断

上述思考只能给出Teamcenter系统性能优化的一个大致方向，但并不能快速和准确的定位问题。想要快速和高效的定位问题，并给出合理的解决办法，必须对Teamcenter系统的四层系统架构及其关键技术有一个更加深入的了解才行，下图是Teamcenter一种典型的四层架构图，假设每一层都运行在不同的主机上，则它们通过网络并分别利用HTTP、TCP/IP、J2EE、JDBC(ODBC)、FMS（文件管理系统）等技术实现客户端与各分布式应用服务器、数据库服务器、卷文件服务器之间的信息交互。

按照信息流交互方向从资源层到客户端层，我们归纳总结了以下性能问题的定位与诊断方法：

1、服务器操作系统诊断：因Linux、UNIX、AIX等服务器操作系统所使用的系统内核不同，则其内核参数也不尽相同，这些内核参数需要在安装Oracle或其他系统软件之前进行适当的调整，如果某些参数存在限制，则软件的整体性能将存在很大的问题。比如，Linux系统中的kernel.shmmax（单个共享内存段的最大值）、kernel.shmall（共享内存的总页数）、kernel.shmmni（共享内存段的最大数量）等参数都会在Oracle安装时进行最小值的检查，如果不满足参数的最小值，会造成Oracle无法正常安装。未来这些参数值的大小如何设定，还要根据服务器硬件配置情况进行合理的设定。另外服务器操作系统在软件用户权限、堆栈空间大小、依赖软件包等方面也都存在着诸多限制，所以这些都是服务器性能优化需要考虑的地方。

2、存储诊断：当前的存储空间划分是否满足软件数据存储需求，需要注意以下几点：

数据库和卷服务器的存储空间是否满足未来较长时间的使用需求；其I/O带宽及其性能是否满足需求；是否已经实施RAID，以便于在磁盘发生故障时能快速恢复数据。
数据库服务器是否采用归档模式，是否有足够的空间存储归档日志。如果按照每小时归档四次，一天8小时计算，每个日志大小约500MB，那么一天的归档日志就需要空间500*4*8=16000MB，那么现在的存储空间是否满足未来存储日志的需求。
当前的存储空间是否满足数据库、卷文件及各应用程序的备份策略。

3、数据库参数诊断：主要指数据库各项参数的诊断和调整，比如：Oracle的内存是手动管理，还是自动内存管理，采用手动管理时SGA各组件的大小设置是否合理，采用自动内存管理时，Oracle动态控制SGA、PGA的大小是否合适；数据库是否采用归档模式；REDO在线日志文件大小如何，是否造成日志切换和归档频繁，致使大量的I/O和等待事件产生，引起性能问题产生；临时表空间的大小是否正常；是否使用闪回恢复区（Flash Recovery Area）进行数据的备份和归档，如果是则需确保有足够的空间执行备份。控制文件、表空间文件、REDO在线日志文件、闪回恢复区等路径是否分散在不同的磁盘上，是否分散了数据库的I/O操作，避免出现I/O进程相互争用的情况。另外，有关数据库其他方面的优化还有很多，限于篇幅限制，此处不做过多介绍，如果大家感兴趣的话，可以关注我们后面的文章《Teamcenter系统性能优化方法总结（数据库篇）》。

4、FMS诊断：FMS是基于Java的文件管理系统，主要包含两部分功能组件：FSC在服务器端提供一个进程缓存文件，FCC在客户端提供一个进程缓存文件。根据服务器硬件资源的使用情况以及网络运行情况，适当的改变FSC和FCC相关参数的配置有助于提高文件上传和下载的速度，并最终改善Teamcenter的整体性能。比如，可通过修改服务传入请求的最大线程数（FSC_MaximumThreads）、读取缓存中的最大文件页数（FSC_MaximumReadCacheFilePages）、读缓存段的最大数目（FSC_MaximumReadCacheSegmentsl）等参数来改善FSC的运行效率。

5、tcserver优化：在Teamcenter客制化程度较高（自定义首选项、数据模型复杂、权限规则复杂、流程设置复杂、客制化代码逻辑复杂等）的情况下，经常发生TC系统内部错误，导致应用程序运行缓慢，甚至经常报错或异常退出，针对这类问题推荐使用以下工具进行诊断和定位问题：

通信监视器（Communication Monitor）：使用该工具可以查看客户端与服务器端的通信时间，是否存在大量的CALL，是否在某些CALL上消耗了大量的通讯时间。如果存在可以考虑改善网络环境，增加高速网络设备，调整网络设备的运行参数、改进服务器操作系统上的网络参数、数据库网络参数以及客户端操作系统的网络参数。该工具还可以检查出是否存在call counts量过高，并有大量的getProperty calls，如果存在可以帮助我们检查客制化属性是否在SOA（%tcdata%\soa\policies）中进行了定义。

JournalWorkbench：使用JournalWorkbench分析tcserver活动日志，JournalWorkbench是一个交互式程序，用于查看和分析性能日志文件中包含的性能数据。它可以加载表示单个进程性能信息的单个日志文件，也可以加载表示更复杂系统的单个用户会话中涉及的多个进程的性能信息的多个日志文件。JournalWorkbench还有一个“比较”模式，允许比较来自两个不同但可能相似的用户会话的日志信息。

利用该工具可以帮助我们完成以下分析：

按消耗的时间排名最高的功能。
按消耗的CPU排名最高的功能。
在tcserver内“CALL”频率最高的请求或者消耗CPU最高的请求，可能是瓶颈资源。
消耗资源最高的函数调用。
查看有多少时间花费在数据库的会话中。
数据库在tcserver中消耗资源最高的语句。
最高频率的SQL语句，他们的总累计时间、最大时间、平均时间，SQL的详细执行信息。

6、网络诊断：主要排查网络设备是否为高速设备、是否增加了新的安全防护软件，导致出现较高网络延时，网络协议是否出现以下问题：

服务器、网络设备对大字节数据包处理能力较低。
网络利用率低。
TCP通信协议出现故障。

当出现上述情况时可通过调整网络设备操作系统的MTU值进行解决。并规范网络应用，禁止使用局域网聊天工具，减少网络共享的使用频率。另外，可通过分别调整服务器、客户端操作系统的网络参数以及数据库的网络参数优化网络设备的运行效率。

7、WEB App诊断：主要是针对WEB中间件进行诊断，我们应用较多的WEB中间件是Weblogic。以Weblogic为例我们可以完成以下诊断任务：

太多或太少的垃圾回收可能会导致性能问题，这时需要调整Weblogic中的JVM的参数，让WEB服务器的垃圾回收处于一个正常的水平，从而提高中间件的运行效率。
Weblogic能够自动监测到当一个执行线程是否变为”阻塞”，变为”阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。为了避免Teamcenter系统中的大的耗时操作被Weblogic当做阻塞进程而停止响应，可以优化它的Stuck Thread max Time和Stuck Thread Timer Interval参数。
调优TCP连接缓存数，WebLogic用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时，这个值可能过小，日志中报Connection Refused,导致有效连接请求遭到拒绝，此时可以将Accept Backlog参数调大以提高性能。

8、客户端诊断：主要是对客户端硬件配置进行检查，避免因硬件配置不足造成客户端运行效率低下，比如，以下几点因素是造成客户端性能低下的主要原因：

显卡性能较差导致三维装配结构或模型加载非常慢，甚至出现某些三维模型失真的情况发生，使用CAD较为频繁的设计师遇到这种情况通常会认为是系统或软件出了问题，而实际情况是其显卡配置较低导致的。
普通客户机的硬件CPU、内存和磁盘与其他高性能客户机相比差距较大，导致Teamcenter客户端及各种应用程序在操作时长上与其他高性能客户机相比也存在明显的差距，这种情况需要增加内存或更换高速磁盘来改善客户端硬件的整体性能才可以解决。
客户机的网卡带宽与其他网络位置的客户机带宽相比存在较大的限制，另外有可能是网卡的带宽与网络吞吐量不匹配，出现这种情况就需要调整TCP/IP的网络参数来适应其带宽的要求，或者更换高速网卡来增加网络带宽。

物流技术装备的发展趋势

总结

Teamcenter系统性能优化是一套比较复杂的系统工程，涉及的知识点非常杂而多，需要掌握非常多的IT基础知识，比如，数据库、Teamcenter系统组件、网络和安全、WEB中间件、服务器操作系统以及硬件等等。

因整个Teamcenter系统又分为4层架构，每一层出现问题都会对整个系统产生影响，所以当系统出现性能瓶颈时，我们应该对每一层服务都要进行一次更加全面的诊断。利用上面的诊断方法和工具，可以帮助我们比较轻松的定位问题出在哪一层。比如，当在网络上出现过多的服务CALL时，说明网络层出现了问题，这时就需要排查网络安全策略、网络协议以及网络设备是否出现了故障，另外有可能是WEB中间件出了问题；当SQL的执行效率不高时，问题很有可能出在了资源层数据库上，这时我们需要对数据库的执行效率再进行更加细致的排查，有关数据库的性能测试和优化方法也很多、也很复杂，这里限于篇幅限制就不再过多赘述，我们将在下一篇《Teamcenter系统性能优化方法总结（数据库篇）》文章中与大家多分享一些数据库方面的优化案例。

上述诊断工具和方法只是为大家提供一种排查问题的思路，所谓万事开头难，找到问题则距离解决问题就已经完成一半的工作量了。同时，我们应该将发现的问题记录在册，整理之后形成一份检测报告，然后针对这份检测报告再出具一份性能优化建议书，性能优化建议书中应包含，但不限于以下内容：

现状描述（Teamcenter系统现状、网络环境现状、操作系统现状、数据库现状、硬件设备现状）。
性能优化方案（数据库、TC Server、WEB、FMS、客户端、网络、服务器）。
Teamcenter系统的备份回退策略。
系统性能优化计划及实施人员。

通过科学的检测方法和手段及利用更加规范化的工作流程，不但有助于我们更加快速的解决问题，还能体现出自己的专业性。工具和方法不会一成不变，也不会解决所有问题，工作当中除了善于思考能够提升自己外，还有就是工作总结。系统调优前后要多注重结果的比对，同时要注重调试次数的反复和迭代，对于经过反复检验和确认的成果要形成最后的性能优化总结报告，这有助于我们实战经验的快速积累。