【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)”的過(guò)程中，如何才能提供更高的效能，將由金蝶天燕首席架構(gòu)師馬震為大家?guī)?lái)精彩分享。

一、     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 是通過(guò)收集目標(biāo)行為的樣本或快照，來(lái)了解目標(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)行采樣，來(lái)分析消耗CPU時(shí)間的代碼路徑?？梢曰诠潭ǖ臅r(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通過(guò)一個(gè)定期執(zhí)行的agent來(lái)記錄系統(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)核依賴的硬件，比如說(shuō)CPU，一般會(huì)內(nèi)置一些性能統(tǒng)計(jì)方面的寄存器（Hardware Performance Counter），通過(guò)軟件讀取這些特殊寄存器里的信息，我們也可以得到很多直接關(guān)于硬件的信息。perf最初就是用來(lái)監(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ù)值的變化：

上圖所示，通過(guò)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)的可通過(guò)回車進(jìn)行路徑的展開。

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

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

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

BPF：

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

BPF是運(yùn)行在內(nèi)核級(jí)進(jìn)行過(guò)濾，無(wú)需將數(shù)據(jù)包拷貝到用戶空間，因?yàn)樗趦?nèi)核可以直接過(guò)濾，所以提高了數(shù)據(jù)包過(guò)濾的性能。常用的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，來(lái)響應(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ì)匯總，以此大幅減少?gòu)?fù)制到用戶空間的數(shù)據(jù)量。

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

BCC和bpftrace：

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

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

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

BCC已經(jīng)包含70多個(gè)BPF工具，用于性能分析和故障排查。這些工具都可以直接使用，無(wú)需編寫任何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)，比如說(shuō)等待鎖，或者被進(jìn)程調(diào)度器（scheduler）剝奪了 CPU 的使用。這些情況都會(huì)導(dǎo)致這個(gè)進(jìn)程無(wú)法運(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í)間，如果通過(guò)off-CPU跟on-CPU相結(jié)合，即可了解線程所有的時(shí)間花費(fèi)，更為全面地了解程序的運(yùn)行情況。

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

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

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

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

1、 何為Stack trace：

Stack Trace是程序執(zhí)行過(guò)程中，在特定時(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ù)的寬度最大，說(shuō)明它可能存在性能問題。

如何使用系統(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)行情況無(wú)法抓取。

如果使用系統(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é)合了起來(lái)，同樣能夠獲得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é)合了起來(lái)，做到同時(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)用棧以及本地庫(kù)的調(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)存頁(yè)的大小為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庫(kù)的訪問；

·  中斷聚合參數(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庫(kù)的訪問；

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

·  關(guān)閉透明大頁(yè)；

·   配置高精度的虛擬機(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ù)庫(kù)連接池、EJB容器、線程池、日志模塊做進(jìn)一步的優(yōu)化。

數(shù)據(jù)庫(kù)連接池優(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解決過(guò)哪些實(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/

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lá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)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。