低延時期貨交易系統的優化與測試

雷達，沈益明

（1.東華大學計算機科學與技術學院，上海200051；2.建信期貨有限責任公司，上海200122)

0 引言

我國期貨市場自創立以來，一直采用電子化交易方式，交易系統一直是期貨公司的核心技術系統。目前客戶普遍使用的期貨交易系統在設計時，核心考慮的是系統的并發性、可用性、系統容量等，低延時并不是最優先考慮的。但近年來，國內期貨市場發展迅速，期貨新品種源源不斷上線，期權、以人民幣計價的原油期貨等新業務也陸續推出，期貨市場的交易方式和市場功能不斷豐富，各類投資者尤其是機構投資者參與各類投資產品、參與多市場多品種間的套利熱情日益高漲。這些投資者造成了資金流動性和交易量的急劇增加，因此對期貨交易系統提出了更為明確的要求，主要體現在提高交易速度和提供程序化交易支持等功能。為了在競爭激烈的行業中脫穎而出，期貨公司迫切需要低延時系統的優化解決方案，從而為速度敏感的客戶提供更為優質的服務。

交易系統的低延時意味著投資者做出投資決策到委托獲得執行和確認的時間間隔必須盡可能短。對于某些交易，如高頻交易，交易速度是影響投資效果的最重要因素之一。此時，衡量交易系統績效最重要的指標之一就是系統延時。一些高頻投資策略可以在系統延時較低的情況下獲得可觀的正收益。

1 期貨交易系統延時框架

如圖1 所示，期貨交易是一個雙向往返的過程。廣義上的交易延時是指由委托等交易指令從市場參與者系統發出，到交易系統接受、處理，并返回處理結果的時間開銷。而狹義上的交易延時是指交易指令從進入交易系統接入點之后到處理結果返回接入點之間的時間開銷[1]。對于期貨公司這種集中式的交易系統來說，客戶系統和交易所撮合等外部延時因素不可控，因此低延時期貨交易系統的構建主要基于后者進行討論。

對于期貨交易系統，根據經過的處理環節，交易延時可細分為以下幾類：

消息處理延時：消息傳輸過程中消息格式轉換的應用，以及消息可用性機制相關的時間開銷；通信處理延時：主機協議棧處理開銷；調度延時：主機請求到處理開始的時間開銷；發送/接收延時：主機向網絡發送或接收協議包的開銷；傳播時延：傳播介質上傳輸的時間開銷，主要與傳輸距離和傳輸介質有關[2]。影響延時的因素分布在硬件、網絡、操作系統、中間件和應用程序等不同層次上。其中，根據文獻[3]，對于高性能、低延時期貨交易環境的系統來說，這些因素相互作用，在構建低延時期貨交易系統的時候，尤其需要對這些延時影響因素進行分析，盡量避免或降低延時影響因素，從而降低交易延時。

圖1 期貨交易系統結構

2 低延時期貨交易系統的優化

2.1 優化步驟

在系統優化之前，需要收集延時參數和數據作為基線，知道“正常”的系統延時數據。然后查找潛在的性能問題并進行參數調優來修復。觀察這些調整對系統的影響并決定是否確認保持這種調整或者恢復到調整前的狀態。系統需要定期檢閱，以發現系統異常變化引起的延時抖動。

優化的步驟如下：

（1）收集數據，建立基線。

（2）對系統進行選擇合理的參數。

（3）觀察統計數據，確認所做的調整是否正確，提交更改或回滾恢復。

（4）確定潛在的性能問題。

（5）調整優化參數。

（6）重復步驟（3）。

2.2 優化內容

（1）服務器優化

低延時期貨交易系統選配的服務器盡量高主頻、大內存，以HP DL380 服務器為例，在優化前記錄系統參數配置，以便在調優過程中跟蹤變化。根據HP 推薦，在BIOS 調優前需先升級至相應BIOS 和Firmware固件版本，有助于提升系統延時性能。

服務器出廠時硬件參數默認設置為通用節能模式，調整BIOS 參數，降低主機延時，使主機發揮最大性能，從而達到降級延時中的關鍵一環。BIOS 參數超頻，虛擬化，超線程均會產生潛在延時抖動風險，需要關閉這些功能，關鍵優化參數描述如表1。

表1 BIOS 優化參數表

（2）Linux 系統優化

調整/boot/grub/grub.conf 參數，增加“idle=poll nosoftlockup mce=ignore_ce intel_idle.max_cstate=0 "參數到kernel。

idle=poll 參數與“intel_idle.max_cstate=0”一起使用時，“idle=poll”使處理核心保持在C0 狀態；nosoftlockup參數使高優先級線程在內核上連續執行超過軟鎖定閾值時，防止內核記錄事件；intel_idle.max_cstate=0 防止內核重寫BIOS C-state 設置；mce=ignore_ce 防止Linux在機器檢查庫中每五分鐘啟動一次輪詢，檢查是否存在可糾正的錯誤。這些參數調整有助于降低通信處理延時、調度延時和發送接收延時。

（3）網絡優化

在低延時系統中我們配置Sloarflare 的低延時網卡，停止中斷分配服務，將網卡口的中斷手工配置至網卡PCI 插槽對應的NUMA 所屬的CPU 核。運行如下指令并將命令添加至rc.local，設置為開機啟動加載，有助于降低傳播延時。

網卡中斷親和性優化：

/usr/sbin/sfcaffinity_config-c 1,2,6,7 auto ethX

