Performance

ZFS 在 FreeBSD 上的讀取速度非常慢

  • August 26, 2015

我有一個 FreeBSD 10.0 系統，在該系統上執行 MySQL，其 InnoDB 數據庫文件儲存在 ZFS 上。幾個月來似乎一直很好，但最近，似乎突然間，性能已經觸底。在對 MySQL 進行了一段時間的調試之後，我最終決定只是看看從文件系統中讀取數據庫文件是否很慢。

我選擇了一張數據庫文件大約 16GB 的表，執行：

time cat table.ibd > /dev/null

並得到：

cat table.ibd > /dev/null 1.24s user 64.35s system 0% cpu 1:00:34.65 total

相比之下，位於同一系統上的 UFS 上的文件副本（有一些更改，我敢肯定：數據庫是活動的）給了我：

cat table.ibd > /dev/null 0.20s user 9.34s system 5% cpu 9.550 total

以下是此系統上的非預設 ZFS 選項：

/boot/loader.conf:
 vfs.zfs.arc_max=17179869184

/etc/sysctl.conf:
 vfs.zfs.prefetch_disable=1

zfs get:
 recordsize 16K
 compression on
 atime off
 primarycache metadata
 zfs:zfs_nocacheflush 1

現在這個文件系統上有 12 個快照。（這似乎過分了；我要看看是否可以刪除其中的任何一個。）

此池（或系統上的任何其他池）沒有 L2ARC。

我已經嘗試了 primarycache 的所有三個值，並嘗試重新啟用預取，但似乎都沒有任何顯著效果。

zpool 是四個 2 磁碟鏡像：

% zpool status mysqlrot
 pool: mysqlrot
state: ONLINE
 scan: scrub repaired 0 in 9h45m with 0 errors on Fri Jun 26 12:46:33 2015
config:

   NAME        STATE     READ WRITE CKSUM
   mysqlrot    ONLINE       0     0     0
     mirror-0  ONLINE       0     0     0
       mfid9   ONLINE       0     0     0
       mfid10  ONLINE       0     0     0
     mirror-1  ONLINE       0     0     0
       mfid11  ONLINE       0     0     0
       mfid12  ONLINE       0     0     0
     mirror-2  ONLINE       0     0     0
       mfid13  ONLINE       0     0     0
       mfid14  ONLINE       0     0     0
     mirror-3  ONLINE       0     0     0
       mfid15  ONLINE       0     0     0
       mfid16  ONLINE       0     0     0
   spares
     mfid19    AVAIL

errors: No known data errors

一個奇怪的是原始設備的設置方式。儲存控制器是一個 MFI 控制器，每個裸磁碟實際上在 MFI 控制器中配置為一個 1-disk RAID0 卷：

% sudo mfiutil show volumes
mfi0 Volumes:
 Id     Size    Level   Stripe  State   Cache   Name
mfid0 (  185G) RAID-1      64K OPTIMAL Disabled <OS>
mfid1 (  558G) RAID-0      64K OPTIMAL Disabled <DB0A>
mfid2 (  558G) RAID-0      64K OPTIMAL Disabled <DB0B>
mfid3 (  558G) RAID-0      64K OPTIMAL Disabled <DB1A>
mfid4 (  558G) RAID-0      64K OPTIMAL Disabled <DB1B>
mfid5 (  558G) RAID-0      64K OPTIMAL Disabled <DB2A>
mfid6 (  558G) RAID-0      64K OPTIMAL Disabled <DB2B>
mfid7 (  558G) RAID-0      64K OPTIMAL Disabled <DB3A>
mfid8 (  558G) RAID-0      64K OPTIMAL Disabled <DB3B>
mfid9 (  558G) RAID-0      64K OPTIMAL Disabled <DB4A>
mfid10 (  558G) RAID-0      64K OPTIMAL Disabled <DB4B>
mfid11 (  558G) RAID-0      64K OPTIMAL Disabled <DB5A>
mfid12 (  558G) RAID-0      64K OPTIMAL Disabled <DB5B>
mfid13 (  558G) RAID-0      64K OPTIMAL Disabled <DB6A>
mfid14 (  558G) RAID-0      64K OPTIMAL Disabled <DB6B>
mfid15 (  558G) RAID-0      64K OPTIMAL Disabled <DB7A>
mfid16 (  558G) RAID-0      64K OPTIMAL Disabled <DB7B>
mfid17 (  558G) RAID-0      64K OPTIMAL Disabled <DB8A>
mfid18 (  558G) RAID-0      64K OPTIMAL Disabled <DB8B>
mfid19 (  558G) RAID-0      64K OPTIMAL Disabled <SPARE0>

