铁路客票系统性能优化的研究

李 琪，刘相坤，李聚宝，武振华

（中国铁道科学研究院电子计算技术研究所，北京100081）

铁路客票系统自1996年启动以来，经过5次大版本的升级改进，基本满足了用户的需求。系统为铁道部、地区中心、车站三级分布式系统，在5.0版本后采用应用服务器和负载均衡技术加强了对用户请求的处理。目前一些小站采用取消车站服务器模式或大站带小站模式，所以系统的业务和数据压力集中体现在铁道部、地区中心和大站的服务器上。为了满足不断膨胀的业务和数据要求，已对硬件资源做过几次大的升级改造。客票系统是铁路运输的重要系统，它的稳定运行极为重要，每到节假日售票高峰时间系统的压力非常大。在维护使用中，系统优化一直在进行，不断增加的需求和多年数据的累积对于优化非常迫切，所以更加深入、有效、全面地对系统优化尤为重要。

本文结合多年对客票系统的开发、实施和维护的工作经验和体会，对系统性能的优化进行了深入探讨。

1 系统调优策略

系统调优应该是一个不断提升的过程。由于应用需求和数据是动态变化的，所以系统调优也是一个循环螺旋上升的过程。图1是在实践摸索中提出并采用的一种策略方法。

图1 调优策略示意图

1.1 系统监控记录现场

出现问题的时候一定要在较快的时间内通过工具或命令将各可能的现场环境记录，这时的记录数据最真实，也对解决问题最有用。真正要维护好一个系统，就应在出现问题之前，通过日常监控记录现场，记录积累发现潜在的问题。目前客票系统监控软件已经使用操作系统、数据库等的命令每隔固定时间收集系统运行情况，并上传到管理机，展现形式也很丰富和直观。

1.2 初步确定问题环节

操作系统、数据库、网络、应用服务器、应用程序等方面都可能是问题所在，但要最快确定问题环节，不能漫无目的，应该制定检查问题的正确顺序。一般业务请求反馈流程是：应用前台反映→应用系统→网络线路和交换设备→主机系统→数据库系统，制定顺序应该从暴露问题的环节开始向后逐步检查。如果曾经发生过类似情况，根据经验能够直接定位问题，也是最迅速的途径。如果应用上并未发现问题，而是系统日志或监控结果等地方出现的警告或错误，就需要根据出错地方提前解决潜在的问题，这也可能是一个综合性质的问题。

1.3 跟踪诊断

有些问题容易准确定位，直接解决即可；但有的问题可能是多个环节错综复杂的综合性难题，这样在短时间内很难准确定位问题所在，就需要跟踪问题重现的规律。

1.4 反复模拟测试

在现场生产环境中出现的问题，不是都能在生产环境中有规律的重现，为了定位问题，往往需要在模拟环境中创造条件重现问题。通过在测试环境中调整系统的参数等方法，再经过反复模拟测试，为确定调优方案做好准备。

1.5 确定调优方案

在前面的环节中如果能够重现问题，则针对所在环节调整原有调优方案；如果不能重现问题，也不能等待这样的问题在生产环境中再现，那样可能给生产带来严重的影响，所以也需要根据现场跟踪的结果和经验制定调优方案。

1.6 调优实施

在前面已经做了大量、充分准备工作的基础上，这时就可以对实际生产系统做优化实施。

上面6个步骤是一个系统调优的周期，但并不意味着在一个周期内所有问题都可以解决，往往复杂的问题需要经过几个周期的观察、测试和调整才能真正解决。

2 系统调优常用监控方法

通过询问客票系统的各级业务人员了解情况，是最为直接的监控手法。这对于日常业务的处理速度和稳定性有直观的体现，但是存在时间滞后的问题。

对操作系统、数据库、网络、应用服务器和应用程序等的日志监控，可以查看系统的一些警告和错误信息，从中发现错误或潜在的问题。

使用一些系统命令可以抓取系统运行过程中使用资源的情况，与实际情况对比，也可与同时期类似情况对比，争取提前发现问题。操作系统一级资源的监控，HP中可以使用top，IBM中使用topas或nmon；数据库中使用sp_sysmon监控资源，使用dbcc检查数据库和表是否存在问题。

通过dbcc traceon(3604)，dbcc sqltext(spid)可以查看正在工作的进程的内容。

使用sp_monitorconfig可以查看数据库参数使用情况。

通过客票系统监控软件不仅能查看刚刚发生过的资源情况，还可以查看历史使用情况，通过类似情况的对比分析也是有效的方法。

3 系统调优中关键配置的优化

3.1 内存配置优化

内存是系统性能的关键因素。对内存使用和管理是否合理既影响系统的安全，也影响系统的性能。在实际使用中也出现过因共享内存配置不当，导致系统越来越慢，直至死机无法正常使用的情况。

全路客票系统中出现过因为内存分配不当导致业务受到影响的实例。在实际配置资源时，经常出现按照一定的比例配置数据库所用最大内存，其实这样做在内存较大的情况下一般不会出现问题。但是在内存较小的情况下按照比例粗略计算来配置，就会出现数据库所用内存过多，导致系统可用内存不够，最后系统会将数据库内存转到虚拟内存（磁盘交换分区）上，这样系统就会变得越来越慢。所以合理的配置应该对资源精打细算。

客票系统对内存分配的调优原则：

主机系统的物理内存总数用M表示，系统占用内存用S表示，文件系统占用内存用F表示，复制占用内存用R表示，备份服务器使用内存用B表示，后台应用使用内存用H表示，临时维护命令或操作使用内存用C表示，数据库可用的最大内存用SM表示，由此得出：

