ARM架構(gòu)下數(shù)據(jù)庫遷移的中間件性能優(yōu)化策略實現(xiàn)

歐陽美旺，陳曉軍，魯慧

（拓維信息系統(tǒng)股份有限公司）

1 引言

近年來，我國大力發(fā)展信創(chuàng)產(chǎn)業(yè)，基于ARM架構(gòu)的企業(yè)級服務(wù)器產(chǎn)品，逐漸應(yīng)用到政府、企業(yè)等各類平臺。在技術(shù)層面，以精簡指令集（RISC）為架構(gòu)的ARM芯片體系具有一定的性能優(yōu)勢，但基于復(fù)雜指令集（CISC）的X86架構(gòu)的原有應(yīng)用與數(shù)據(jù)庫遷移的安全、效率問題也引起了大量的關(guān)注。為了提高數(shù)據(jù)庫遷移質(zhì)量，快速實現(xiàn)平臺各主營業(yè)務(wù)的全面貫通，確保內(nèi)外部信息流的高效運轉(zhuǎn)，嘗試在對ARM架構(gòu)及其生態(tài)體系分析的基礎(chǔ)上，重點討論基于ARM架構(gòu)數(shù)據(jù)庫遷移中應(yīng)用中間件的性能優(yōu)化問題，為提高數(shù)據(jù)庫遷移的效率和質(zhì)量提供切實可行的建議。

2 ARM架構(gòu)生態(tài)體系

2.1 ARM與X86架構(gòu)對比分析（見表1）

1）授權(quán)方式

ARM架構(gòu)主要有指令集授權(quán)、內(nèi)核授權(quán)和使用權(quán)授權(quán)三種方式，其中指令集授權(quán)靈活度最高，授權(quán)費用最貴。

2）版本更迭

自1985年ARM公司推出ARM v1，目前ARM架構(gòu)已經(jīng)升級到第8代，2019年ARM公司推出了最新的v9架構(gòu)[1,2]。

3）性能更優(yōu)

相比X86架構(gòu)，ARM架構(gòu)在功耗、發(fā)熱、工作時長、數(shù)據(jù)安全等方面都具備明顯優(yōu)勢。

2.2 ARM架構(gòu)帶來的適配挑戰(zhàn)

ARM架構(gòu)作為數(shù)據(jù)中心的后來者，在推動國產(chǎn)化自主可控項目上，面對諸多挑戰(zhàn)。然而，由于X86架構(gòu)在數(shù)據(jù)中心的市場份額和對開源社區(qū)長期的投入，目前各大開源社區(qū)的主要都是使用X86架構(gòu)來進行開發(fā)、編譯構(gòu)建、集成驗證、打包發(fā)布等開源開發(fā)流程。

對ARM用戶來說想要直接使用通過基于X86架構(gòu)開發(fā)流水線產(chǎn)出的軟件包，常常面臨著很多不確定因素和額外的工作量。因此，只有在開發(fā)流程中引入ARM架構(gòu)開發(fā)流水線，端到端使用ARM架構(gòu)，才能從源頭解決適配問題。

3 中間件的性能優(yōu)化

性能問題是多方面的，比如應(yīng)用、系統(tǒng)軟件（應(yīng)用中間件、消息中間件、數(shù)據(jù)庫等）、操作系統(tǒng)、硬件、網(wǎng)絡(luò)，然而，如何診斷性能問題是出自應(yīng)用中間件。本文從解讀監(jiān)控指標、指標優(yōu)劣，及其關(guān)聯(lián)入手，分析在應(yīng)用中間件的性能優(yōu)化的參數(shù)問題，并提出優(yōu)化策略。

表1 ARM與X86架構(gòu)對比表

3.1 技術(shù)路線

3.1.1 建立基準

在進行優(yōu)化或者開始進行監(jiān)視之前，首先要建立一個基準數(shù)據(jù)和優(yōu)化目標。這個基準包括硬件配置、組網(wǎng)、測試模型、系統(tǒng)運行數(shù)據(jù)（CPU/內(nèi)存/IO/網(wǎng)絡(luò)吞吐/響應(yīng)延時等）。性能調(diào)優(yōu)是一個長期的過程。在優(yōu)化工作的初期，很容易識別瓶頸并實施有效的優(yōu)化措施，優(yōu)化成果往往也很顯著，但是越到后期優(yōu)化的難度就越大，優(yōu)化措施更難尋找，效果也將越來越弱。因此建議有一個合理的平衡點。

3.1.2 壓力測試與監(jiān)視瓶頸

使用峰值工作負載或?qū)I(yè)的壓力測試工具，對系統(tǒng)進行壓力測試。使用一些性能監(jiān)視工具觀察系統(tǒng)狀態(tài)。在壓力測試期間，建議詳細記錄系統(tǒng)和程序的運行狀態(tài)，精確的歷史記錄將更有助于分析瓶頸和確認優(yōu)化措施是否有效。

