【HDC.Cloud】Web應(yīng)用在鯤鵬上的性能優(yōu)化及加速技術(shù)實(shí)踐

隨著互聯(lián)網(wǎng)的興起,Web技術(shù)逐漸成為主流,各種技術(shù)流派蓬勃發(fā)展,當(dāng)Web遇上鯤鵬又會(huì)發(fā)生哪些事情?

金蝶天燕作為中國(guó)領(lǐng)先的軟件基礎(chǔ)設(shè)施提供商,其業(yè)務(wù)主要涵蓋政府財(cái)政財(cái)務(wù)應(yīng)用、政務(wù)大數(shù)據(jù)服務(wù)、云基礎(chǔ)設(shè)施等領(lǐng)域,在共建“鯤鵬生態(tài)”的過程中,如何才能提供更高的效能,將由金蝶天燕首席架構(gòu)師馬震為大家?guī)砭史窒怼?/p>

一、     Web服務(wù)器架構(gòu)分解

Connector和Engine是Tomcat最核心的兩個(gè)組件。

Connector負(fù)責(zé)處理網(wǎng)絡(luò)通信,以及應(yīng)用層協(xié)議(HTTP,AJP)的解析,生成標(biāo)準(zhǔn)的ServletRequest和ServletResponse對(duì)象,然后傳遞給Engine處理。每個(gè)Connector監(jiān)聽不同的網(wǎng)絡(luò)端口。

Connector支持多種 I/O 模型:

· NIO:使用Java NIO實(shí)現(xiàn)

· NIO.2:異步I/O,使用JDK NIO.2實(shí)現(xiàn)

·  APR:使用了Apache Portable Runtime (APR)實(shí)現(xiàn)

Engine代表整個(gè)Servlet引擎,可以包含多個(gè)Host,表示它可以管理多個(gè)虛擬站點(diǎn)。Host代表的是一個(gè)虛擬主機(jī),而一個(gè)虛擬主機(jī)下可以部署多個(gè)Web應(yīng)用程序,Context表示一個(gè)Web應(yīng)用程序。Wrapper表示一個(gè)Servlet,一個(gè)Web應(yīng)用程序中可能會(huì)有多個(gè)Servlet。

二、     Web調(diào)優(yōu)與加速技術(shù)

對(duì)于跑在Web容器里的應(yīng)用進(jìn)行調(diào)優(yōu),首先要對(duì)應(yīng)用的性能進(jìn)行剖析。Linux平臺(tái)性能分析的技術(shù)和工具可以分為以下四類:

1、 Counter:

內(nèi)核維護(hù)各種統(tǒng)計(jì)信息就會(huì)被稱為Counter,它用于對(duì)事件進(jìn)行計(jì)數(shù),例如網(wǎng)絡(luò)接收數(shù)據(jù)包的數(shù)據(jù)量,發(fā)出的磁盤I/O請(qǐng)求,以及執(zhí)行的系統(tǒng)調(diào)用次數(shù),均用作統(tǒng)計(jì)次數(shù),而常用工具是vmstat、mpstat、iostat、netstat。 

2、 Tracing:

是收集每個(gè)事件的數(shù)據(jù)進(jìn)行分析,Tracing會(huì)捕捉所有事件進(jìn)行分析,對(duì)CPU的開銷消耗較大,例如常用的TCPdump會(huì)把網(wǎng)絡(luò)通訊包根據(jù)設(shè)置的條件全部抓包,包括blktrace對(duì)block進(jìn)行Tracing,包括strace對(duì)系統(tǒng)調(diào)用進(jìn)行的Tracing,屬于常用的Tracing工具。

3、Profiling:

Tracing會(huì)抓取所有數(shù)據(jù),而Profiling只進(jìn)行采樣。Profiling 是通過收集目標(biāo)行為的樣本或快照,來了解目標(biāo)的特征。Profiling可以從多個(gè)方面對(duì)程序進(jìn)行動(dòng)態(tài)分析,如CPU、Memory、Thread、I/O等,其中對(duì)CPU進(jìn)行Profiling的應(yīng)用最為廣泛。

CPU Profiling原理是基于一定頻率對(duì)運(yùn)行的程序進(jìn)行采樣,來分析消耗CPU時(shí)間的代碼路徑。可以基于固定的時(shí)間間隔進(jìn)行采樣,例如每10毫秒采樣一次。也可以設(shè)置固定速率采樣,例如每秒采集100個(gè)樣本。