我在任何日誌文件或實用程序中都找不到任何錯誤。

任何人有任何想法在哪裡看？

各種數據：

% zpool list mysqlrot
NAME       SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
mysqlrot  2.17T  1.49T   701G    68%  1.00x  ONLINE  -

將 15.3GB 文件複製到受影響的文件系統（從 UFS 文件系統）：

% time sudo cp test.file /var/lib/mysql/mysqlrot/test.file
sudo cp test.file /var/lib/mysql/mysqlrot/test.file  0.02s user 44.23s system 1% cpu 1:06.93 total

（即 66.93 秒。）

從受影響的文件系統中讀取相同的文件：

# time cat test.file > /dev/null
cat test.file > /dev/null  4.23s user 268.50s system 0% cpu 25:29.27 total

（這是 1529.27 秒：幾乎是寫入時間的 23 倍。）

有趣的是，cp性能遠遠好於cat：

% time sudo cp /var/lib/mysql/v4netrot/test.file /dev/null
sudo cp /var/lib/mysql/v4netrot/test.file /dev/null  0.03s user 33.63s system 0% cpu 3:05.99 total

（185.99 秒）

iostat複製期間的數據到：

                       extended device statistics
device     r/s    w/s    kr/s    kw/s qlen svc_t  %b
mfid0      0.0    0.6     0.0     8.8    0   0.6   0
mfid1      0.4   12.6     2.7    70.5    0   0.5   0
mfid2      1.8   12.8    10.8    70.5    0   1.6   2
mfid3      0.2   10.0     1.5    92.4    0   0.7   0
mfid4      0.0   10.4     0.0    92.4    0   0.5   0
mfid5      0.2    9.4     1.2    39.7    0   0.5   0
mfid6      0.6    9.8     3.9    39.7    0   0.6   0
mfid7      0.6    4.8     0.3    46.1    0   0.9   0
mfid8      1.8    4.8    11.4    46.1    0   0.8   0
mfid9      0.4 1327.2     2.9 26686.5    0   0.5  23
mfid10     0.8 1328.2     1.8 26686.5    0   0.5  20
mfid11     1.4 1304.8     8.4 26357.6    0   0.5  23
mfid12     1.4 1304.6     2.6 26357.6    0   0.6  31
mfid13     1.6 1120.6     3.5 26194.2    0   0.6  25
mfid14     0.4 1122.6     2.7 26194.2    0   0.5  22
mfid15     0.8 1406.6     5.5 26188.5    0   0.5  22
mfid16     1.0 1174.6     2.0 21534.3   10   4.9  74
mfid17     5.8   24.2   152.9   300.6    0   0.3   0
mfid18     4.0   23.6    76.7   300.6    0   0.3   0
mfid19     0.0    0.0     0.0     0.0    0   0.0   0

kw/s 數據范圍從大約 17k 到大約 25k，並且在驅動器之間非常一致。

iostat當cat從：_

                       extended device statistics
