樹莓派4B很熱門,而且我也一直想要一個ARM V8的64位平臺做個實體硬件的arm測試平臺,在各種國產arm開發板上和樹莓派4B上反復比較，最終還是選擇了比較潮流的樹莓派4B作為測試平臺，紙面性能很好看， 4核心1.5g a72 , 很是動心，但是真實跑文件服務性能，我心里沒底，那些跑分軟件給出的對比，畢竟無法代替真實的文件服務測試。

我入手的這套樹莓派4B,是乞丐版，因為不需要也不打算使用圖形環境，因此 2GB的乞丐版足夠使用，

由于之前的環境都使用的是ubuntu系列，因此，這套arm平臺的linux系統，我沒有選擇樹莓派官方的os,而是直接下載的ubuntu linux 20.04.1 for arm arch64 ,這里的一個最大難點是如何點亮hdmi, 默認參數下hdmi接口基本是無法點亮的，需要修改config.txt文件，具體可以參考這里 , 反正按里面的步驟進行，只要不是太特別的設備，基本可以點亮。

安裝完ubuntu linux for arm arch64后，開啟了ssh服務，畢竟樹莓派太精簡了，系統上沒啥東西，命令行也不知道如何截圖，因此開了ssh服務后，使用遠程登錄，在另一臺ubuntu linux 20.04 筆記本上執行的后續部署操作

對比平臺

樹莓派： 4B(1.2) cpu: Broadcom BCM2711 4核心 A72 1.5ghz , 內存 2GB 居然是LPDDR4 千兆網，usb3之類的都是標準配置 特別說明的是tf卡的輸出速度是80MB/s

聯想 thinkpad e330, cpu: intel i3-2328m 雙核心 32nm 超線程 2.2ghz， 內存 4GB ddr3-1333 網卡之類的標準配置 特別說明系統盤是 320GB筆記本機械硬盤

操作系統都是ubuntu linux 20.04.1, 升級到最新補丁，不同的是一個是arm版，一個是x64

XFile，默認用戶數量和服務， [統一啟用hash功能] ,都是采用gcc(g++) O2優化編譯

先對比在待機狀態下的cpu占用

先上樹莓派的，幾乎始終穩定在0.3%,這cpu好像不會自動降頻，一條直線啊

然后是i3-2328m

arm 的功耗：

也就是，在待機狀態下， intel i3-2328m X64平臺和 樹莓派平臺的待機開銷基本相同0.3%占用，而i3-2328m X64平臺偶爾會突破0.3%的開銷,主要是intel cpu節能降頻功能導致，不要太在意,大體是平手,主要原因可能是intel的自動降頻功能下，頻率被壓低了，arm 待機功耗更是喜人，3.8瓦.

現在嘗試使用手機點播2.4GB大小媒體文件測試，這是正常網絡播放測試，http流播放,沒有明顯的延遲，和i3-2328m X64平臺對比，主觀上無法區分，都非常流暢，樹莓派4B監測到的cpu最高開銷是1%,而 i3-2328m X64平臺這時候就跟沒事發生一樣，最高依然是0.7%,由于媒體播放和播放器，無線網絡帶寬，磁盤性能等影響太多，偶然性很大，因此只能說明，樹莓派用做文件服務器，家庭影院做純文件服務，不存在性能不足的問題，我們推算， 樹莓派 2GB版，使用XFile服務器做點播服務，只計算cpu和內存限制，按50%占用限制,對家用來說，性能基本夠了.

由于tf卡和機械硬盤本身輸出速度不同，因此我們沒有做網速測試，而是使用了更專業的功能，啟用文件hash校驗功能，通過對文件執行散列計算，得到消耗的cpu時間，由于XFile文件散列計算是采用自身的函數，通過cpu進行的計算，因此不會受到cpu/gpu擴展指令的影響，是純cpu計算.

下圖，是重新啟動樹莓派后，立即執行文件散列計算：

耗費時間大約1分鐘20秒, 最終的cpu消耗時間片是53秒,期間cpu的最高占用大約70%,可功耗居然：4.6瓦

這個能耗比真的太牛了，不是一般的牛

下圖，是intel i3-2328m 對相同文件執行的計算

耗費時間大約是45秒，cpu開銷的時間片是35秒.

這個指令是XFile支持的指令中cpu開銷最大的一個專業指令，普通用戶一般根本不會用到，但是它用來做對比測試就比較合適。

對比：

intel 2328m ,cpu時間： 35秒，總計算時間45秒

arm BCM2711, cpu時間 ： 53秒 ， 總計算時間 72秒(這主要是因為tf卡只有80MB/s讀取導致)

