ZFS:读取良好但写入速度较差

我负责下载和处理大量的财务数据。 每个交易日,我们必须增加100GB左右。

为了处理这些数据,我们从我们大学的数据中心租用了一个虚拟服务器(3个核心,12 GB RAM)和一个30 TB的块设备。

在虚拟机上,我在Linux上安装了Ubuntu 16.04和ZFS。 然后,我在30TB块设备上创build了一个ZFS池。 使用ZFS的主要原因是压缩function,因为数据是可压缩的(〜10%)。 请不要因为没有遵循ZFS希望看到裸机的黄金规则而对我太苛刻,我不得不使用基础架构。

张贴的原因是我面临一个写速度差的问题。 服务器能够从块设备读取大约50 MB / s的数据,但写入数据的速度非常慢,大约为2-4 MB / s。

以下是有关池和数据集的一些信息:

zdb

 tank: version: 5000 name: 'tank' state: 0 txg: 872307 pool_guid: 8319810251081423408 errata: 0 hostname: 'TAQ-Server' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 8319810251081423408 children[0]: type: 'disk' id: 0 guid: 13934768780705769781 path: '/dev/disk/by-id/scsi-3600140519581e55ec004cbb80c32784d-part1' phys_path: '/iscsi/[email protected]%3Asn.606f4c46fd740001,0:a' whole_disk: 1 metaslab_array: 30 metaslab_shift: 38 ashift: 9 asize: 34909494181888 is_log: 0 DTL: 126 create_txg: 4 features_for_read: com.delphix:hole_birth com.delphix:embedded_data 

zpool get all

 NAME PROPERTY VALUE SOURCE tank size 31,8T - tank capacity 33% - tank altroot - default tank health ONLINE - tank guid 8319810251081423408 default tank version - default tank bootfs - default tank delegation on default tank autoreplace off default tank cachefile - default tank failmode wait default tank listsnapshots off default tank autoexpand off default tank dedupditto 0 default tank dedupratio 1.00x - tank free 21,1T - tank allocated 10,6T - tank readonly off - tank ashift 0 default tank comment - default tank expandsize 255G - tank freeing 0 default tank fragmentation 12% - tank leaked 0 default tank feature@async_destroy enabled local tank feature@empty_bpobj active local tank feature@lz4_compress active local tank feature@spacemap_histogram active local tank feature@enabled_txg active local tank feature@hole_birth active local tank feature@extensible_dataset enabled local tank feature@embedded_data active local tank feature@bookmarks enabled local tank feature@filesystem_limits enabled local tank feature@large_blocks enabled local 

zfs get all tank/test

 NAME PROPERTY VALUE SOURCE tank/test type filesystem - tank/test creation Do Jul 21 10:04 2016 - tank/test used 19K - tank/test available 17,0T - tank/test referenced 19K - tank/test compressratio 1.00x - tank/test mounted yes - tank/test quota none default tank/test reservation none default tank/test recordsize 128K default tank/test mountpoint /tank/test inherited from tank tank/test sharenfs off default tank/test checksum on default tank/test compression off default tank/test atime off local tank/test devices on default tank/test exec on default tank/test setuid on default tank/test readonly off default tank/test zoned off default tank/test snapdir hidden default tank/test aclinherit restricted default tank/test canmount on default tank/test xattr on default tank/test copies 1 default tank/test version 5 - tank/test utf8only off - tank/test normalization none - tank/test casesensitivity mixed - tank/test vscan off default tank/test nbmand off default tank/test sharesmb off default tank/test refquota none default tank/test refreservation none default tank/test primarycache all default tank/test secondarycache all default tank/test usedbysnapshots 0 - tank/test usedbydataset 19K - tank/test usedbychildren 0 - tank/test usedbyrefreservation 0 - tank/test logbias latency default tank/test dedup off default tank/test mlslabel none default tank/test sync disabled local tank/test refcompressratio 1.00x - tank/test written 19K - tank/test logicalused 9,50K - tank/test logicalreferenced 9,50K - tank/test filesystem_limit none default tank/test snapshot_limit none default tank/test filesystem_count none default tank/test snapshot_count none default tank/test snapdev hidden default tank/test acltype off default tank/test context none default tank/test fscontext none default tank/test defcontext none default tank/test rootcontext none default tank/test relatime off default tank/test redundant_metadata all default tank/test overlay off default tank/test com.sun:auto-snapshot true inherited from tank 

你能给我一个提示,我可以做些什么来提高写入速度?

更新1

在您对存储系统的评论之后,我去了IT部门。 那家伙告诉我,vdev出口的逻辑块实际上是512 B.

这是dmesg的输出:

 [ 8.948835] sd 3:0:0:0: [sdb] 68717412272 512-byte logical blocks: (35.2 TB/32.0 TiB) [ 8.948839] sd 3:0:0:0: [sdb] 4096-byte physical blocks [ 8.950145] sd 3:0:0:0: [sdb] Write Protect is off [ 8.950149] sd 3:0:0:0: [sdb] Mode Sense: 43 00 10 08 [ 8.950731] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 8.985168] sdb: sdb1 sdb9 [ 8.987957] sd 3:0:0:0: [sdb] Attached SCSI disk 

那么512 B逻辑块,但是4096 B物理块?

他们提供了一些临时文件系统,我可以备份这些数据。 然后,我将首先在原始设备上testing速度,然后再从头开始设置池。 我会发送更新。

更新2

我摧毁了原来的游泳池。 然后我使用dd了一些速度testing,结果是好的 – 两个方向都是80MB / s左右。

作为进一步的检查,我在设备上创build了一个ext4分区。 我拷贝了一个大的zip文件到这个ext4分区,平均写入速度大约是40MB / s。 不是很好,但足以达到我的目的。

我继续使用以下命令创build新的存储池

 zpool create -o ashift=12 tank /dev/disk/by-id/scsi-3600140519581e55ec004cbb80c32784d zfs set compression=on tank zfs set atime=off tank zfs create tank/test 

然后,我再次将一个zip文件复制到新创build的test文件系统。 写入速度很差,仅为2-5 MB / s左右。

有任何想法吗?

更新3

当我复制文件时, tgx_sync被阻止。 我在ZoL的github存储库上打开了一张票。

你已经设置了ashift=0 ,当你有使用4096字节扇区的高清驱动器时,这导致写入速度变慢。 在没有ashift ,当ZFS写入512字节扇区时,ZFS不能正确地将写入alignment到扇区边界 – >硬盘需要读取 – 修改 – 写入4096字节的扇区。

使用ashift=12使ZFSalignment写入到4096字节的扇区。

您还需要检查分区的alignment方式是否与正在使用的实际硬盘相对。