CPU Profiling經(jīng)常被用于分析代碼的熱點(diǎn),比如“哪個(gè)方法占用CPU的執(zhí)行時(shí)間最長(zhǎng)”、“每個(gè)方法占用CPU的比例是多少”等等,然后我們就可以針對(duì)熱點(diǎn)瓶頸進(jìn)行分析和性能優(yōu)化。

Linux上常用的CPU Profiling工具有:perf的 record 子命令和BPF profile。

4、Monitoring:

系統(tǒng)性能監(jiān)控會(huì)記錄一段時(shí)間內(nèi)的性能統(tǒng)計(jì)信息,以便能夠基于時(shí)間周期進(jìn)行比較。這對(duì)于容量規(guī)劃,了解高峰期的使用情況都很有幫助。歷史值還為我們理解當(dāng)前的性能指標(biāo)提供了上下文。

監(jiān)控單個(gè)操作系統(tǒng)最常用工具是sar(system activity reporter,系統(tǒng)活動(dòng)報(bào)告)命令。sar通過一個(gè)定期執(zhí)行的agent來記錄系統(tǒng)計(jì)數(shù)器的狀態(tài),并可以使用sar命令查看它們。

本文主要討論如何使用perf和BPF進(jìn)行CPU Profiling。

perf:

perf最初是使用Linux性能計(jì)數(shù)器子系統(tǒng)的工具,因此perf開始的名稱是Performance Counters for Linux(PCL)。perf在Linux2.6.31合并進(jìn)內(nèi)核,位于tools/perf目錄下。

隨后perf進(jìn)行了各種增強(qiáng),增加了tracing、profiling等能力,可用于性能瓶頸的查找和熱點(diǎn)代碼的定位。

perf是一個(gè)面向事件(event-oriented)的性能剖析工具,因此它也被稱為L(zhǎng)inux perf events (LPE),或perf_events。

perf的整體架構(gòu)如下:

perf 由兩部分組成:

·  perf Tools:perf用戶態(tài)命令,為用戶提供了一系列工具集,用于收集、分析性能數(shù)據(jù)。

·  perf Event Subsystem:Perf Events是內(nèi)核的子系統(tǒng)之一,和用戶態(tài)工具共同完成數(shù)據(jù)的采集。

內(nèi)核依賴的硬件,比如說CPU,一般會(huì)內(nèi)置一些性能統(tǒng)計(jì)方面的寄存器(Hardware Performance Counter),通過軟件讀取這些特殊寄存器里的信息,我們也可以得到很多直接關(guān)于硬件的信息。perf最初就是用來監(jiān)測(cè)CPU的性能監(jiān)控單元(performance monitoring unit, PMU)的。

perf支持多種性能事件:

這些性能事件分類為:

·   Hardware Events: CPU性能監(jiān)控計(jì)數(shù)器performance monitoring counters(PMC),也被稱為performance monitoring unit(PMU)

·   Software Events: 基于內(nèi)核計(jì)數(shù)器的底層事件。例如,CPU遷移,minor faults,major faults等。

·   Kernel Tracepoint Events: 內(nèi)核的靜態(tài)Tracepoint,已經(jīng)硬編碼在內(nèi)核需要收集信息的位置。

·   User Statically-Defined Tracing (USDT): 用戶級(jí)程序的靜態(tài)Tracepoint。

·   Dynamic Tracing: 用戶自定義事件,可以動(dòng)態(tài)的插入到內(nèi)核或正在運(yùn)行中的程序。Dynamic Tracing技術(shù)分為兩類:

    - kprobes:對(duì)于kernel的動(dòng)態(tài)追蹤技術(shù),可以動(dòng)態(tài)地在指定的內(nèi)核函數(shù)的入口和出口等位置上放置探針,并定義自己的探針處理程序。

    - uprobes:對(duì)于用戶態(tài)軟件的動(dòng)態(tài)追蹤技術(shù),可以安全地在用戶態(tài)函數(shù)的入口等位置設(shè)置動(dòng)態(tài)探針,并執(zhí)行自己的探針處理程序。

perf的功能強(qiáng)大,支持硬件計(jì)數(shù)器統(tǒng)計(jì),定時(shí)采樣,靜態(tài)和動(dòng)態(tài)tracing等。本文只介紹幾個(gè)常用的使用場(chǎng)景。

