OSS系统的性能问题及对策

2019-11-03 19:19:56

字体：大中小

来源：转载

供稿：网友

陈龙大唐电信张春红北京邮电大学

　　现在OSS已经成为整个通信网的重要组成部分。OSS的建设经历了一个从无到有、从点到面的过程。OSS系统建设的最初目的是为了解决生产作业的自动化处理，最初建设的系统也局限在专业的网管系统和计费处理等运营核心领域。随着运营的发展和管理的深化，很多运营企业开始将市场经营和运维管理领域中的更多的环节纳入OSS的管理范畴。于是，很多按照职能划分的，大大小小的系统陆续建立起来。同时，由于业务的发展，原先建成的诸多核心系统也经过不断的扩容和改造升级，业务管理的范围越来越大，功能也越来越强。当人们都在关注OSS系统的业务管理功能是否强大时，一个新的矛盾产生了，那就是，一些系统由于数据量不断增大，以及系统间频繁交互而导致了严重的性能问题。

OSS系统概述

　　OSS系统都包括哪些？国际上没有一个固定的模式。一般意义上说，很多运营商在建设时参考的是eTOM模型。它从企业运营，企业战略、架构和产品，以及企业内部管理这样三个层面分别做了描述；并从流程的角度描述了业务开通、业务保障、业务计量、运营支持、战略、架构和产品生命周期等七个企业的核心流程。

　　在国内，大多数的电信运营企业的OSS系统一般包含几个大的部分：即专业网管系统、资源管理系统、计费结算系统、营帐系统、客服系统、经营分析系统等几大类。

　　这几类的支撑系统，架构上符合TMN的思想。我们知道，TMN分成四层，从下往上依次为网元管理层、网络管理层、业务管理层和经营管理层。上述已经建成的支撑系统，总体上网管类的系统和资源类的系统对应于TMN的网元管理层和网络管理层；计费结算类系统和营帐类系统对应于TMN的业务管理层；经营分析类系统对应于TMN的经营管理层。一般而言，业务管理层的系统由于是实时的业务系统，相对来说对性能的要求高一些，效率问题比较关键；而网管类系统和经营类系统，在报表处理和报表分析方面，由于数据量比较大，也存在效率问题。

OSS部署环境的分析

　　OSS系统是指为保证电信运营企业能够高效稳定的运转，而建立起来的一系列包括软硬件支撑环境、应用软件以及业务数据在内的运营支撑系统。一个完整的OSS系统包括几个方面：主机、网络、数据库、应用软件、系统软件、终端、与其它系统的接口以及系统中业务流程、业务规则和数据。从理论上讲，这些方面的因素都有可能成为OSS系统性能的瓶颈。

　　主机系统是影响性能的主要因素之一。电信的支撑系统，绝大多数是采用小型机或高档PC SERVER做为服务器，当然也有极少数的采用大机的案例。这里我们只介绍比较常见的小型机系统。一般而言，象计费结算系统和营帐系统这样比较大的应用，对主机的处理能力都有量化的要求。衡量数据库服务器处理能力的指标一般采用Tpmc值（Tpmc是Transactions per minute的简称；C指TPC中的C基准程序）。选择主机系统时通常需要按照所处理事务的规模来计算Tpmc值，并根据Tpmc值配置相应档次的小型机。否则对支撑系统的处理能力和处理时限都将会产生影响。

　　网络的选择和配置也有可能是影响整个系统性能的因素之一。现在的很多系统都是以本地网为单位来建设的，更有一些系统是按照大区集中或者省集中的模式建设的。在这种情况下，大数据量在异地的传送和处理对网络的传输能力会有较高的要求。网络的传输能力如果没有适当的冗余，在大笔业务突发的情况下，就会产生拥塞。

　　数据库在支撑系统中的使用已经非常普遍，但多数系统中的数据库并没有充分的优化。数据库的性能调优和参数调整，以及它的索引策略等已经越来越引起系统集成商、软件开发商和最终用户的重视，但到目前为止，对此还没有定量的评估，还处在经验调优的阶段。　　应用软件的设计质量和开发质量是影响系统性能的最重要因素之一。从设计上讲，业务功能模块划分的粒度、事务处理的描述、数据库表的物理设计、热表查询策略以及数据库约束机制等都是影响系统性能的重要因素。从开发上讲，算法的选择，SQL语句的使用等也都会影响到应用的时延。