由式（1）计算出的内存配置，不会因为现有的某一方面占用过多导致系统不够用而变慢。当然，如果出现新增加业务可能改变内存的平衡，就应该重新计算并做出新的优化配置。

与内存配置相关的磁盘交换分区的配置也很重要，虽然将内存里的东西转到交换分区上会变慢，但是可以保证数据完整。一般配置大小为物理内存的1.5倍以上，根据实际需要可作出调整。

3.2 tempdb（临时数据库）的配置优化

tempdb为临时表和其他临时工作空间提供一个存储区域。当做order by、group by、distinct和创建临时表等操作时将使用tempdb的空间。经常引起tempdb问题的可能原因是：tempdb被频繁填满、系统表被锁定、数据页被刷新出缓存等。

根据实际调优经验，可以通过以下方法解决相关问题：

（1）扩展tempdb的空间，这样可以减缓被频繁填满和刷新出缓存。估计tempdb的大小主要靠经验和监测来调整。

（2）tempdb要尽可能扩展到独立设备上，这样就不会与关键应用发生争用。但是缺省情况下，tempdb的一些段在master数据库设备上，当扩展到新设备后，可以从master设备中删除这些段，以后所有临时表就会只在新的设备上创建，避免了跨多个设备的问题。

（3）把tempdb整个放在RAM 驱动器或固态存储设备上，提高tempdb的i/o速度，这样可以减轻封锁竞争。

（4）设置多个tempdb。实际应用中常常会出现并发性处理事物过多导致争用系统表，导致锁表的情况，现在经常采用这一办法来解决。

（5）把tempdb绑定到自己的命名缓存。在创建、使用和删除临时表时会频繁地使用default data cache，为避免与其它对象的冲突，最好把tempdb捆绑到命名缓冲。

以上方法在使用中可根据实际情况，选择其中几个，达到性能调整需要即可。在维护中了解到，因为价格等原因使用固态存储的并不多，所以可选择上面D方法也基本可以减轻封锁竞争。

3.3 锁的配置优化

锁在系统运行中起着很重要的作用，锁相关参数的配置以及应用在锁机制下的开发和维护都可能影响系统的运行。不同类型的锁都各有优缺点，现在客票系统中很多重要的表改为行级锁，起到很好的效果。

根据业务特点和锁的作用综合考虑，应该统筹考虑，做出优化配置。Sybase数据库缺省使用页级锁，通过对不同类型锁的配置实现封锁和并发的平衡，以下几点作为参考：

（1）一般情况下Sybase数据库能自动发现并解除死锁，但是在实际使用中也出现死锁保留较长时间而影响应用，所以应该尽可能避免死锁。为尽可能降低封锁竞争和避免死锁出现，事务应缩小且应尽快提交；工作流任务（自动后台执行的操作）应尽可能避开使用相同表的大事物同时操作；在业务处理高峰期间减少人工维护操作；加强监控及时手工杀掉不重要的进程。

（2）在搜索变量上没有索引就会引起表级锁，在大表上造成表扫描会严重影响业务性能，所以要充分挖掘业务需求，尽可能定义正确的索引。

（3）对锁升级的控制会直接影响使用。锁升级阈值用于设置升级到对象上的表锁之前，所允许的锁的个数。锁升级是针对单一搜索而言的，当一次搜索的锁多于锁升级阈值时，锁就会升级。可用3个参数进行升级控制：page lock promotion HWM、page lock promotion LWM、page lock promotion PCT。

（4）锁升级阀值的设定需要根据资源和应用来确定。锁升级阀值低，易于产生表级锁，降低了并发度，严重时会影响应用的连续性；锁升级阀值高，可提高并发度，但需要足够的锁个数，资源开销大。综合考虑，现在内存空间相对大一些，可以把锁的个数设置大一些，锁升级阀值设置高一些。

3.4 缓存的配置优化

随着服务器处理能力的增强，应该将内存等关键资源用在最需要用的地方。实践中发现表资源争用长期存在，往往成为性能的瓶颈。所以对于关键表配置命名缓存很重要，可以减少争用。例如对syslogs、seat_area、left_base_center等表在一些铁路局配置了命名缓存后效果很好。

3.5 引擎的配置优化

当前的客票数据库服务器的cpu配置有很多个，这可以解决并发请求在cpu方面的压力，但是随着可用资源的不断扩大，需要在参数配置方面优化，否则不仅起不到加速效果，还会造成新的瓶颈。一般主要需要注意以下两个方面：

（1）如果cpu数量为n且大于2，数据库引擎一般可以考虑配置在可用cpu数量的80%左右，但在初期可以多留几个给系统用，也可在以后增加引擎数量。

（2）“global cache partition number”参数应该随着引擎的个数调整，一般配置为大于引擎数且最接近引擎数的2的幂。例如引擎数位15，该参数配置为16。

3.6 表分区的配置优化

现在的应用数据越来越庞大，多个业务同时访问一张表很常见，在cpu并发处理能力得到很大改善的情况下，设备访问IO情况的问题突现出来，通过分区可以得到部分缓解。

通过把最常用的表分区，通过一定的规则放在多个设备上，从而改善多个并发访问时的IO性能。现在有的铁路局将seat_area表做了分区，效果比较好。

4 结束语

系统的优化是需要长期不断进行的，并根据需要逐步调整，一般经过几个不同业务流量周期后，系统对于资源的使用范围相对固定下来。如果业务量在某个时期突然增大，应适时作出相应调整。合理配置各项资源，达到相互协调，才能使整个客票系统性能最佳。

[1] 杨孝如，徐任，李立，彭立军. Sybase数据库系统管理指南[M] . 北京：中国水利水电出版社，1997.

[2] 客票系统5.0技术手册[S] . 北京：中国铁道出版社，2006.