1. Couting Mode:

使用perf的stat命令可以收集性能計(jì)數(shù)器統(tǒng)計(jì)信息,精確統(tǒng)計(jì)一段時(shí)間內(nèi) CPU 相關(guān)硬件計(jì)數(shù)器數(shù)值的變化:

上圖所示,通過perf stat執(zhí)行一個(gè)命令,執(zhí)行完畢后,可以看到命令執(zhí)行時(shí)長(zhǎng)12秒,同時(shí)顯示上下文切換次數(shù)、CPU周期次數(shù),以及多少指令和分支,可從中獲取更多幫助信息。

2. Sampling Mode

可以使用perf record以任意頻率收集快照。這通常用于CPU使用情況的分析。

·   sudo perf record -F 99 -a -g sleep 10

對(duì)所有CPU(-a)進(jìn)行call stacks(-g)采樣,采樣頻率為99 Hertz(-F 99),即每秒99次,持續(xù)10秒(sleep 10)。

·   sudo perf record -F 99 -a -g -p PID sleep 10

對(duì)指定進(jìn)程(-p PID)進(jìn)行采樣。

·   sudo perf record -F 99 -a -g -e context-switches -p PID sleep 10

perf可以和各種instrumentation points一起使用,以跟蹤內(nèi)核調(diào)度程序(scheduler)的活動(dòng)。其中包括software events和tracepoint event(靜態(tài)探針)。

上面的例子對(duì)指定進(jìn)程的上下文切換(-e context-switches)進(jìn)行采樣。

perf record的運(yùn)行結(jié)果保存在當(dāng)前目錄的perf.data文件中,采樣結(jié)束后,我們使用perf report查看結(jié)果。

交互查看模式:

直接執(zhí)行perf report,將采樣數(shù)據(jù)進(jìn)行加載,此時(shí)運(yùn)行的是交互式模式,針對(duì)不同的代碼路徑,統(tǒng)計(jì)出百分比,前綴帶+號(hào)的可通過回車進(jìn)行路徑的展開。

通過交互模式進(jìn)行分析,可先從占用CPU時(shí)間最多的代碼路徑開始分析,看哪里占用的CPU時(shí)間多,是否能夠進(jìn)行優(yōu)化。

統(tǒng)計(jì)模式:

使用--stdio選項(xiàng)打印所有輸出。運(yùn)行結(jié)束后,會(huì)將所有的代碼路徑展開,每一個(gè)代碼路徑上的CPU的消耗時(shí)間都會(huì)顯示出來。

BPF:

BPF作為系統(tǒng)級(jí)的性能分析工具,最初是為BSD開發(fā),是用來改進(jìn)網(wǎng)絡(luò)數(shù)據(jù)包捕獲性能的工具。

BPF是運(yùn)行在內(nèi)核級(jí)進(jìn)行過濾,無需將數(shù)據(jù)包拷貝到用戶空間,因?yàn)樗趦?nèi)核可以直接過濾,所以提高了數(shù)據(jù)包過濾的性能。常用的tcpdump內(nèi)部使用的就是BPF。

2013年BPF被重寫,被稱為Extended BPF (eBPF),于2014年包含進(jìn)Linux內(nèi)核中。改進(jìn)后的BPF成為了通用執(zhí)行引擎,可用于多種用途,包括創(chuàng)建高級(jí)性能分析工具。

BPF允許在內(nèi)核中運(yùn)行mini programs,來響應(yīng)系統(tǒng)和應(yīng)用程序事件(例如磁盤I/O事件)。這種運(yùn)作機(jī)制和JavaScript類似:JavaScript是運(yùn)行在瀏覽器引擎中的mini programs,響應(yīng)鼠標(biāo)點(diǎn)擊等事件。BPF使內(nèi)核可編程化,使用戶(包括非內(nèi)核開發(fā)人員)能夠自定義和控制他們的系統(tǒng),以解決實(shí)際問題。

BPF可以被認(rèn)為是一個(gè)虛擬機(jī),由指令集,存儲(chǔ)對(duì)象和helper函數(shù)三部分組成。BPF指令集由位于Linux內(nèi)核的BPF runtime執(zhí)行,BPF runtime包括了解釋器和JIT編譯器。BPF是一種靈活高效的技術(shù),可以用于networking,tracing和安全等領(lǐng)域。我們重點(diǎn)關(guān)注它作為系統(tǒng)監(jiān)測(cè)工具方面的應(yīng)用。

