我负责下载和处理大量财务数据。每个交易日，我们必须添加大约 100GB。
为了处理如此大量的数据，我们从我们大学的数据中心租用了一台虚拟服务器（3 个内核，12 GB 内存）和一个 30 TB 的块设备。
在虚拟机上，我在 Linux 上安装了 Ubuntu 16.04 和 ZFS。然后，我在 30TB 块设备上创建了一个 ZFS 池。使用 ZFS 的主要原因是压缩功能，因为数据可以很好地压缩 (~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/disk@0000iqn.2015-02.de.uni-konstanz.bigdisk%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 物理块？！
他们为我提供了一些临时文件系统，我可以将数据备份到其中。然后，在从头开始设置池之前，我将首先测试原始设备上的速度。我会发送更新。
更新 2
我破坏了原来的水池。然后我使用 进行了一些速度测试dd，结果还可以 - 双向大约 80MB/s。
作为进一步检查，我在设备上创建了一个 ext4 分区。我将一个大的 zip 文件复制到这个 ext4 分区，平均写入速度约为 40MB/s。不是很好，但足以满足我的目的。
我继续使用以下命令创建一个新的存储池
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 文件复制到新创建的test文件系统。写入速度很差，只有 2-5 MB/s 左右。
有任何想法吗？
更新 3
tgx_sync当我复制文件时被阻止。我在ZoL的github仓库上开了一张票。
您设置了ashift=0，当您的 HD 驱动器使用 4096 字节扇区时，这会导致写入速度变慢。如果没有ashift，ZFS 无法正确地将写入与扇区边界对齐 -> 当 ZFS 写入 512 字节扇区时，硬盘需要读取-修改-写入 4096 字节扇区。
用于ashift=12使 ZFS 将写入对齐到 4096 字节扇区。
您还需要检查分区相对于实际使用的硬盘的对齐方式是否正确。
| 归档时间： |
|
| 查看次数： |
10766 次 |
| 最近记录： |