鐵路客票系統性能優化的研究

李 琪，劉相坤，李聚寶，武振華

（中國鐵道科學研究院電子計算技術研究所，北京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.