優化儲存庫效能

Azure DevOps 服務 |Azure DevOps Server |Azure DevOps Server 2022

Azure Repos 為大多數 Git 倉庫提供高效能與可靠性。 Git 表現最佳時，當倉庫類似典型原始碼專案時：檔案相對較小，變更是漸進式且在地化，目錄有良好組織的階層結構。 這些條件使 Git 能有效利用 delta 壓縮並遍歷資料庫樹。

當儲存庫不符合這些條件時，Git 必須讀取並傳輸更多且更大的物件。 因此，常見的操作，如克隆、取用和瀏覽，都會變得較慢。

本文說明如何分析儲存庫健康狀況、識別並解決常見效能下降原因，以及減少在複製與取用過程中傳輸的資料量。

關於適用於倉庫的資源限制，請參見 Git 限制。

儲存庫健康分析

從內建 的健康與使用 面板開始。 它彙整了儲存庫大小、物件數量、參考數量及其他指標。 同時也會突顯接近或超過建議門檻的數值。

此面板可能在較舊版本的 Azure DevOps Server 中無法使用。 如果沒看到，考慮升級到新版本以存取內建的儲存庫健康指標。

CLI 工具

若要進一步仔細檢查，請對該儲存庫的完整複本執行以下工具。

git-sizer

用於 git-sizer 對資料庫規模與複雜度進行高層次評估。 它會計算整個資料庫的指標，並為每個指標分配關注等級。 從發佈頁面下載最新版本，並按照快速入門執行此工具並檢視輸出結果。

Git 倉庫結構

使用 git-sizer 作為 git repo structure 的替代方案。 這個實驗性指令設計用來在主流 Git 中原生提供類似功能。 更多資訊請參閱 Git repo 文件。

Git 調查

使用 git survey 進行路徑層級分析。 在這些 CLI 工具中，它提供了最詳細的分解。 它會依物件數量、磁碟大小和膨脹大小來排名頂尖的目錄和檔案。 該報告幫助你辨識對資料庫規模貢獻最大的因素，並針對他們進行清理或重組。

此指令包含於 Git for Windows 及 Microsoft 的 Git 分支中。 其他 Git 發行版的可用性可能有所不同。

常見的儲存庫效能問題與緩解措施

以下模式是導致儲存庫成長與效能下降的最常見原因。

大型且頻繁更新的檔案

大型檔案會降低 Git 效能，不論是文字還是二進位檔案。 影響最大是在它們頻繁變動時。 由於每次變更通常會重寫檔案的大部分內容，delta 壓縮變得無效，導致 Git 幾乎要為每個版本儲存完整的快照。 因此，儲存庫大小與物件數量迅速成長。

建議動作

• 避免將大型且頻繁更新的檔案放入 Git。 把它們存到 Git LFS 或 Azure Artifacts，不要提交建置輸出或產生的內容。 欲了解更多資訊，請參閱 「處理你的 Git 倉庫中的大型檔案」。
• 如果一個大型檔案必須保留在 Git 中且經常變動，請將其拆分成較小的邏輯部分，這些部分可以獨立進行版本管理。
• 要阻止新的大型檔案進入儲存庫，請啟用 最大檔案大小 政策。

Git LFS 僅用於不適合進行差異比對的大型檔案。 將許多小型檔案移到 LFS 並不會提升效能，甚至可能讓效能變得更差。

超大或扁平目錄結構

包含多個直接條目（包含檔案與子目錄）的目錄會以一個大型樹狀物件形式儲存。 裡面的任何變更都會讓 Git 重新寫入整個物件的副本。 這種行為會拖慢 Git 運算速度，並隨時間增加儲存庫大小，即使變更很小。

將任何單一目錄中的直接條目數量維持在易於管理的範圍內。 若數量超過數百，就表示該結構應重新平衡。

建議動作

• 將條目組織成平衡且階層式的版面。 將檔案和子目錄平均分配，避免單一目錄包含過多的直接條目。
• 如果你需要在儲存庫中儲存大量產生的資料，可以將其分割成巢狀的版面，例如 年份/月份/日期。
• 在每個檔案中保持產生內容的順序一致。 新增或刪除少量資料應該只影響相關行，不會重新排序檔案並造成較大差異。 例如，清單排序方式永遠相同。

未使用的分支

過多長期未使用的分支會增加儲存庫容量並拖慢作業速度。 當你 git clone 建立一個儲存庫時，Git 會下載可從所有遠端分支存取的物件，包括從未合併成 main的檔案。

建議動作

• 定期刪除過期或未使用的分支。
• 如果你的資料庫確實需要大量分支，可以考慮啟用 有限參考。

這兩種操作都能減少每次擷取時客戶端與伺服器協商的參考數量。

加快複製和擷取速度

無論資料庫多麼健康，客戶都可以減少下載的資料量：

• 淺克隆限制了可取得的歷史紀錄量，這對於只需要最新提交的 CI 來說很有效。
• 部分克隆會保留完整歷史，但只有在需要時才下載檔案內容。

關於這兩種選項的更多資訊，請參閱 Azure DevOps 中的 Git 部分複製。