ARM處理器在數(shù)據(jù)中心中的應(yīng)用一直是一個(gè)熱門(mén)話題，我們很想看看他在PG中表現(xiàn)怎么樣。用于測(cè)試和評(píng)估基于ARM的服務(wù)器，其可用性一直是一個(gè)主要障礙，當(dāng)AWS 2018年宣布在他們的云中提供基于ARM的處理器時(shí)，轉(zhuǎn)機(jī)出現(xiàn)了。但是還不能太過(guò)激動(dòng)，因?yàn)楹芏嗳苏J(rèn)為這是個(gè)實(shí)驗(yàn)性的東西。我們也很謹(jǐn)慎將它推薦給關(guān)鍵用途，而且在測(cè)試時(shí)也沒(méi)太過(guò)用心。但是2020年5月Graviton2發(fā)布后，可以認(rèn)真考慮了。我們決定從PG運(yùn)行角度獨(dú)立研究實(shí)例的價(jià)格／性能。

要點(diǎn)：請(qǐng)注意，盡管在x86和arm上比較PG很有吸引力，但這是不正確的。這些測(cè)試比較了兩個(gè)虛擬云中的PG，保護(hù)的移動(dòng)部件不止CPU。我們主要關(guān)注基于兩種不同體系架構(gòu)的兩個(gè)特定AWS EC2實(shí)例的性?xún)r(jià)比。

測(cè)試設(shè)置

本測(cè)試中，選擇了兩個(gè)相似的是，一個(gè)是教老的m5d．5xlarge，一個(gè)是新型基于Graviton2的m6gd．8xlarge。兩個(gè)實(shí)例都有一個(gè)本地”短暫性”存儲(chǔ)。使用非�？焖俚谋镜仳�(qū)動(dòng)可有助于暴露系統(tǒng)其它部分的差異，并避免測(cè)試云存儲(chǔ)。這些實(shí)例并不是完全相同，正如下面看到的，但也非常接近，可以被認(rèn)為是相同級(jí)別。我們使用來(lái)自pgdg repo的PG13．1和ubuntu20．04 AMI，小內(nèi)存和大數(shù)據(jù)量進(jìn)行測(cè)試。

實(shí)例

實(shí)例的規(guī)范和按需定價(jià)，參考Northern Virginia region的定價(jià)信息，按目前的掛牌價(jià)格，m6gd．8xlarge便宜25％。

Graviton2 （arm） Instance：  Instance ： m6gd．8xlarge  Virtual CPUs ： 32  RAM  ： 128 GiB  Storage ： 1 x 1900 NVMe SSD （1．9 TiB）  Price ： ＄1．4464 per HourRegular （x86） Instance：  Instance ： m5d．8xlarge  Virtual CPUs ： 32  RAM ： 128 GiB  Storage ： 2 x 600 NVMe SSD （1．2 TiB）  Price ： ＄1．808 per Hour

操作系統(tǒng)及PG設(shè)置

我們選擇ubuntun20．04 LTS AMIS，操心系統(tǒng)上沒(méi)有做任何修改，在m5d．8xlarge上兩個(gè)本地的NVME SSD統(tǒng)一在一個(gè)raid0中。PG使用PGDG存儲(chǔ)庫(kù)中提供的．deb包進(jìn)行安裝。

postgres＝＃ select version（）；                                                                version                                                                 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ PostgreSQL 13．1 （Ubuntu 13．1－1．pgdg20．04＋1） on aarch64－unknown－linux－gnu， compiled by gcc （Ubuntu 9．3．0－17ubuntu1～20．04） 9．3．0， 64－bit（1 row）

aarch64 表示64位的ARM架構(gòu)。

下面是PG配置：

max＿connections ＝ ＇200＇shared＿buffers ＝ ＇32GB＇checkpoint＿timeout ＝ ＇1h＇max＿wal＿size ＝ ＇96GB＇checkpoint＿completion＿target ＝ ＇0．9＇archive＿mode ＝ ＇on＇archive＿command ＝ ＇／bin／true＇random＿page＿cost ＝ ＇1．0＇effective＿cache＿size ＝ ＇80GB＇maintenance＿work＿mem ＝ ＇2GB＇autovacuum＿vacuum＿scale＿factor ＝ ＇0．4＇bgwriter＿lru＿maxpages ＝ ＇1000＇bgwriter＿lru＿multiplier ＝ ＇10．0＇wal＿compression ＝ ＇ON＇log＿checkpoints ＝ ＇ON＇log＿autovacuum＿min＿duration ＝ ＇0＇

Pgbench進(jìn)行測(cè)試

執(zhí)行命令：pgbench －c 16 －j 16 －T 600 －r

16個(gè)客戶(hù)端連接和16個(gè)pgbench job。

無(wú)checksum的讀寫(xiě)

在ARM上有19％的提升．

有checksum的讀寫(xiě)

