Ubuntu Server 24.04 Minimal 與 Standard：效能基準測試詳解

虛擬專用伺服器記憶體不足，因此您重新安裝了 Ubuntu Server 24.04 LTS，並面臨一個選擇：預設的 Ubuntu Server 安裝還是精簡版的 Ubuntu Server。人們很容易認為軟體包越少，網頁請求速度就越快，資料庫查詢時間就越短，CPU 吞吐量也越高。但實際情況並非如此簡單。較小的初始軟體包集可以減少磁碟使用和後台活動，但它本身並不能提高處理器或儲存設備的速度。

總之：如果您想要一個精簡的初始安裝，並且只添加所需的工具，請選擇最小化安裝。如果您需要更全面的預設伺服器工具集，請選擇標準安裝。請分別比較啟動時間、空閒記憶體、磁碟佔用空間和實際應用程式效能，而不是將它們簡單地歸結為「更快」這個標籤。

證據說明（2026年10月9日）：本文解釋了一種可重複的基準測試方法以及各項指標所能得出的結果。本文並未展示兩個匹配的Ubuntu 24.04安裝的原始測量分數。測試結果中不包含任何未經驗證的記憶體、磁碟、啟動時間或吞吐量資料。

標準版 Ubuntu 伺服器和精簡版 Ubuntu 伺服器有什麼區別？

Ubuntu Server 的 Subiquity 安裝程式提供兩種安裝來源：ubuntu-server標準安裝來源（預設）和ubuntu-server-minimal最小化安裝來源。 Canonical 對這些安裝來源識別碼進行了文件說明，並建議檢查casper/install-sources.yaml所選 ISO 文件，因為安裝程式識別碼可能會變更。請參閱Canonical Subiquity 自動安裝來源文件。

兩者都是 Ubuntu Server 24.04 LTS，並非兩種不同最佳化的 CPU 架構或獨立的 Linux 發行版。主要差異在於安裝時提供的軟體。具體包含哪些軟體包取決於安裝媒體版本、可選選項、更新、驅動程式以及後續安裝的應用程式。請勿假定針對某個鏡像版本所發佈的軟體包清單適用於所有 24.04 的小版本安裝程式。

最小化伺服器選項不應與最小化 Ubuntu 雲端鏡像（一個獨立的鏡像系列）或 Ubuntu 桌面最小化安裝選項混淆。 Ubuntu 24.04 LTS 發行說明中提到，與早期版本相比，最小化雲鏡像的軟體包數量和可下載大小均大幅減少。已發布的雲端鏡像範例並非受控的標準版與最小化版 Live Server ISO 基準測試，其資料不應直接用於此類基準測試。

哪些性能指標比較重要？

預期行為並非實際測量結果。一台配置精簡的機器在安裝後可能立即消耗更少的資源。但一旦兩台機器運行相同的資料庫、容器運行時、監控代理程式和 Web 伺服器，觀察到的資源消耗差距可能會縮小、消失，或改變方向。唯一可靠的結論來自目標工作負載的測量。

首先要設定一個公平的測試環境，而不是用秒錶計時。

使用相同的 Ubuntu Server 24.04 LTS ISO 映像建立兩個一次性虛擬機，一個標準配置，一個最小化配置。分配相同的虛擬 CPU 數量、記憶體、虛擬磁碟、檔案系統、啟動模式、虛擬機器管理程式設定、網路連線和儲存類別。對於實體機，使用同等硬件，並在相似的散熱和電源條件下進行測試。確保虛擬機器不用於生產流量。

在兩個系統上套用相同的安全性更新並重新啟動。記錄版本cat /etc/os-release號uname -r、lscpu安裝鏡像版本和測試日期。 Ubuntu Server 24.04 通常使用通用可用內核，但也可選擇性地使用硬體啟用核心；不同的核心版本會影響僅基於安裝類型的比較。 Ubuntu核心文件中關於 GA 核心和 HWE 核心的說明解釋了這種差異。

收集兩組測量數據：

1. 全新安裝基準：在完成所有相同更新後，安裝工作負載前立即進行。這可以隔離安裝預設設定中的實際差異。
2. 生產環境基線：安裝相同的應用程式套件、啟用相同的服務並套用相同的配置後，即可查看初始資源佔用差異是否仍然重要。