網卡吞吐量優化：

/usr/sbin/ethtool-G ethX rx 4096 tx 2048

/usr/sbin/ethtool-X ethX equal 2

/usr/sbin/ifconfig ethX mtu 9000 txqueuelen 10000

（4）交易線程綁核

期貨交易系統的交易核心是多線程，操作系統調度算法使線程均勻的分布在CPU 核心上，線程之間需要進行通信、共享資源，所以這些資源必須從CPU 的一個核心被復制到另外一個核心，這會造成額外的開銷。

為了讓程序擁有更好的性能和更低的延時，將交易核心線程綁定到特定的CPU，這樣可以減少調度的開銷和保護關鍵線程。綁定后交易核心線程就會一直在綁定的核上運行，不會再被操作系統調度到其他核上，但綁定的核上還是可能會被調度運行其他應用程序的。因此，需要隔離被交易核心綁定的核。綁核代碼如下：

bind_ttrade_cpu（）

{

ttrade_threads=`ps-eLF|grep ttrade|grep-v grep|awk'{print

$4}'`

cpucore=（6 7 8 9 10 11）

index=0

for i in$ttrade_threads;do

if![[-z$i]];then

taskset-pc${cpucore[$index]}$i

fi

index=`expr$index+1`

done

}

bind_ttrade_cpu

3 低延時期貨交易系統的測試

（1）測試準備

試驗環境為萬兆以太網，交換機Arista 7140，兩臺HP DL380 G9 服務器（12 核3.40GHz，64G 內存），配置2 塊Solarflare 8522 萬兆網卡和光纖模塊。

（2）RTT 延時測試：

此外，卷積神經網絡還涉及到多層次的輸出類別以及輸入圖像類別。針對不同種類的輸出與輸入圖像而言，通常都需將其分成相應的隱含層，然后將其連接于整個卷積網絡。在這其中，圖像隱含層能夠容納某些中間信息，且可以用來顯示圖片中的邊緣點以及特征點。由此可見，卷積神經網絡具備的核心價值就在于開展全方位的邏輯判斷，其在本質上很近似人腦固有的性能，同時也涉及到多層次的技術細節。

兩臺服務器使用光纖back-to-back 直連，避免交換機產生的延時影響，RTT 測試結果如下：

優化前：

rtt min/avg/max/mdev=0.036/0.084/0.109/0.014 ms

服務器優化：

rtt min/avg/max/mdev=0.035/0.041/0.056/0.011 ms

Linux 系統優化：

rtt min/avg/max/mdev=0.027/0.031/0.049/0.007 ms

網絡優化：

rtt min/avg/max/mdev=0.006/0.008/0.017/0.002 ms

從結果看出前述調優方法效果非常明顯，但要注意的時，RTT 不可能無限降低，當降到某個穩定值時，我們認為此時調整的參數有效，如果無限制的追求最低，那延時抖動所帶來的風險對期貨交易來說是致命的。

（3）Onload 加速中間件測試

測試主要使用了sfnettest 開源工具來對比使用Onload 和Kernel 的差別。pingpong 測試1/2RTT 平均延時數據（單位：微秒）如圖2。

圖2 1/2RTT 平均延時

從圖2 中可以看出Onload 中間件的加速功能比Kernel 低2/3，對延時的提升是巨大的，當一個應用程序調用操作系統內核來發送和接收數據，從應用程序到內核是一項開銷很大的操作，當應用程序使用Onload 中間件發送或接收數據,它利用了kernel bypass 技術，中間件直接訪問網卡上的一個虛擬區來達到與網卡的直接通訊。因此系統的開銷越小，延時就越低。

（4）期貨交易實盤測試

期貨公司更多關注的是交易系統自身內部延時，對系統設置4 個采樣點T1，T2，T3，T4[4]。其中T1 為報單錄入應答，當客戶端發出報單錄入請求指令后，交易系統返回響應時；T2 為交易系統接受到報單錄入請求后向交易所前置發送報單錄入請求；T3 為交易系統接受到請求后發給交易所，交易所收到后返回的請求；T4為返回給終端交易所報單狀態。

圖3 中可知，交易系統內部延時為Inner=（T2-T1）+（T4-T3）。

圖3 延時指標定義

使用API 在內網用接近市價報單并迅速撤單，下單頻率為50 筆/秒，內部處理時間（包含上行和下行的總處理時間）平均為27us，99%的報單延時在35us 以下。報單延時分布如圖4。

圖4 交易系統報單延時

從圖4 看出系統的內部延時較為穩定，系統內部平均延時27us，那么每秒能處理的訂單量約為1000000/27=37037。如果以用戶量來說明的話，能處理3 萬7 千筆的報單相當于能接受375 個用戶每秒按100 筆（上期所流控）來報單而不會出現積壓。

4 結語

在系統上減少或消除抖動是獲得最佳性能的關鍵，然而抖動的原因從而導致低劣的性能很難定義和很難補救，特別是在當前交易環境中，期貨公司更多關注于自身環境的內部延時，從交易所線路接入到期貨公司機房，從服務器、網卡到操作系統等，要設計好每一個環節。

期貨交易系統是個多因素相互作用的復雜系統，僅改進系統的一部分并不一定會帶來總體性能的提高和延時的下降。因此，構建低延時交易系統必須把握均衡原則，在把握關鍵因素的同時，必須從系統整體作考慮，認真分析各因素之間的相互作用和與周邊系統的相互聯系，并根據實際情況不斷調整和優化。