本頁面將介紹 Filestore 執行個體的效能選項,並提供最佳化效能的一般建議。使用 Google Cloud 控制台建立區域和可用區執行個體時,系統會預設啟用自訂效能,讓您獨立調整 IOPS 和容量,滿足特定工作負載需求。
下表摘要列出在自訂效能設定下,較低和較高容量範圍的效能限制:
| 容量範圍 | 服務級別 | 容量 | 每 TiB 的佈建 IOPS |
|---|---|---|---|
| 容量範圍較小 | 區域性 (區域內提供小型執行個體) | 100 GiB 至 10,239 GiB | 4,000 至 17,000 點 |
| 區域性 (區域中無法使用小型執行個體) | 1 TiB 至 9.75 TiB | 4,000 至 17,000 點 | |
| 可用區 | 1 TiB 至 9.75 TiB | 4,000 至 17,000 點 | |
| 容量範圍較大 | 區域 | 10 TiB 至 100 TiB | 3,000 至 7,500 |
| 可用區 | 10 TiB 至 100 TiB | 3,000 至 7,500 |
瞭解成效計算方式
下表顯示根據每 TiB 佈建 IOPS 和配置容量計算的效能。系統會根據不同的容量範圍進行計算,顯示讀取 IOPS、寫入 IOPS、讀取處理量和寫入處理量的值,以及每 TiB 的最低和最高 IOPS 值。
詳情請參閱「讀取及寫入 IOPS」。
| 容量範圍 | 每 TiB 佈建的 IOPS 上限和下限 |
容量 | 讀取 IOPS | 寫入 IOPS | 讀取處理量 (MiBps) | 寫入處理量 (MiBps) | 單一用戶端讀取總處理量 (MiBps) | 單一用戶端寫入處理量 (MiBps) |
|---|---|---|---|---|---|---|---|---|
| 容量範圍下限 (100 GiB 至 10,239 GiB) |
4,000 | 100 GiB | 2,000* | 600 | 47 | 16 | 47 | 16 |
| 600 GiB | 2,344 | 703 | 55 | 19 | 55 | 19 | ||
| 1,024 GiB | 4,000 | 1,200 | 94 | 32 | 94 | 32 | ||
| 10,239 GiB | 39,996 | 11,999 | 940 | 320 | 450 | 260 | ||
| 17,000 | 100 GiB | 2,000 | 600 | 47 | 16 | 47 | 16 | |
| 600 GiB | 9,961 | 2,988 | 234 | 80 | 234 | 80 | ||
| 1,024 GiB | 17,000 | 5,100 | 400 | 136 | 400 | 136 | ||
| 10,239 GiB | 169,983 | 50,995 | 3,995 | 1,360 | 450 | 260 | ||
| 容量範圍較大 (10 TiB 至 100 TiB) |
3,000 | 10 TiB | 30,000 | 9,000 | 705 | 240 | 705 | 240 |
| 7,500 | 100 TiB | 750,000 | 225,000 | 17,625 | 6,000 | 1,600 | 800 |
* 視小型容量執行個體功能的存取權而定,Filestore 區域執行個體的容量下限範圍可能為 100 GiB 至 10,239 GiB,或 1 TiB 至 9.75 TiB。詳情請參閱「 小容量 Filestore 執行個體」。
效能擴充
在單一和少數用戶端情境中,您必須使用 nconnect
掛接選項增加 TCP 連線數量,才能達到最高 NFS 效能。
對於特定服務層級,我們建議在用戶端與伺服器之間指定下列連線數:
| 級別 | 容量 | 連線數量 |
|---|---|---|
| 區域、可用區 | 1 至 9.75 TiB | nconnect=2 |
| 區域、可用區 | 10 至 100 TiB | nconnect=7 |
| Enterprise | - | nconnect=2 |
| 高可擴充性固態硬碟 | - | nconnect=7 |
一般來說,檔案共用容量越大,連線的用戶端 VM 越少,指定額外連線 (使用 nconnect) 帶來的效能提升就越大。
建議的用戶端機型
建議使用 Compute Engine 機型 (例如 n2-standard-8),提供至少 16 Gbps 的輸出頻寬。對於快取友善的工作負載,這個輸出頻寬可讓用戶端達到約 16 Gbps 的讀取頻寬。如需更多背景資訊,請參閱「網路頻寬」。
Linux 用戶端掛接選項
建議您使用下列 NFS 掛接選項,特別是 hard 掛接、async,以及 rsize 和 wsize 選項,在 Linux 用戶端 VM 執行個體上獲得最佳效能。如要進一步瞭解 NFS 掛接選項,請參閱 nfs。
| 預設選項 | 說明 |
|---|---|
hard |
NFS 用戶端會無限期重試 NFS 要求。 |
timeo=600 |
NFS 用戶端會等待 600 分秒 (60 秒),然後重試 NFS 要求。 |
retrans=3 |
NFS 用戶端會嘗試 NFS 要求三次,然後採取進一步的復原動作。 |
rsize=524288 |
每個 READ 要求,NFS 用戶端最多可從 NFS 伺服器接收 524,288 個位元組。注意:如果是基本層級執行個體,請將 rsize 值設為 1048576。 |
wsize=524288 |
每個 WRITE 要求中,NFS 用戶端最多可傳送 524,288 個位元組給 NFS 伺服器。 |
resvport |
NFS 用戶端與這個掛接點的 NFS 伺服器通訊時,會使用具備權限的來源通訊埠。 |
async |
NFS 用戶端會延遲將應用程式寫入作業傳送至 NFS 伺服器,直到符合特定條件為止。 注意:使用 sync 選項會大幅降低效能。 |
使用 read_ahead_kb 參數將 NFS 讀取輸送量最佳化
NFS read_ahead_kb 參數會指定 Linux 核心在循序讀取作業期間應預先擷取的資料量 (以 KB 為單位)。因此,後續的讀取要求可直接從記憶體提供服務,以減少延遲並提升整體效能。
如果是 Linux 核心版本 5.4 以上,Linux NFS 用戶端會使用 128 KB 的預設 read_ahead_kb 值。建議將這個值提高至 20 MB,以提升循序讀取輸送量。
在 Linux 用戶端 VM 成功掛接檔案共用區後,您可以使用下列指令碼手動調整 read_ahead_kb 參數值:
mount_point=MOUNT_POINT_DIRECTORY
device_number=$(stat -c '%d' $mount_point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo 20480 > /sys/class/bdi/$major:$minor/read_ahead_kb"
更改下列內容:
MOUNT_POINT_DIRECTORY 是掛接檔案共用區的所在目錄路徑。
單一和多個用戶端 VM 的效能
Filestore 的可擴充服務層級已針對多個用戶端 VM 進行效能最佳化,而非單一用戶端 VM。
如要充分發揮區域、區域和企業執行個體的效能,至少需要四個用戶端 VM。這可確保基礎 Filestore 叢集中的所有 VM 都能充分發揮效用。
為提供更多脈絡資訊,最小的可擴充 Filestore 叢集有四部 VM。無論使用 nconnect
掛接選項為每個用戶端指定多少個 NFS 連線,每個用戶端 VM 都只會與一個 Filestore 叢集 VM 通訊。如果使用單一用戶端 VM,讀寫作業只會從單一 Filestore 叢集 VM 執行。
以容量為依據的效能限制
容量限制適用於不支援自訂效能的服務層級,例如基本層級,或您手動停用自訂效能的執行個體。
每個 Filestore 服務層級提供的效能等級不同,可能會因快取使用情形、用戶端 VM 數量、用戶端 VM 的機型,以及測試的工作負載等因素而異。
下表列出為各服務層級設定最低和最高容量時,可達成的最高效能。表格中的所有值都是預估上限。
| 服務級別 | 容量 | 讀取 IOPS | 寫入 IOPS | 讀取處理量 (MiBps) | 寫入處理量 (MiBps) | 單一用戶端讀取總處理量 (MiBps) | 單一用戶端寫入處理量 (MiBps) |
|---|---|---|---|---|---|---|---|
| 可用區 | 1 TiB | 9,200 | 2,600 | 260 | 88 | 260 | 88 |
| 9.75 TiB | 89,700 | 25,350 | 2,535 | 858 | 450 | 260 | |
| 10 TiB | 92,000 | 26,000 | 2,600 | 880 | 1,600 | 800 | |
| 100 TiB | 920,000 | 260,000 | 26,000 | 8,800 | 1,600 | 800 | |
| 區域 | 1 TiB | 12,000 | 4,000 | 120 | 100 | 120 | 100 |
| 9.75 TiB | 117,000 | 39,000 | 1,170 | 975 | 450 | 260 | |
| 10 TiB | 92,000 | 26,000 | 2,600 | 880 | 1,600 | 800 | |
| 100 TiB | 920,000 | 260,000 | 26,000 | 8,800 | 1,600 | 800 | |
| Enterprise | 1 TiB | 12,000 | 4,000 | 120 | 100 | 120 | 100 |
| 10 TiB | 120,000 | 40,000 | 1,200 | 1,000 | 450 | 260 | |
| 基本傳統硬碟 | 1 TiB 至 10 TiB | 600 | 1,000 | 100 | 100 | 100 | 100 |
| 10 TiB 至 63.9 TiB | 1,000 | 5,000 | 180 | 120 | 180 | 120 | |
| 基本固態硬碟 | 2.5 TiB - 63.9 TiB | 60,000 | 25,000 | 1,200 | 350 | 1,200 | 350 |
提升各項 Google Cloud 資源的效能
跨多個 Google Cloud 資源執行的作業 (例如使用 Google Cloud CLI 將資料從 Cloud Storage 複製到 Filestore 執行個體) 可能會很慢。如要緩解效能問題,請嘗試下列做法:
請確認 Cloud Storage 值區、用戶端 VM 和 Filestore 執行個體都位於同一個地區。
雙區域是儲存 Cloud Storage 資料的最佳效能選項。如果使用這個選項,請確保其他資源位於雙區域所含的單一區域中。舉例來說,如果 Cloud Storage 資料位於
us-central1,us-west1,請確保用戶端 VM 和 Filestore 執行個體位於us-central1。如要參考,請驗證附加 Persistent Disk (PD) 的 VM 效能,並與 Filestore 執行個體的效能比較。
- 如果與 Filestore 執行個體相比,PD 附加的 VM 效能相似或較慢,可能表示效能瓶頸與 Filestore 無關。如要提升非 Filestore 資源的基準效能,可以調整與平行複合上傳作業相關聯的 gcloud CLI 屬性。詳情請參閱「工具和 API 如何使用平行複合式上傳」。
- 如果 Filestore 執行個體的效能明顯低於
連結 PD 的 VM,請嘗試將作業分散到多個 VM,以提升 Cloud Storage 的讀取作業效能。