使用簡單的“pgbench”測試,我在 GCE 的“本地 SSD”選項(與 SSD 持久磁碟相比)上每秒的事務數出乎意料地低:
# With Local SSD
# /dev/mapper/vg0-data on /data type xfs (rw,noexec,noatime,attr2,inode64,noquota)
pg-dev-002:~$ pgbench -c 8 -j 2 -T 60 -U postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 8
number of threads: 2
duration: 60 s
number of transactions actually processed: 10765
tps = 179.287875 (including connections establishing)
tps = 179.322407 (excluding connections establishing)
# With SSD Persistent Disk
# /dev/mapper/vg1-data on /data1 type xfs (rw,noexec,noatime,attr2,inode64,noquota)
pg-dev-002:/data$ pgbench -c 8 -j 2 -T 60 -U postgres
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 8
number of threads: 2
duration: 60 s
number of transactions actually processed: 62457
tps = 1040.806664 (including connections establishing)
tps = 1041.012782 (excluding connections establishing)
「fio」基準測試顯示了本地 SSD 宣傳的 IOPS 和吞吐量。然而,在本地 SSD 掛載上執行“pg_test_fsync”讓我相信 fsync 延遲是罪魁禍首。本地 SSD 編號是套用 Google IRQ 腳本後的值這裡:
# Local SSD
open_datasync 319.738 ops/sec 3128 usecs/op
fdatasync 321.963 ops/sec 3106 usecs/op
# Persistent SSD
open_datasync 1570.305 ops/sec 637 usecs/op
fdatasync 1561.469 ops/sec 640 usecs/op
- 使用 Ubuntu 14.04 和 Debian 7 映像進行測試
- 實例類型:n1-highmem-4
- 兩種磁碟區類型的安裝選項相同
我還沒有看到任何有關 fsync 和本地 SSD 限制的信息,但我不確定還可以在哪裡檢查或測試。
答案1
比較一個單身的本地 SSD/HDD/等。與SAN 類型RAID 控制器相比,就像將大眾甲殼蟲與奧迪RS10 勒芒賽車進行比較一樣,是的,它們都來自同一家工廠,並且都使用四衝程發動機/SSD/HDD,但是它們的調校等等。
我可以給您幾個獲得的經驗範例,但簡單的答案與基於 SAN 的儲存與非本地 SSD/HDD 上的儲存相比的大量電池備份 RAM 快取有關。在確認資料已「提交」到磁碟時,即使 SSD 也無法與電池支援的 DDR3 RAM 競爭。此外,單一本機磁碟(實際上)一次只能處理一個操作,將區塊寫入“磁碟”,而電池支援的 SAN 系統可以同時處理多個請求“寫入磁碟”(因為它提交了資料)至電池備份的DDR3 RAM)
最後,問題可能是哪個正在使用本機SSD磁碟,因為我發現不同的磁碟之間的寫入效能有巨大差異尺寸同一系列 SSD(越大越快),更不用說各種 SSD 磁碟的不同速度。
是的,SSD 比 HDD 更快,但還不如電池供電的 DDR3 RAM 快;)
答案2
Google 承認本機 SSD 上的寫入快取刷新相當緩慢,並提供了在檔案系統掛載上停用寫入快取的步驟,以避免這種延遲[如果適合您的用例]。文件是這裡。