3.1.3 確定瓶頸

壓力測試和監(jiān)視系統(tǒng)的目的是確定瓶頸。系統(tǒng)的瓶頸通常會在CPU過于繁忙、IO等待、網(wǎng)絡(luò)等待等方面出現(xiàn)。需要注意的是，識別瓶頸是分析整個測試系統(tǒng)，包括測試工具、測試工具與被測系統(tǒng)之間的組網(wǎng)、網(wǎng)絡(luò)帶寬等。有很多“性能危機”的項目其實是由于測試工具、測試組網(wǎng)等這些很容易被忽視的環(huán)節(jié)所導(dǎo)致的，在性能優(yōu)化時應(yīng)該首先花一點時間排查這些環(huán)節(jié)。

3.1.4 實施優(yōu)化

確定了瓶頸之后，接著應(yīng)該對其進行優(yōu)化。本文總結(jié)了筆者所在團隊在項目中所遇到的常見系統(tǒng)瓶頸和優(yōu)化措施。需要注意的是，系統(tǒng)調(diào)優(yōu)的過程是在曲折中前進，并不是所有的優(yōu)化措施都會起到正面效果，負優(yōu)化也是經(jīng)常遇到的。所以在準備好優(yōu)化措施的同時，也應(yīng)該準備好將優(yōu)化措施回滾的操作指導(dǎo)。避免因為實施了一些不可逆的優(yōu)化措施導(dǎo)致重新恢復(fù)環(huán)境而浪費大量的時間和精力。

3.1.5 確認優(yōu)化效果

實施優(yōu)化措施后，重新啟動壓力測試，準備好相關(guān)的工具監(jiān)視系統(tǒng)，確認優(yōu)化效果。產(chǎn)生負優(yōu)化效果的措施要及時回滾，調(diào)整優(yōu)化方案。如果有正優(yōu)化效果，但未達到優(yōu)化目標，則重復(fù)步驟2（3.1.2）“壓力測試與監(jiān)視瓶頸”，如達成優(yōu)化目標，則需要將所有有效的優(yōu)化措施和參數(shù)總結(jié)、歸檔，進入后續(xù)生產(chǎn)系統(tǒng)的版本發(fā)布準備等工作中。

3.2 案例分析

3.2.1 案例描述

Nginx的應(yīng)用程序移植到ARM服務(wù)器上，發(fā)現(xiàn)業(yè)務(wù)吞吐量沒有達到硬件預(yù)期，需要做相應(yīng)調(diào)優(yōu)。

3.2.2 問題原因

1）網(wǎng)卡配置

該應(yīng)用場景下網(wǎng)絡(luò)吞吐量大，網(wǎng)卡的配置能對性能提升起到很大的作用。

2）操作系統(tǒng)參數(shù)配置

在更換操作系統(tǒng)后，原來的一些調(diào)優(yōu)措施需要重新定制。

3）應(yīng)用程序

從X86切換到ARM之后，可以做一些代碼層面、編譯選項上的調(diào)優(yōu)。

3.2.3 解決思路

1）網(wǎng)卡調(diào)優(yōu)

① 中斷綁核：中斷親和度描述為可以為特定中斷提供響應(yīng)的一組CPU，如果應(yīng)用程序可以通過關(guān)聯(lián)到相關(guān)的CPU，在相同的CPU上下文中處理接收到的數(shù)據(jù)包，則可以減少等待時間，提高CPU利用率。因此，可以將處理網(wǎng)卡中斷的CPU core設(shè)置在網(wǎng)卡所在的NUMA上，從而減少跨NUMA的內(nèi)存訪問所帶來的額外開銷，提升網(wǎng)絡(luò)處理性能。

在此案例中綁核拓撲如圖1所示。

在服務(wù)器中搭載了4塊1822網(wǎng)卡，每個網(wǎng)卡使用了4個端口，每個端口設(shè)置了6個隊列。整機有96個CPU邏輯核，與這96個隊列一一綁定。在應(yīng)用程序上，也在nginx.conf中設(shè)置worker_processes為96。

② 使用網(wǎng)卡的TSO特性

TSO(TCP Segmentation Offload)將傳出的TCP數(shù)據(jù)包的分片工作交給網(wǎng)卡來做，這樣可以提高大量使用TCP協(xié)議傳輸數(shù)據(jù)的應(yīng)用程序的性能。使用了TSO特性后，將為CPU減負，可有效降低發(fā)送端的CPU利用率。可以使用ethtool來使能TSO特性：

圖1 中斷綁核拓撲圖

# /sbin/ethtool –K tso on