　　还有一个因素就是系统间的互联。单一的支撑系统运转时没有性能问题，在与其它系统互联以后，可能就不一样了。这取决于接口设计得是否合理，系统间的服务调用机制的采用，以及数据的存储策略和共享机制，这些因素都将使以前单一系统的事务处理模式变得复杂，从而带来性能上的问题。

　　当然，系统软件的选择和配置，终端的使用，都有可能影响整体的效率，但从实际情况看，这些还都不是主要的因素。

基于应用的分析及优化策略

　　前面所述，是从OSS系统的一般意义上讲的。对于某一类特定的OSS系统，因其应用特点和处理方式不尽相同，相应的性能解决方案的策略也有所不同。

　　例如，对于计费帐务系统来说，主要的性能压力来自两个方面。一个是出帐的时候，一个是前台收费。出帐可以用两种方式，一种是基于文件的方式，速度相对要快一些；还有一种是基于数据库的方式，速度虽不如前一种快，但安全性比较高。在每月的收费日，收费前台终端往往面临较大的压力，这是因为大数据量并发导致整个系统的性能降低。对于大数量并发的情况，一个比较好的方法是采用B/A/S或C/A/S的三层体系架构。在三层结构中，由于中间件软件和应用服务器的引入，可以将表现逻辑放在瘦的客户端，将业务逻辑放在应用服务器，而数据逻辑则放在数据库服务器端。这样大数据量的访问只与中间层的应用服务器交互，而不会影响到数据库服务器，加之中间件软件提供的负载均衡的机制，使得效率得到了提升。

　　而对于如营业处理这样的业务处理系统，低性能主要是因为多种不同的业务处理逻辑针对有限几张热表频繁操作导致的。以97系统而言，对于规模比较大的C3局，往往表现出营业窗口受理定单慢，核配线路资源速度慢，定单处理过程慢，或是报表的统计慢。这是因为在以上的几类操作中，往往是针对同一张表进行的（而之所以是几类数据放在同一张表内存储主要则是考虑数据一致性的问题），在数据量比较大，并且同时频繁操作的时候，就会出现相互锁定的现象。对于这样的应用，可以尝试几种解决方法。方法一是可以重新考虑热表的物理存储，使其负载均匀分布在物理设备中；方法二是可以考虑数据的一定程度的冗余存储，但同时需要考虑好空间成本和数据的一致性；方法三是适当减少数据之间的约束，因为在数据库的约束机制比较多的时候，系统会牺牲大量时间做数据合法性检查，从而降低效率；方法四是建立并优化索引，这在实践中是非常有效的一种方法；方法五是优化SQL语句，使用高效代码。不过需要说明的是，以上的方法只是改善系统性能的可能的方法，并不是调优工作的充分条件，也不是必要条件。通过应用软件调优和通过数据库、网络以及主机系统的调优都是有限度的，而实际效率问题的解决则是这几个方面的共同努力。当然，在应用复杂到一定程度，可能上述的方法都没有办法解决，这时就需要考虑根据需求分析，重新规划、重新设计，必要时应考虑将系统拆分实施。

结束语

　　OSS的建设将朝着集中化，综合化的方向发展，可以预见以后投入运营的支撑系统无论从覆盖的用户规模还是要处理和分析的数据都会有增无减，所以OSS系统的性能问题也将是今后我们面临的一大挑战。目前虽然有很多厂商推出了性能监测和性能调优的工具，但也往往只是针对某一网络元素的监控和改善，或是针对SQL语句的优化；整体上解决问题的效果并不明显。目前在实践中，对影响客户应用的综合因素还只能定性的研究和分析，系统性能的综合调优还是处在经验调优的阶段。不过我们相信，随着OSS热潮的掀起，将有更多的企业和研究机构投入其中，OSS性能调优技术和效果必定将会取得有效的进展。

----《通讯世界》