ARM處理器在數據中心中的應用一直是一個熱門話題，我們很想看看他在PG中表現怎么樣。用于測試和評估基于ARM的服務器，其可用性一直是一個主要障礙，當AWS 2018年宣布在他們的云中提供基于ARM的處理器時，轉機出現了。但是還不能太過激動，因為很多人認為這是個實驗性的東西。我們也很謹慎將它推薦給關鍵用途，而且在測試時也沒太過用心。但是2020年5月Graviton2發布后，可以認真考慮了。我們決定從PG運行角度獨立研究實例的價格／性能。

要點：請注意，盡管在x86和arm上比較PG很有吸引力，但這是不正確的。這些測試比較了兩個虛擬云中的PG，保護的移動部件不止CPU。我們主要關注基于兩種不同體系架構的兩個特定AWS EC2實例的性價比。

測試設置

本測試中，選擇了兩個相似的是，一個是教老的m5d．5xlarge，一個是新型基于Graviton2的m6gd．8xlarge。兩個實例都有一個本地”短暫性”存儲。使用非常快速的本地驅動可有助于暴露系統其它部分的差異，并避免測試云存儲。這些實例并不是完全相同，正如下面看到的，但也非常接近，可以被認為是相同級別。我們使用來自pgdg repo的PG13．1和ubuntu20．04 AMI，小內存和大數據量進行測試。

實例

實例的規范和按需定價，參考Northern Virginia region的定價信息，按目前的掛牌價格，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

操作系統及PG設置

我們選擇ubuntun20．04 LTS AMIS，操心系統上沒有做任何修改，在m5d．8xlarge上兩個本地的NVME SSD統一在一個raid0中。PG使用PGDG存儲庫中提供的．deb包進行安裝。

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架構。

下面是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進行測試

執行命令：pgbench －c 16 －j 16 －T 600 －r

16個客戶端連接和16個pgbench job。

無checksum的讀寫

在ARM上有19％的提升．

有checksum的讀寫

Checksum計算會因架構不同而有不同性能嗎？開啟PG checksum命令：pg＿checksums －e －D ＄PGDATA

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

無checksum的只讀

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

有checksum的只讀

同樣類似，有30％的提升。Checksum也沒帶來性能衰減。

注意：當PG從緩沖池讀取或寫出時會計算checksum并寫入頁。另外啟用checksum后，總是會記錄hint bits，增加了WAL IO的壓力。為了爭取驗證checksum開銷，需要更長更大的測試，就行增加對sysbench tpcc所做的一樣。

sysbench－tpcc進行測試

我們決定使用sysbench－tpcc執行更詳細的測試。注意感興趣的是數據可全放到內存的情況。另一方面，雖然ARM服務器上PG沒有問題，但是與x86服務器相比，sysbench根據挑剔。

每個測試執行下面步驟：

1）restore必要規模的數據目錄（10／200）

2）用相同參數進行10分鐘預熱

3）PG端checkpoint

4）進行測試

16個線程，在內存

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

可能會思考，為什么測試在結束時性能會突然下降。他與full＿page＿writes的checkpoint有關。即使對于內存測試，使用了pareto分布，但是每個checkpoint后仍會寫出相當多的頁面。本實例中，顯示WAL早于對應點觸發checkpoint，所有進行的測試都會有這種下降。

32個線程，在內存

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

64個線程，在內存

64個下，減小到了4．5％。

128個線程，在內存

兩個實例超過飽和點，性能差異就很小了。經仍保持在1．4％水平。此外可以看到ARM的tps下降了6－7％，在x86上下降了4％。

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

造成這種情況的一個可能原因，特別對于m6gd．8xlarge的128線程上的嚴重衰減，是因為缺少m5d．8xlarge所擁有的第二個驅動器。目前還沒有完全可比較的實例可用，因此我們認為這是一個比較公平的測試。每個實例類型都有一定優勢。需要更多測試和分析。可以使用EBS執行IO綁定測試，以嘗試刪除本地驅動器。

有關測試設置、結果、使用腳本和測試之間生產的數據的更詳細信息，訪問https：／／github．com／arronax／scratch／tree／master／performance／graviton2－postgres

總結

執行測試中，ARM實例比x86慢的情況不多。過去的幾天測試中，結果一致。雖然基于ARM的實例便宜了25％，但與x86相比，能夠在大多數測試中有15－20％的提升。因此基于ARM的實例在各方面提供了更好的性價比。

討論的郵件列表：

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