每個測試至少運行多次，最好在預熱後運行五次或更多次，並比較中位數和變異性。重新啟動系統並測量多次啟動的啟動時間。切勿將一個系統上的冷啟動結果與另一個系統上已預熱後的結果進行比較。

先測量容易區分的差異。

1. 統計已安裝軟體包數量並檢查磁碟空間

軟體包數量和儲存使用情況通常是最容易檢查的特徵。在每台虛擬機器上運作：

dpkg-query -W -f='${binary:Package}\n' | wc -l
df -h /
lsblk -f

記錄根檔案系統已用空間和檔案系統佈局。確保根分割區大小相近；否則，分割方式不同可能會導致表面上的差異。磁碟使用情況還包括日誌、軟體包快取和檔案系統元數據，因此相同的安裝時間和相似的更新歷史記錄至關重要。

2. 比較可用內存，而不僅僅是「空閒」內存

待兩個系統都閒置一段時間後，執行以下指令：

free -h
systemctl --type=service --state=running --no-pager

同時查看該available列。 Linux 會將原本空閒的記憶體用作緩存，以便在應用程式需要時回收。該列中較小的值並不一定表示有問題。請檢查額外記憶體的使用是否屬於您計劃保留的服務。freeusedfree

3. 比較啟動時間並找出運作緩慢的服務

每次啟動時，都使用發行版提供的 systemd 工具：

systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain

systemd-analyze time該清單會報告啟動階段的計時，但這並不一定意味著應用程式已準備好接受請求。blame此外，由於各個單元可能會並行初始化，且某些服務類型的計時方式不同，因此該清單也可能具有誤導性。請調查關鍵鏈，然後單獨檢查您關注的特定服務端點。這些限制已在Ubuntu 24.04 systemd-analyze 手冊中進行了說明。

例如，如果伺服器運行 HTTP API，則測量從重新啟動到 API 健康檢查端點成功所需的時間。如果主機執行資料庫，則檢查查詢是否成功。這種就緒狀態測量比作業系統是否達到啟動目標更具實際意義。

然後，在受控負載下測試 CPU 和儲存。

4. 在兩台機器上運行相同的 CPU 工作負載。

為了進行簡單的 CPU 效能比較，在記錄全新安裝後的虛擬機器效能佔用情況後，在每個一次性虛擬機器上安裝相同版本的 sysbench。然後運行相同的命令：

sudo apt update
sudo apt install sysbench
sysbench --threads=1 --time=30 cpu --cpu-max-prime=20000 run

比較多次運行的每秒事件數和延遲。 sysbench專案文件提供了指令語法和內建的 CPU 測試。只有當執行緒數高於分配的 CPU 數量時，才使用相同但更高的執行緒數進行第二次運行。僅減少軟體包集不足以證明 CPU 速度提升；如果出現意外差異，則應檢查主機 CPU 爭用情況、時脈行為、核心版本和後台進程。

5. 測試磁碟 I/O，而不對生產磁碟進行基準測試

對於可選的儲存實驗，請在兩台測試機器上都安裝 fio，並在一個具有充足可用空間的臨時檔案系統上建立相同的測試檔案。以下指令會在目前使用者的家目錄下建立一個 256 MiB 的文件，然後對該文件執行有界隨機讀取工作負載：

sudo apt install fio
dd if=/dev/urandom of="$HOME/fio-sample.bin" bs=1M count=256 status=progress
fio --name=randread --filename="$HOME/fio-sample.bin" --rw=randread --bs=4k --size=256M --ioengine=libaio --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

兩台機器應使用相同的磁碟和 I/O 參數運作。 256 MiB 的檔案可能太小，無法準確模擬資料庫或儲存設備；只有在有足夠的臨時空間和安全的測試環境時，才能增加檔案大小並改變工作負載。記錄 IOPS、頻寬和延遲分佈，而不僅僅是最大的頻寬值。 Ubuntu 24.04 的 fio 手冊解釋了工作負載參數。切勿將寫入測試指向包含有用資料的原始區塊裝置。

6. 最後測試實際應用。