BPF的優(yōu)勢(shì):

由于BPF的迷你程序是運(yùn)行在內(nèi)核,所以可在內(nèi)核進(jìn)行計(jì)算的統(tǒng)計(jì)匯總,以此大幅減少復(fù)制到用戶空間的數(shù)據(jù)量。

BPF已經(jīng)內(nèi)置在Linux內(nèi)核中,因此你無需再安裝任何新的內(nèi)核組件,就可以在生產(chǎn)環(huán)境中使用BPF。

BCC和bpftrace:

直接使用BPF指令進(jìn)行編程非常繁瑣,因此很有必要提供高級(jí)語言前端方便用戶使用,于是就出現(xiàn)了BCC和bpftrace。

BCC(BPF Compiler Collection) 提供了一個(gè)C編程環(huán)境,使用LLVM工具鏈來把 C 代碼編譯為BPF虛擬機(jī)所接受的字節(jié)碼。此外它還支持Python,Lua和C++作為用戶接口。

bpftrace 是一個(gè)比較新的前端,它為開發(fā)BPF工具提供了一種專用的高級(jí)語言。bpftrace適合單行代碼和自定義短腳本,而BCC更適合復(fù)雜的腳本和守護(hù)程序。

BCC已經(jīng)包含70多個(gè)BPF工具,用于性能分析和故障排查。這些工具都可以直接使用,無需編寫任何BCC代碼。

BCC已經(jīng)自帶了CPU profiling工具:

一般的CPU profiling都是分析on-CPU,即CPU時(shí)間都花費(fèi)在了哪些代碼路徑。off-CPU是指進(jìn)程不在CPU上運(yùn)行時(shí)所花費(fèi)的時(shí)間,進(jìn)程因?yàn)槟撤N原因處于休眠狀態(tài),比如說等待鎖,或者被進(jìn)程調(diào)度器(scheduler)剝奪了 CPU 的使用。這些情況都會(huì)導(dǎo)致這個(gè)進(jìn)程無法運(yùn)行在 CPU 上,但是仍然花費(fèi)了時(shí)間。

off-CPU是針對(duì)on-CPU的補(bǔ)充,on-CPU分析的是什么正在CPU上運(yùn)行,off-CPU分析的是進(jìn)程由于某種原因處于休眠狀態(tài),如磁盤阻塞、等待網(wǎng)絡(luò)事件、被鎖阻塞或時(shí)間片用完而被切換。此時(shí)雖然沒有在CPU上運(yùn)行,但仍然花費(fèi)時(shí)間,如果通過off-CPU跟on-CPU相結(jié)合,即可了解線程所有的時(shí)間花費(fèi),更為全面地了解程序的運(yùn)行情況。

抓取的采樣如何更好地展示與分析——火焰圖:

火焰圖是Brendan Gregg發(fā)明的將stack traces可視化展示的方法?;鹧鎴D把時(shí)間和空間兩個(gè)維度上的信息融合在一張圖上,將頻繁執(zhí)行的代碼路徑以可視化的形式,非常直觀的展現(xiàn)了出來。

火焰圖可以用于可視化來自任何profiler工具的記錄的stack traces信息,除了用來CPU profiling,還適用于off-CPU,page faults等多種場(chǎng)景的分析。本文只討論 on-CPU 和 off-CPU 火焰圖的生成。

要理解火焰圖,先從理解Stack Trace開始。

1、 何為Stack trace:

Stack Trace是程序執(zhí)行過程中,在特定時(shí)間點(diǎn)的函數(shù)調(diào)用列表。例如,func_a()調(diào)用func_b(),func_b()調(diào)用func_c(),此時(shí)的Stack Trace可寫為:

func_c

func_b

func_a

2、 profilingStack trace的含義是什么:

我們做CPU profiling時(shí),會(huì)使用perf或bcc定時(shí)采樣Stack Trace,這樣會(huì)收集到非常多的Stack Trace。前面介紹了perf report會(huì)將Stack Trace樣本匯總為調(diào)用樹,并顯示每個(gè)路徑的百分比。火焰圖是怎么展示的呢?