在這個案例中，啟用了所有端口的TSO特性以實現(xiàn)更高的吞吐量。

③ 中斷聚合

中斷聚合通過合并多個接收到的數(shù)據(jù)包中斷事件，將其一起發(fā)送到單個中斷中，從而減少了網(wǎng)卡生成的中斷數(shù)量。

● 增加中斷聚合參數(shù)。

● 產(chǎn)生更少的中斷。

● 降低CPU利用率。

● 增加響應(yīng)延時。

● 提高整體吞吐量。

所以在這里增大了中斷聚合相關(guān)參數(shù)。

修改方式：

使用ethtool -C $eth方法調(diào)整中斷聚合參數(shù)。其中參數(shù)“$eth”為待調(diào)整配置的網(wǎng)卡設(shè)備名稱，如eth0，eth1等。

# ethtool -C eth3 adaptive-rx off adaptivetx off rx-usecs N rx-frames N tx-usecs N txframes N

為了確保使用靜態(tài)值，需禁用自適應(yīng)調(diào)節(jié)，關(guān)閉Adaptive RX和Adaptive TX。

●rx-usecs：設(shè)置接收中斷延時的時間。

●tx-usecs：設(shè)置發(fā)送中斷延時的時間。

●rx-frames：產(chǎn)生中斷之前接收的數(shù)據(jù)包數(shù)量。

●tx-frames：產(chǎn)生中斷之前發(fā)送的數(shù)據(jù)包數(shù)量。

2）TCP協(xié)議參數(shù)調(diào)優(yōu)

在測試過程中，通過perf trace工具捕捉到了sock:sock_exceed_buf_limit事件：

perf trace -e sock:sock_exceed_buf_limit -F 777

這表示內(nèi)核TCP協(xié)議棧中的發(fā)送緩沖區(qū)已耗盡，發(fā)送緩沖區(qū)的內(nèi)存大小成為阻塞應(yīng)用程序性能的瓶頸。在這個案例中，設(shè)置成如下所示的值：

echo ‘4096 2097152 67108864’ > /proc/sys/net/ipv4/tcp_rmem

echo ‘4096 2097152 67108864’ > /proc/sys/net/ipv4/tcp_wmem

之后在測試過程中，沒有再監(jiān)控到sock:sock_exceed_buf_limit事件。

3）操作系統(tǒng)調(diào)優(yōu)

使用perf工具來統(tǒng)計被測試進程的相關(guān)信息，發(fā)現(xiàn)上下文切換的頻率很高。進一步使用perf 工具來監(jiān)控被測進程，查看其中調(diào)度最頻繁的部分。發(fā)現(xiàn) timer_tick 在 ARM服務(wù)器中占了很高的調(diào)度時延。查看ARM服務(wù)器系統(tǒng)中的/proc/cmdline文件，發(fā)現(xiàn)其中包含了啟動參數(shù)nohz = off，這表示在該系統(tǒng)中關(guān)閉了內(nèi)核的nohz特性，這使得timer_tick切換變得更加頻繁，增加了上下文切換的開銷。為了解決該問題，在/boot/efi/EFI/euleros/grub.cfg中刪除了該內(nèi)核引導(dǎo)參數(shù)nohz = off。

4）應(yīng)用程序調(diào)優(yōu)

在搭載了ARM服務(wù)器上，可以在編譯過程中指定處理器、架構(gòu)相關(guān)的編譯選項來進行優(yōu)化。具體修改方式如下：

● 在Euler系統(tǒng)中使用HCC編譯器，可以在CFLAGS和CPPFLAGS里面增加編譯選項：

-mtune=tsv110 -march=armv8-a

在其他操作系統(tǒng)中，可以升級GCC版本到9.10，并在CFLAGS和CPPFLAGS里面增加編譯選項：

-mtune=tsv110 -march=armv8-a

3.2.4 總結(jié)

應(yīng)用中間件相關(guān)的性能監(jiān)控與優(yōu)化可以歸類為6個字：判斷、監(jiān)控、優(yōu)化。

1）如何判斷性能問題是出自應(yīng)用中間件？

從系統(tǒng)拓撲的角度：前端→中間件→應(yīng)用→中間件→數(shù)據(jù)庫的包抄當中，如果你發(fā)現(xiàn)其他都沒有問題，那很可能就是中間件的問題了。

從系統(tǒng)層次的角度：應(yīng)用→系統(tǒng)軟件（中間件、數(shù)據(jù)庫）→OS→硬件/網(wǎng)絡(luò)這條線上，如果其他都沒問題，那也得看看中間件了。

2）采用什么工具來監(jiān)控中間件？