Checksum計(jì)算會(huì)因架構(gòu)不同而有不同性能嗎？開(kāi)啟PG checksum命令：pg＿checksums －e －D ＄PGDATA

令人驚訝的是，結(jié)果稍微好點(diǎn)，不同只有1．7％，可以認(rèn)為是噪聲。至少可以得出這樣的結(jié)論：在現(xiàn)代處理器上，啟用checksum不會(huì)有明顯的性能下降。

無(wú)checksum的只讀

指定負(fù)載可以認(rèn)為是CPU型，因數(shù)據(jù)大小能夠全部放到內(nèi)存，消除了IO影響。ARM下有30％的提升。

有checksum的只讀

同樣類(lèi)似，有30％的提升。Checksum也沒(méi)帶來(lái)性能衰減。

注意：當(dāng)PG從緩沖池讀取或?qū)懗鰰r(shí)會(huì)計(jì)算checksum并寫(xiě)入頁(yè)。另外啟用checksum后，總是會(huì)記錄hint bits，增加了WAL IO的壓力。為了爭(zhēng)取驗(yàn)證checksum開(kāi)銷(xiāo)，需要更長(zhǎng)更大的測(cè)試，就行增加對(duì)sysbench tpcc所做的一樣。

sysbench－tpcc進(jìn)行測(cè)試

我們決定使用sysbench－tpcc執(zhí)行更詳細(xì)的測(cè)試。注意感興趣的是數(shù)據(jù)可全放到內(nèi)存的情況。另一方面，雖然ARM服務(wù)器上PG沒(méi)有問(wèn)題，但是與x86服務(wù)器相比，sysbench根據(jù)挑剔。

每個(gè)測(cè)試執(zhí)行下面步驟：

1）restore必要規(guī)模的數(shù)據(jù)目錄（10／200）

2）用相同參數(shù)進(jìn)行10分鐘預(yù)熱

3）PG端checkpoint

4）進(jìn)行測(cè)試

16個(gè)線程，在內(nèi)存

這種中等負(fù)載下，ARM實(shí)例性能提升了15．5％。此處及之后結(jié)果，百分比差異基于平均TPS值。

可能會(huì)思考，為什么測(cè)試在結(jié)束時(shí)性能會(huì)突然下降。他與full＿page＿writes的checkpoint有關(guān)。即使對(duì)于內(nèi)存測(cè)試，使用了pareto分布，但是每個(gè)checkpoint后仍會(huì)寫(xiě)出相當(dāng)多的頁(yè)面。本實(shí)例中，顯示W(wǎng)AL早于對(duì)應(yīng)點(diǎn)觸發(fā)checkpoint，所有進(jìn)行的測(cè)試都會(huì)有這種下降。

32個(gè)線程，在內(nèi)存

32個(gè)線程下，性能的不同減小到了將近8％。

64個(gè)線程，在內(nèi)存

64個(gè)下，減小到了4．5％。

128個(gè)線程，在內(nèi)存

兩個(gè)實(shí)例超過(guò)飽和點(diǎn)，性能差異就很小了。經(jīng)仍保持在1．4％水平。此外可以看到ARM的tps下降了6－7％，在x86上下降了4％。

并不是所有測(cè)試都有利于Graviton2的實(shí)例。在IO綁定測(cè)試中，看到兩個(gè)實(shí)例之間的差異很小，64個(gè)128個(gè)線程上，常規(guī)的m5d實(shí)例性能更好，從下面組合圖上可看到這一點(diǎn)：

造成這種情況的一個(gè)可能原因，特別對(duì)于m6gd．8xlarge的128線程上的嚴(yán)重衰減，是因?yàn)槿鄙賛5d．8xlarge所擁有的第二個(gè)驅(qū)動(dòng)器。目前還沒(méi)有完全可比較的實(shí)例可用，因此我們認(rèn)為這是一個(gè)比較公平的測(cè)試。每個(gè)實(shí)例類(lèi)型都有一定優(yōu)勢(shì)。需要更多測(cè)試和分析�？梢允褂肊BS執(zhí)行IO綁定測(cè)試，以嘗試刪除本地驅(qū)動(dòng)器。

有關(guān)測(cè)試設(shè)置、結(jié)果、使用腳本和測(cè)試之間生產(chǎn)的數(shù)據(jù)的更詳細(xì)信息，訪問(wèn)https：／／github．com／arronax／scratch／tree／master／performance／graviton2－postgres

總結(jié)

執(zhí)行測(cè)試中，ARM實(shí)例比x86慢的情況不多。過(guò)去的幾天測(cè)試中，結(jié)果一致。雖然基于ARM的實(shí)例便宜了25％，但與x86相比，能夠在大多數(shù)測(cè)試中有15－20％的提升。因此基于ARM的實(shí)例在各方面提供了更好的性?xún)r(jià)比。

討論的郵件列表：

https：／／news．ycombinator．com／item？id＝25875342