考慮下面的示例,我們用perf定時(shí)采樣收集了多個(gè)Stack Trace,然后將相同的Stack Trace歸納合并,統(tǒng)計(jì)出次數(shù)。

如圖右側(cè)所示,共采集了10個(gè)樣本,第一個(gè)代碼路徑func_a調(diào)用func_b調(diào)用func_c,有7個(gè)樣本。第二個(gè)路徑a調(diào)用b有2個(gè)樣本,第三個(gè)路徑有1個(gè)樣本。

此時(shí),將相同的Stack trace進(jìn)行歸納合并,統(tǒng)計(jì)成圖右側(cè)格式,即可使用火焰圖工具生成火焰圖。

火焰圖具有以下特性:

·   每個(gè)長(zhǎng)方塊代表了函數(shù)調(diào)用棧中的一個(gè)函數(shù)

·   Y 軸顯示堆棧的深度(堆棧中的幀數(shù))。調(diào)用棧越深,火焰就越高。頂層方塊表示 CPU 上正在運(yùn)行的函數(shù),下面的函數(shù)即為它的祖先。

·   X 軸的寬度代表被采集的樣本數(shù)量,越寬表示采集到的越多,即執(zhí)行的時(shí)間長(zhǎng)。需要注意的是,X軸從左到右不代表時(shí)間,而是所有的調(diào)用棧合并后,按字母順序排列的。

拿到火焰圖,尋找最寬的塔并首先了解它們。頂層的哪個(gè)函數(shù)占據(jù)的寬度最大,說明它可能存在性能問題。

如何使用系統(tǒng)工具分析Java的CPU Profiling:

雖然有很多Java專用的profiler工具,但這些工具一般只能看到Java方法的執(zhí)行,缺少了GC,JVM的CPU時(shí)間消耗,并且有些工具的Method tracing性能損耗比較大。

perf和BCC profile的優(yōu)點(diǎn)是它很高效,在內(nèi)核上下文中對(duì)堆棧進(jìn)行計(jì)數(shù),并能完整顯示用戶態(tài)和內(nèi)核態(tài)的CPU使用,能看到native libraries(例如libc),JVM(libjvm),Java方法和內(nèi)核中花費(fèi)的時(shí)間。

profiling圖:

如果使用傳統(tǒng)的java profiling工具,可能只看到中間部分,即Java的調(diào)用棧的情況,而對(duì)于GC、JVM以及內(nèi)核的運(yùn)行情況無法抓取。

如果使用系統(tǒng)工具即可抓取進(jìn)程全貌,而進(jìn)行更全面的分析。

但是,perf和BCC profile不能很好地與Java配合使用:

它們識(shí)別不了Java方法和stack traces

具體原因:

·  JVM的JIT(just-in-time)沒有給系統(tǒng)級(jí)profiler公開符號(hào)表。

·   VM還使用幀指針寄存器(frame pointer register)作為通用寄存器,打破了傳統(tǒng)的堆棧遍歷。

目前有兩種解決方案:

1、 使用perf-map-agent:

使用JVMTI agent perf-map-agent,生成Java符號(hào)表,供perf和bcc讀?。?tmp/perf-PID.map)。同時(shí)要加上-XX:+PreserveFramePointer JVM 參數(shù),讓perf可以遍歷基于幀指針(frame pointer)的堆棧。

2、 使用async-profiler:

使用async-profiler,該項(xiàng)目將perf的堆棧追蹤和JDK提供的AsyncGetCallTrace結(jié)合了起來,同樣能夠獲得mixed-mode火焰圖。同時(shí),此方法不需要啟用幀指針,所以不用加上-XX:+PreserveFramePointer參數(shù)。

以上兩種方式均可畫出完整的Java火焰圖。

下面我們就分別演示這兩種方式。

perf-map-agent+perf :

用perf-map-agent為perf生成符號(hào)表,同時(shí)perf-map-agent也提供了perf-java-flames腳本,可以一步生成火焰圖。

perf-java-flames接收perf record命令參數(shù),它會(huì)調(diào)用perf進(jìn)行采樣,然后使用FlameGraph生成火焰圖,一步完成,非常方便。

perf-map-agent+ bcc profile :

同樣使用perf-map-agent生成符號(hào)表,然后調(diào)用bcc profile進(jìn)行采樣,生成火焰圖。因?yàn)閎cc提供了off-cpu的分析,也可以生成off-cpu的火焰圖。

