歐陽美旺，陳曉軍，魯慧

（拓維信息系統(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ì)量，快速實(shí)現(xiàn)平臺各主營業(yè)務(wù)的全面貫通，確保內(nèi)外部信息流的高效運(yùn)轉(zhuǎn)，嘗試在對ARM架構(gòu)及其生態(tài)體系分析的基礎(chǔ)上，重點(diǎn)討論基于ARM架構(gòu)數(shù)據(jù)庫遷移中應(yīng)用中間件的性能優(yōu)化問題，為提高數(shù)據(jù)庫遷移的效率和質(zhì)量提供切實(shí)可行的建議。

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)費(fèi)用最貴。

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í)長、數(shù)據(jù)安全等方面都具備明顯優(yōu)勢。

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

ARM架構(gòu)作為數(shù)據(jù)中心的后來者，在推動(dòng)國產(chǎn)化自主可控項(xiàng)目上，面對諸多挑戰(zhàn)。然而，由于X86架構(gòu)在數(shù)據(jù)中心的市場份額和對開源社區(qū)長期的投入，目前各大開源社區(qū)的主要都是使用X86架構(gòu)來進(jìn)行開發(fā)、編譯構(gòu)建、集成驗(yàn)證、打包發(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)控指標(biāo)、指標(biāo)優(yōu)劣，及其關(guān)聯(lián)入手，分析在應(yīng)用中間件的性能優(yōu)化的參數(shù)問題，并提出優(yōu)化策略。

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

3.1 技術(shù)路線

3.1.1 建立基準(zhǔn)

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

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

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

3.1.3 確定瓶頸

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

3.1.4 實(shí)施優(yōu)化

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

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

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

3.2 案例分析

3.2.1 案例描述

Nginx的應(yīng)用程序移植到ARM服務(wù)器上，發(fā)現(xiàn)業(yè)務(wù)吞吐量沒有達(dá)到硬件預(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之后，可以做一些代碼層面、編譯選項(xiàng)上的調(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ù)包，則可以減少等待時(shí)間，提高CPU利用率。因此，可以將處理網(wǎng)卡中斷的CPU core設(shè)置在網(wǎng)卡所在的NUMA上，從而減少跨NUMA的內(nèi)存訪問所帶來的額外開銷，提升網(wǎng)絡(luò)處理性能。

在此案例中綁核拓?fù)淙鐖D1所示。

在服務(wù)器中搭載了4塊1822網(wǎng)卡，每個(gè)網(wǎng)卡使用了4個(gè)端口，每個(gè)端口設(shè)置了6個(gè)隊(duì)列。整機(jī)有96個(gè)CPU邏輯核，與這96個(gè)隊(duì)列一一綁定。在應(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ù)，可有效降低發(fā)送端的CPU利用率?？梢允褂胑thtool來使能TSO特性：

圖1 中斷綁核拓?fù)鋱D

# /sbin/ethtool –K tso on

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

③ 中斷聚合

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

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

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

● 降低CPU利用率。

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

● 提高整體吞吐量。

所以在這里增大了中斷聚合相關(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è)置接收中斷延時(shí)的時(shí)間。

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

●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)用程序性能的瓶頸。在這個(gè)案例中，設(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)計(jì)被測試進(jìn)程的相關(guān)信息，發(fā)現(xiàn)上下文切換的頻率很高。進(jìn)一步使用perf 工具來監(jiān)控被測進(jìn)程，查看其中調(diào)度最頻繁的部分。發(fā)現(xiàn) timer_tick 在 ARM服務(wù)器中占了很高的調(diào)度時(shí)延。查看ARM服務(wù)器系統(tǒng)中的/proc/cmdline文件，發(fā)現(xiàn)其中包含了啟動(dòng)參數(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)的編譯選項(xiàng)來進(jìn)行優(yōu)化。具體修改方式如下：

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

-mtune=tsv110 -march=armv8-a

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

-mtune=tsv110 -march=armv8-a

3.2.4 總結(jié)

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

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

從系統(tǒng)拓?fù)涞慕嵌龋呵岸恕虚g件→應(yīng)用→中間件→數(shù)據(jù)庫的包抄當(dāng)中，如果你發(fā)現(xiàn)其他都沒有問題，那很可能就是中間件的問題了。

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

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

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

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

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

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

① 有請求進(jìn)來，有多少個(gè)session來服務(wù)于請求。

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

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

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

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

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

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

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

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

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

數(shù)據(jù)庫遷移過程中需考慮數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)類型、數(shù)據(jù)庫性能、數(shù)據(jù)使用場景四個(gè)方面。數(shù)據(jù)庫結(jié)構(gòu)和數(shù)據(jù)類型是靜態(tài)數(shù)據(jù)，可以通過語法、語義比對完成調(diào)研，數(shù)據(jù)庫性能和數(shù)據(jù)使用場景是動(dòng)態(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)用各個(gè)模塊與數(shù)據(jù)庫調(diào)用SQL的兼容特點(diǎn)，明確應(yīng)用在各個(gè)模塊轉(zhuǎn)換的改造點(diǎn)。應(yīng)用調(diào)整的內(nèi)容取決于源、目標(biāo)數(shù)據(jù)庫架構(gòu)切換的狀態(tài)以及源數(shù)據(jù)庫與目標(biāo)數(shù)據(jù)庫的兼容度。通過調(diào)用SQL詳情實(shí)現(xiàn)改造點(diǎn)定位，即交互SQL點(diǎn)定位， 如應(yīng)用系統(tǒng)采用成熟框架，可以在框架中直接完成修改，如在代碼中直接嵌入SQL，若有成熟工具快速完成改造點(diǎn)定位和半自動(dòng)化實(shí)現(xiàn)改造樣本，將會(huì)極大方便改造工作。

5 結(jié)語

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