XFile對文件的計算服務看作是cpu單核心整數運算的對比，文件服務器一般很少用到浮點計算，只有跑分軟件才會。

由于intel i3-2328m屬于已被淘汰的古董32nmcpu,而且只有兩個固定2.2ghz頻率的核心，畢竟現在的主流cpu隨便拿一個出來都能把這貨按地上磨擦好多次了,因此，這個對比可能沒有什么現實意義,但是作為參考還是可以的, 4核心1.5G BCM2711打不過雙核心的古董i3-2328m。

作為開發者，我能說的是ARM A72 4核心，相對a53性能提升還是非常明顯的（雖然A72也是很老的架構)，之前接觸過A53的arm,被那糟糕的性能搞的沒心情，但是這個樹莓派4B的性能，超出我的想像 ,使用ARM平臺建立家庭服務器基本不存在性能障礙,估算，XFile帶個16路點播，ARM是可以滿足的。

最后說下這個樹莓派搭建家庭文件服務器的比較大的缺點吧

[1] 缺少ECC內存的支持，對內文件服務沒大問題，但是如果要提供公網訪問，沒有ecc保護，有點危險，畢竟現在的服務器軟件基本沒有做軟件層關鍵數據校驗，除非航天軟件。

[2] 缺少sata接口，缺少內存擴展接口，畢竟大內存，機械盤對家庭文件服務器太關鍵了，使用USB3的硬盤盒？ 我可不想我的硬盤死的太快。

今天剛寫這篇文章，傳來個大消息，nvidia要收購ARM了，哎，RISC-V快點普及吧，否則真的是連根都被老美給掐斷了

##########################################

補充下，AMD R5-3500X 6核心 + 16G DDR4-2666的測試，這個目前算主流平臺了，就是內存頻率低了 點，由于已經裝了win10，不想折騰，就干脆用windows版XFile進行測試，文件時同一個，重新啟動后【主要時去掉緩存的影響】，測試結果【File zilla需要把指令超時時間調整到60，默認太短】：

cpu 時間片大約9秒，總用時大約22秒【老機械硬盤拖累】

現在重新對比：

對同一個文件 執行散列計算，

樹莓派 4*1.5g cpu時間是 53秒

i3-2328m 2*2.2g cpu時間是 35秒

若-3500x 6*3.6g cpu時間是 9秒

9/53=0.1698, 也就是 樹莓派的cpu整數計算性能大約是3500x 的 17%左右,

這個數據是針對特定整數計算的，沒有使用浮點，僅供參考（samba，nfs,ftp,http,smtp,pop3等網絡服務都是整數計算）

#####2020.09.29 補充典型家庭內部使用下的性能開銷

一般家庭內部,包括手機端和電腦,電視等同時使用,一般在4路并發播放內,我們模擬了這個使用場景, 目標文件為4個大小2GB大小的視頻文件 ,[硬拷貝,已經重啟以避免linux系統的緩存影響測試], 存儲設備是80MB/s讀取速度的tf卡,

場景1 , 4個客戶端同時登錄XFile服務器,但是沒有執行播放操作

樹莓派在客戶端登錄的瞬間,Xfile最高占用為3%[因為需要掃描發送文件列表等],等后期進行無操作階段后,cpu占用回到了0.3%,幾乎和沒有負載一樣.

現在來同時執行對4個客戶端請求4個不同的2GB文件的播放操作,播放器為VLC,協議是http流播放(http 1.1協議),由于已經重啟去掉了緩存的影響,因此這個播放是無緩存直讀模式,也是負載最大的情形,

并發峰值為6.3%,大約每個客戶端的cpu開銷峰值為1.5%,那么假設存儲設備和網絡設備沒有帶寬限制,針對我們測試里這種典型的2GB大小文件,樹莓派按50%cpu性能開銷限制[因為可能用戶會要部署其他服務如ssh等],峰值情況下也可以支持到 32路,超出我們估算的一倍,但是這是針對我們測試用的2GB大小的電影文件做的測試,,就算是30GB-80GB的藍光高清,只要磁盤和網絡不存在限制,樹莓派也可以支持3路以上并發點播. 可以看到,網絡點播服務器端的cpu性能需求,只有在登錄列表和具體文件開始播放階段,會出現占用峰值,當后續播放的時候,cpu開銷非常小.

最后,附上播放文件的情況(testbig.mp4+ testbig1.mp4+ testbig2.m4+ testbig3.mp4)

可以看到進入持續播放狀態后,4路點播情況下,Xfile服務器端平均開銷在0.7%-1.3%之間波動. 比我想像的開銷要小不少.

總結

以上是生活随笔為你收集整理的树莓派4b和3b+功耗_ARM v8(树莓派4)搭建服务器和性能测试实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。