在兩台機器上安裝完全相同的應用程式堆疊，包括 Web 或資料庫版本、連線數限制、日誌記錄、TLS、快取和監控。使用獨立的負載產生器發送相同的請求組合，並保持相同的並發性和測試持續時間。測量吞吐量、反應延遲的中位數和第 95 個百分位數、錯誤率、CPU 使用率、記憶體壓力和交換情況。使用相同的資料集，並確保兩台機器的後端儲存不存在爭用問題。

對於小型 API 伺服器而言，如果某個配置在負載期間開始使用交換，那麼空閒記憶體的差異就至關重要。而對於擁有充足可用記憶體的 CPU 密集型工作進程來說，相同的應用程式二進位檔案可能提供基本相同的吞吐量。這兩種結果都無法在測試之前確定。

如何解讀相互矛盾的基準測試結果

• 軟體包數量減少但 CPU 效能得分不變：這完全合乎邏輯。安裝的工具數量減少並不一定會影響運算效能。
• 磁碟使用率降低但 IOPS 不變：可用空間和裝置速度是不同的屬性。若要考慮儲存硬體、I/O 模式、檔案系統和快取。
• systemd 啟動速度更快，但應用程式準備速度同樣慢：瓶頸可能是應用程式啟動、網路依賴或資料庫復原。
• 空閒 RAM 減少，但請求延遲不變：最小化可能會提供有用的容量餘裕，但當前工作負載不受記憶體限制。
• 兩次運行之間的分數變化很大：在宣布獲勝者之前，請調查嘈雜的鄰居、CPU 頻率調節、更新、計劃任務、過熱節流和快取預熱等因素。

如果節省的磁碟空間微乎其微，但您的操作流程卻經常需要用到缺少的管理工具，那麼標準安裝可能是更有效率的選擇。如果您的伺服器是自動配置的，並且運行的是定義明確的服務，那麼精簡的基礎軟體包通常更便於審核。

是否應該將現有伺服器切換到最小化模式？

通常情況下，並非僅為了追求基準測試分數。對於一個運作正常的標準安裝，首先應該檢查其實際運行的服務並評估應用程式的效能。移除無關的軟體包可能不會改善已經運作良好的工作負載，而且隨意移除軟體包可能會導致網路連線、復原、日誌記錄或遠端管理功能故障。 Canonical 針對Ubuntu 不必要軟體包的安全指南建議，選擇一個合適的最小初始安裝，而不是隨意移除預設軟體包。

如果重建值得，請備份資料和配置，驗證復原功能，在新實例上安裝最小化選項，並明確配置必要的軟體包。在遷移流量之前，請先驗證 SSH 存取、更新、時間同步、備份、監控、防火牆策略和應用程式運作狀況。如果管理員經常依賴捆綁的診斷程序或承擔多種角色，即使標準安裝的全新安裝佔用空間更大，也可能是更佳選擇。

安全性與此相關但又有所區別：軟體包數量的減少或許能降低您需要維護的軟體量，但這並不能證明特定 CVE 漏洞的減少。兩種安裝方式仍需要進行安全更新和服務加固。

最終核查清單

• 確認兩台機器都是 Ubuntu Server 24.04 LTS，且架構、修補程式等級、核心版本和安裝程式版本都相同。
• 記錄標準版或最小化版的選擇、可選的安裝程式選項以及之後新增的服務。
• 比較相同更新操作和一段空閒穩定期後的軟體包數量、根檔案系統使用情況和可用記憶體。
• 在多次重新啟動過程中重複進行啟動和應用程式準備測量，報告中位數而不是單次最佳運行結果。
• 使用與 CPU、儲存和應用程式工作負載相符的參數，並記錄錯誤和延遲分佈。
• 使用相同的依賴項、配置和資料運行應用程序，然後確定任何差異是否會影響容量、可靠性或部署時間。

實際結論：對於範圍較窄、自動化程度較高的伺服器，最小化配置通常是更好的初始選擇；標準配置則提供更完整的預設工具集。兩種配置並非在所有情況下都更快。在 Ubuntu Server 24.04 LTS 上，最有效的基準測試是在服務實際需要處理的工作負載下進行測試。