device      r/s   w/s    kr/s    kw/s qlen svc_t  %b
mfid0       0.0   0.0     0.0     0.0    0   0.0   0
mfid1       0.4  17.2    11.4    63.4    0   0.5   0
mfid2       0.0  17.0     0.0    63.4    0   0.4   0
mfid3       0.0  14.0     0.0    56.4    0   0.4   0
mfid4       0.4  13.6     0.2    56.4    0   0.4   0
mfid5       0.8   9.6     4.8    37.3    0   0.8   0
mfid6       0.0   9.8     0.0    37.3    0   0.4   0
mfid7       0.2   3.8    17.2    11.9    0   0.6   0
mfid8       0.2   3.8     1.4    11.9    0   0.5   0
mfid9    1208.8   0.0  6831.4     0.0    0   0.1  11
mfid10    129.4   0.0   780.7     0.0    0   0.2   2
mfid11    906.4   0.0  5858.5     0.0    0   0.1  10
mfid12    600.5   0.0  2673.0     0.0    0   0.1   5
mfid13    136.2   0.0   803.9     0.0    0   0.2   3
mfid14    316.1   0.0  1895.3     0.0    0   0.1   4
mfid15    243.6   0.0  1414.5     0.0    0   0.1   2
mfid16    129.0   0.0   768.8     0.0    0   0.2   2
mfid17      3.8  25.8    29.8   274.1    0   0.2   0
mfid18      6.0  25.6    96.6   274.1    0   0.2   0
mfid19      0.0   0.0     0.0     0.0    0   0.0   0

kr/s 的數字非常不一致，但這些都是有代表性的數字。

iostatwhile cping從（到 /dev/null）：

                       extended device statistics
device     r/s   w/s    kr/s    kw/s qlen svc_t  %b
mfid0      0.0   0.0     0.0     0.0    0   0.0   0
mfid1     21.0  66.6   107.6  2351.7    0   0.9   6
mfid2     17.6  66.8   106.8  2351.7    0   1.0   6
mfid3     17.6  39.0   116.9  2111.3    0   1.1   6
mfid4     18.8  39.6    99.8  2111.3    0   1.3   7
mfid5     23.2  62.4   172.2  2076.1    0   1.1   7
mfid6     23.0  62.0   130.0  2076.1    0   1.4   9
mfid7     16.2  62.6   112.6  2125.3    0   1.0   6
mfid8     17.4  63.0   107.6  2125.3    0   0.7   4
mfid9    237.5  44.6  5140.6   807.0    0   3.1  22
mfid10   263.7  43.6  5530.5   807.0    0   1.5  14
mfid11   252.7  55.8  5297.6   802.4    0   2.6  20
mfid12   298.1  55.6  5361.9   802.4    0   2.5  21
mfid13   275.3  46.2  5116.4   801.4    0   2.8  22
mfid14   252.9  42.4  5107.7   801.4    2   3.1  21
mfid15   270.9  43.8  4546.5   943.7    0   1.2  12
mfid16   257.7  44.0  5642.5   943.7    0   2.5  19
mfid17     7.8  23.0    73.1   244.9    0   0.3   0
mfid18     0.8  24.2    44.4   244.9    0   0.2   0
mfid19     0.0   0.0     0.0     0.0    0   0.0   0

它似乎不受 CPU 限制。 top顯示cp從受影響的文件系統到/dev/null消耗大約 18% 的一個核心（共 48 個），其餘核心顯示超過 95% 的空閒。