async-profiler:

async-profiler將perf的堆棧追蹤和JDK提供的AsyncGetCallTrace結(jié)合了起來,做到同時(shí)采樣Java棧與Native棧,因此也就可以同時(shí)分析Java代碼和Native代碼中存在的性能熱點(diǎn)。

async-profile提供命令行工具,只需指定持續(xù)的時(shí)間以及進(jìn)程ID,即可一步生成火焰圖。

async-profiler繪制的火焰圖:

如圖所示,綠色代表Java的調(diào)用棧,同時(shí)可以看到內(nèi)核調(diào)用棧以及本地庫的調(diào)用棧,同時(shí)顯示在一張圖上,可以更全面的分析Java程序的CPU使用情況。

Java CPU Profiling——總結(jié)

為Java進(jìn)程生成CPU火焰圖基本流程的三步:

·   使用工具采集樣本;

·  不論perf或BCC,完成樣本采集后使用火焰圖項(xiàng)目中提供的腳本,將樣本進(jìn)行歸納合并,統(tǒng)計(jì)出Stack trace的出現(xiàn)頻率,將Stack trace進(jìn)行匯總;

·   匯總完成后使用腳本根據(jù)上一步的結(jié)果繪制出火焰圖。

以下兩種方式可繪制出Java Stacks和native stacks的完整火焰圖

·  如果只對(duì)javaprofiler進(jìn)行on-CPU分析,async-profiler更為方便,可一步生成火焰圖;

·   如果需要全面了解Java進(jìn)程運(yùn)行情況,不僅要分析on-CPU,且同時(shí)分析系統(tǒng)鎖的開銷、I/O的開銷以及scheduler的工作,此時(shí)還需使用perf和BCC工具做分析。

三、     基于鯤鵬的深度優(yōu)化

CPU與內(nèi)存:

·   NUMA的優(yōu)化,即盡量減少跨NUMA的內(nèi)存訪問;

·   修改CPU的預(yù)取開;

·  定時(shí)器機(jī)制調(diào)整, 減少不必要的時(shí)鐘中斷;

·   調(diào)整內(nèi)存頁的大小為64K,translation目前是4k的,調(diào)整到64K以后,可以提高TLB的命中率;

·  調(diào)整線程并發(fā)數(shù)

以上是對(duì)CPU還有內(nèi)存的調(diào)優(yōu)。

磁盤:

·   調(diào)整臟數(shù)據(jù)刷新策略,減小磁盤的IO壓力;

·   調(diào)整磁盤文件預(yù)讀參數(shù);

·   優(yōu)化磁盤IO調(diào)度方式,I/O調(diào)度需要根據(jù)具體的應(yīng)用情況選擇合適的磁盤I/O調(diào)度算法;

·   文件系統(tǒng)參數(shù)優(yōu)化;

·   使用異步文件操作libaio提升系統(tǒng)性能

以上是對(duì)磁盤部分的調(diào)優(yōu)。

·  PCIE Max Payload Size大小配置;

·  網(wǎng)絡(luò)NUMA綁核,減少跨CPU庫的訪問;

·  中斷聚合參數(shù)調(diào)整;

·  開啟TSO,把TCP分段的卸載處理交給網(wǎng)卡,減少CPU的運(yùn)算;

·   使用epoll代替select

以上是對(duì)網(wǎng)絡(luò)部分的優(yōu)化方法。

我們做性能測(cè)試時(shí)候具體用到的幾種優(yōu)化:

·   配置虛擬機(jī)獨(dú)占NUMA,即盡量減少跨CPU庫的訪問;

·   配置了增強(qiáng)型的大頁內(nèi)存;

·  關(guān)閉透明大頁;

·   配置高精度的虛擬機(jī);

·  最后一個(gè)是JDK對(duì)GC葉子節(jié)點(diǎn)的優(yōu)化,這個(gè)是鯤鵬JDK特有的優(yōu)化。

操作系統(tǒng)的TCP協(xié)議站配置:

主要是調(diào)整了發(fā)送和接收的緩沖器的大小,調(diào)整backlog隊(duì)列,避免隊(duì)列不夠的情況發(fā)生。

文件進(jìn)程及網(wǎng)卡調(diào)整:

調(diào)整文件進(jìn)程,開啟網(wǎng)卡多隊(duì)列。