根據(jù)實際的應(yīng)用部署場景，可以選擇的監(jiān)控范圍有：中間件自身的監(jiān)控、JVM的監(jiān)控、應(yīng)用的監(jiān)控、分布式系統(tǒng)監(jiān)視以及網(wǎng)絡(luò)監(jiān)視等。

監(jiān)控的指標有：響應(yīng)時間、Web應(yīng)用程序相關(guān)指標、JDBC連接池、線程池、JVM虛擬機、會話數(shù)、垃圾回收GC、高速緩存、數(shù)據(jù)源語句緩存等。

3）中間件如何影響系統(tǒng)的性能指標（如吞吐量、響應(yīng)時間、交易成功率）？

運行在中間件上的應(yīng)用是委托“中間件”來處理“應(yīng)用”與外界的一切聯(lián)系，比如：

① 有請求進來，有多少個session來服務(wù)于請求。

② 應(yīng)用需要讀寫數(shù)據(jù)庫，數(shù)據(jù)庫連接由應(yīng)用中間件負責，并且還放置了連接池。

③ 應(yīng)用需要多少內(nèi)存，由中間件定制。

④ 應(yīng)用需要做GC，由中間件定制。

4 數(shù)據(jù)庫遷移適配策略

數(shù)據(jù)庫系統(tǒng)遷移本身是一個復(fù)雜工程，異構(gòu)數(shù)據(jù)庫遷移相對同構(gòu)數(shù)據(jù)庫遷移技術(shù)難度更大，數(shù)據(jù)庫系統(tǒng)遷移需要完善的規(guī)劃方案和謹慎的實施操作，稍有不慎，就會導(dǎo)致遷移失敗，甚至丟失重要數(shù)據(jù)。具體項目實施過程中，在數(shù)據(jù)庫遷移流程與方法論的指導(dǎo)下，為解決遷移過程出現(xiàn)的問題，應(yīng)具備詳細的實施方案。

4.1 適配遷移流程整體設(shè)計

經(jīng)整體分析，國產(chǎn)化替換異構(gòu)數(shù)據(jù)庫遷移存在很多不確定性因素與痛點，基于這些問題，現(xiàn)梳理一整套數(shù)據(jù)庫遷移流程與方法論，需要說明的是，各階段的順序不是僵硬不變的，可按需在不同階段之間向前和向后移動，這取決于每個階段的結(jié)果和下一個階段的具體任務(wù)，具體流程圖可以參見表2。

表2 適配遷移流程設(shè)計

4.2 數(shù)據(jù)庫與應(yīng)用系統(tǒng)調(diào)研

數(shù)據(jù)庫遷移過程中需考慮數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)類型、數(shù)據(jù)庫性能、數(shù)據(jù)使用場景四個方面。數(shù)據(jù)庫結(jié)構(gòu)和數(shù)據(jù)類型是靜態(tài)數(shù)據(jù)，可以通過語法、語義比對完成調(diào)研，數(shù)據(jù)庫性能和數(shù)據(jù)使用場景是動態(tài)數(shù)據(jù)，與其對應(yīng)的業(yè)務(wù)屬性、數(shù)據(jù)庫硬件資源、數(shù)據(jù)庫自有能力、數(shù)據(jù)屬性和應(yīng)用系統(tǒng)屬性直接相關(guān)。

應(yīng)用的調(diào)研主要是發(fā)現(xiàn)應(yīng)用和數(shù)據(jù)庫之間的調(diào)用關(guān)系和調(diào)用方式，理清應(yīng)用各個模塊與數(shù)據(jù)庫調(diào)用SQL的兼容特點，明確應(yīng)用在各個模塊轉(zhuǎn)換的改造點。應(yīng)用調(diào)整的內(nèi)容取決于源、目標數(shù)據(jù)庫架構(gòu)切換的狀態(tài)以及源數(shù)據(jù)庫與目標數(shù)據(jù)庫的兼容度。通過調(diào)用SQL詳情實現(xiàn)改造點定位，即交互SQL點定位， 如應(yīng)用系統(tǒng)采用成熟框架，可以在框架中直接完成修改，如在代碼中直接嵌入SQL，若有成熟工具快速完成改造點定位和半自動化實現(xiàn)改造樣本，將會極大方便改造工作。

5 結(jié)語

信創(chuàng)領(lǐng)域的政府信息化建設(shè)已從探索期，逐步進入大規(guī)模建設(shè)期，解決了系列適配技術(shù)問題，取得一定成果[3]。但處理數(shù)據(jù)庫遷移適配問題，需要對中間件的技術(shù)進行深度優(yōu)化，值得研究與關(guān)注。本文從解讀監(jiān)控指標、指標優(yōu)劣，及其關(guān)聯(lián)入手，分析在應(yīng)用中間件的性能優(yōu)化的參數(shù)問題，并提出優(yōu)化策略。