last pid: 12474;  load averages:  1.65,  1.26,  1.14                                                                                                                                        up 39+05:42:19  14:29:08
147 processes: 1 running, 146 sleeping
CPU 0:   0.0% user,  0.0% nice,  1.6% system,  0.0% interrupt, 98.4% idle
CPU 1:   0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle
CPU 2:   0.4% user,  0.0% nice,  0.8% system,  0.0% interrupt, 98.8% idle
CPU 3:   0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle
CPU 4:   0.0% user,  0.0% nice,  2.3% system,  0.0% interrupt, 97.7% idle
CPU 5:   0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle
CPU 6:   0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle
CPU 7:   0.0% user,  0.0% nice,  2.7% system,  0.0% interrupt, 97.3% idle
CPU 8:   0.4% user,  0.0% nice,  1.9% system,  0.0% interrupt, 97.7% idle
CPU 9:   0.0% user,  0.0% nice,  2.3% system,  0.0% interrupt, 97.7% idle
CPU 10:  0.4% user,  0.0% nice,  1.9% system,  1.2% interrupt, 96.5% idle
CPU 11:  0.0% user,  0.0% nice,  3.9% system,  0.0% interrupt, 96.1% idle
CPU 12:  0.0% user,  0.0% nice,  1.6% system,  0.8% interrupt, 97.7% idle
CPU 13:  0.0% user,  0.0% nice,  2.7% system,  0.0% interrupt, 97.3% idle
CPU 14:  0.0% user,  0.0% nice,  1.6% system,  0.0% interrupt, 98.4% idle
CPU 15:  0.4% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.4% idle
CPU 16:  0.0% user,  0.0% nice,  1.6% system,  0.0% interrupt, 98.4% idle
CPU 17:  0.4% user,  0.0% nice,  3.1% system,  0.0% interrupt, 96.5% idle
CPU 18:  0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle
CPU 19:  0.8% user,  0.0% nice,  0.8% system,  0.0% interrupt, 98.4% idle
CPU 20:  0.0% user,  0.0% nice,  2.7% system,  0.0% interrupt, 97.3% idle
CPU 21:  0.4% user,  0.0% nice,  1.9% system,  0.0% interrupt, 97.7% idle
CPU 22:  0.0% user,  0.0% nice,  2.3% system,  0.0% interrupt, 97.7% idle
CPU 23:  0.4% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.4% idle
CPU 24:  0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle
CPU 25:  0.8% user,  0.0% nice,  0.8% system,  0.0% interrupt, 98.4% idle
CPU 26:  0.4% user,  0.0% nice,  0.8% system,  0.0% interrupt, 98.8% idle
CPU 27:  0.0% user,  0.0% nice,  4.7% system,  0.0% interrupt, 95.3% idle
CPU 28:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle
CPU 29:  0.4% user,  0.0% nice,  0.8% system,  0.0% interrupt, 98.8% idle
CPU 30:  0.0% user,  0.0% nice,  2.7% system,  0.0% interrupt, 97.3% idle
CPU 31:  0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle
CPU 32:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle
CPU 33:  0.0% user,  0.0% nice,  3.5% system,  0.0% interrupt, 96.5% idle
CPU 34:  0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle
CPU 35:  0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle
CPU 36:  1.2% user,  0.0% nice,  1.6% system,  0.0% interrupt, 97.3% idle
CPU 37:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU 38:  0.4% user,  0.0% nice,  1.2% system,  0.4% interrupt, 98.1% idle
CPU 39:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU 40:  0.0% user,  0.0% nice,  1.9% system,  0.0% interrupt, 98.1% idle
CPU 41:  0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle
CPU 42:  0.4% user,  0.0% nice,  1.9% system,  0.0% interrupt, 97.7% idle
CPU 43:  0.0% user,  0.0% nice,  4.7% system,  0.0% interrupt, 95.3% idle
CPU 44:  0.0% user,  0.0% nice,  2.3% system,  0.0% interrupt, 97.7% idle
CPU 45:  0.4% user,  0.0% nice,  2.7% system,  0.0% interrupt, 96.9% idle
CPU 46:  0.4% user,  0.0% nice,  3.5% system,  0.0% interrupt, 96.1% idle
CPU 47:  0.4% user,  0.0% nice,  1.6% system,  0.0% interrupt, 98.1% idle
Mem: 82G Active, 23G Inact, 15G Wired, 3340K Cache, 1655M Buf, 4858M Free
ARC: 12G Total, 527M MFU, 11G MRU, 4375K Anon, 377M Header, 89M Other
Swap: 4096M Total, 12M Used, 4084M Free

 PID USERNAME     PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