四、     技術(shù)優(yōu)化方向與展望

后面我們將對(duì)數(shù)據(jù)庫連接池、EJB容器、線程池、日志模塊做進(jìn)一步的優(yōu)化。

數(shù)據(jù)庫連接池優(yōu)化:

主要是增強(qiáng)連接池的監(jiān)控,簡(jiǎn)化連接池的配置。

EJB容器優(yōu)化:

改進(jìn)底層的IO模型,提高EJB遠(yuǎn)程調(diào)用的性能。

應(yīng)用服務(wù)器http線程池優(yōu)化:

HTTP線程池,與連接池類似,增加更詳盡的監(jiān)控特性,讓配置更簡(jiǎn)化。

日志模塊優(yōu)化:

日志模塊同時(shí)進(jìn)行一些優(yōu)化,以此提高性能。

提問&解答:

Q:統(tǒng)計(jì)動(dòng)作可以在內(nèi)核完成嗎?

A:如果BPF的話,統(tǒng)計(jì)是可以的,因?yàn)槲覀兛梢岳斫鉃锽PF run time就是運(yùn)行在內(nèi)核態(tài)的一個(gè)虛擬機(jī),小程序編譯成BPF字節(jié)碼加載到了內(nèi)核,然后可以運(yùn)行統(tǒng)計(jì)以及計(jì)算。

Q:traceing的優(yōu)勢(shì)是什么?

A: traceing優(yōu)勢(shì)比較全面,因?yàn)樗鼤?huì)抓取所有數(shù)據(jù)。采樣只會(huì)采集部分?jǐn)?shù)據(jù),例如一秒鐘進(jìn)行99次采樣,此時(shí)可能會(huì)出現(xiàn)采樣數(shù)據(jù)不全的問題,但采樣對(duì)程序的影響非常小,損失只在2、3%左右的樣子。如果對(duì)java進(jìn)行traceing的話,影響非常大,可能不能真實(shí)地反映出這個(gè)程序的運(yùn)行狀況,這就兩者之間的對(duì)比。

Q:我們用perf和BPF解決過哪些實(shí)際的問題?

A:我們?cè)诋a(chǎn)品在發(fā)布之前都會(huì)做一些性能的測(cè)試,此時(shí)用perf或者BPF去抓取火焰圖,相當(dāng)于對(duì)運(yùn)行的進(jìn)程拍了一個(gè)X光,內(nèi)部狀況一目了然。可以對(duì)熱點(diǎn)代碼進(jìn)行分析。例如有些地方中還在使用傳統(tǒng)的同步的數(shù)據(jù)結(jié)構(gòu),那我們可以換成并發(fā)數(shù)據(jù)結(jié)構(gòu),比如ConcurrentHashMap。還有一些對(duì)鎖的使用問題,由于使用方法不對(duì),會(huì)拋出很多異常,這時(shí)在火焰圖里也能明顯地看到很寬的山峰,再去仔細(xì)分析代碼的時(shí)候就可以發(fā)現(xiàn)且容易定位到系統(tǒng)問題。

更多Web應(yīng)用的優(yōu)化內(nèi)容:https://www.huaweicloud.com/kunpeng/


極客網(wǎng)企業(yè)會(huì)員

免責(zé)聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請(qǐng)進(jìn)一步核實(shí),并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏,概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí),應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明,并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后,將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí),溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。

2020-04-07
【HDC.Cloud】Web應(yīng)用在鯤鵬上的性能優(yōu)化及加速技術(shù)實(shí)踐
隨著互聯(lián)網(wǎng)的興起,Web技術(shù)逐漸成為主流,各種技術(shù)流派蓬勃發(fā)展,當(dāng)Web遇上鯤鵬又會(huì)發(fā)生哪些事情?金蝶天燕作為中國(guó)領(lǐng)先的軟件基礎(chǔ)設(shè)施提供商,其業(yè)務(wù)主要涵蓋政府財(cái)政財(cái)務(wù)應(yīng)用、政務(wù)大數(shù)據(jù)服務(wù)、云基礎(chǔ)設(shè)施等領(lǐng)域,在共建“鯤鵬生態(tài)”的過程中,如何才能提供更高的效能,將由金蝶天燕首席架構(gòu)師馬震為大家?guī)砭史窒怼?/div>

長(zhǎng)按掃碼 閱讀全文