12461 root          31    0 12268K  2552K zio->i 30   0:07  18.16% cp
3151 mysql         24    0 92309M 92073M uwait   3  22:06   7.47% mysqld{mysqld}
3151 mysql         22    0 92309M 92073M select 33  15:30   4.79% mysqld{mysqld}
3151 mysql         20    0 92309M 92073M uwait  46 895:41   0.49% mysqld{mysqld}
12175 wfaulk        20    0 23864K  6404K CPU25  25   0:03   0.29% top
6074 root          20    0 84348K 40372K kqread 25   0:11   0.20% vc-aggregator{vc-aggregator}

（其餘程序顯示 CPU 使用率為 0.00%。）

MFI 控制器昨天完全失效。我猜這種緩慢只是即將發生的硬體故障的早期症狀。

您是否嘗試重新啟動機器？有什麼不同嗎？

如果重新啟動沒有幫助，您所面臨的可能是過度碎片的問題，這是旋轉媒體的第一大敵人（閱讀：HDD）。大量快照會加劇這種情況。

要確認問題，請嘗試以下操作：

  1. 使用命令創建一個新的類似大小的文件fallocate testfile.raw -l <size>
  2. 嘗試讀取新分配的文件。如果它讀取速度很快，那麼舊文件的碎片可能是罪魁禍首。

如果您確認這是一個碎片問題，請按照下列步驟操作：

  1. 停止 MySQL
  2. 備份您的 table.ibd 文件
  3. 將其重命名為 table.ibd.old ( mv table.ibd table.ibd.old)
  4. 將其複製到之前的文件名 ( cp -a table.ibd.old table.ibd)
  5. 重啟 MySQL

iostat 更新後編輯

感謝您提供 iostat 號碼。

您在大約 67 秒內將一個 15 GB 的文件移至 ZFS 陣列，這意味著每個磁碟的攝取速率為 223 MB/s 或 55 MB/s（不包括鏡像磁碟）。另一方面，您的 iostat 似乎報告了這一點（大約 25 MB/s），所以我將這種差異歸因於大約 2:1 的壓縮比。

好的，這很好。然而，在閱讀過程中發生了奇怪的事情……

丟棄cat結果（cat預設情況下使用非常小的緩衝區，並且禁用預取器肯定會慢得多cp），該cp命令會變慢：您在大約 1530 秒內複製了一個 15 GB 的文件，這意味著提取率只有 10 MB /秒。這已經是壓縮優勢的因素。另一方面，您的 iostat 數字顯示每個磁碟的讀取速度超過 5 MB/s，每個陣列加起來約為 40 MB/s。考慮到 2:1 的壓縮比，它應該為您提供 80 MB/s 以上的傳輸速率。這意味著您的閱讀潛力大約是 1/8。

問題是：為什麼？看起來確實是在傳輸過程中 CPU 已用盡。您可以在讀取受影響的文件期間執行一個top和一個會話嗎？dstat如果可能，配置top顯示每個 CPU 的負載。

引用自：https://serverfault.com/questions/708082

相關問答

Performance

有效地從 ZFS 中刪除 10M+ 文件

  • September 8, 2016
檢視問答
Performance

zfs 慢 - 池 76% 已滿。性能問題的可能原因？

  • October 17, 2022
檢視問答
Unix

我應該使用整個磁碟或分區創建 ZFS zpools 嗎？

  • February 15, 2022
檢視問答
Performance

具有大容量儲存的高速網路寫入

  • October 5, 2021
檢視問答
Performance

在 EC2 上讀取訪問速度更快；本地驅動器還是 EBS？

  • November 13, 2020
檢視問答
Raid

ZFS 在硬體鏡像之上，還是只是在 ZFS 中鏡像？

  • May 22, 2020
檢視問答