我是否误解iostat结果，还是每分钟只写3.06 MB？
# zpool iostat -v 60
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 356G 588G 465 72 1.00M 3.11M
xvdf 356G 588G 465 72 1.00M 3.11M
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 356G 588G 568 58 1.26M 3.06M
xvdf 356G 588G 568 58 1.26M 3.06M
---------- ----- ----- ----- ----- ----- -----
目前rsync正在从其他HDD（ext4）写入文件。基于我们的文件特征（~50 KB文件），似乎数学是正确的3.06 * 1024 / 58 = 54 KB。
记录：
primarycache=metadata compression=lz4 dedup=off checksum=on relatime=on atime=off 服务器位于EC2，目前是1核，2GB RAM（t2.small），硬盘 - 亚马逊上最便宜的。操作系统 - Debian Jessie，zfs-dkms从debian testing存储库安装。
如果真的那么慢，为什么呢？有没有办法提高性能，而无需全部转移到SSD并添加8 GB的RAM？它可以在VPS上表现良好，还是ZFS设计时考虑到裸机？
修改
我添加了一个5 GB的通用SSD，用作ZIL，正如答案中所建议的那样。这没有多大帮助，因为似乎根本没有使用ZIL。在我的用例中，5 GB应该足够多，因为根据以下Oracle article我应该有1/2大小的RAM。
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 504G 440G 47 36 272K 2.74M
xvdf 504G 440G 47 36 272K 2.74M
logs - - - - - -
xvdg 0 4.97G 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 504G 440G 44 37 236K 2.50M
xvdf 504G 440G 44 37 236K 2.50M
logs - - - - - -
xvdg 0 4.97G 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
修改
dd测试表明速度相当不错。
# dd if=/dev/zero of=/mnt/zfs/docstore/10GB_test bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 29.3561 s, 366 MB/s
然而，iostat输出的带宽变化不大。注意更多的写操作。
# zpool iostat -v 10
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 529G 415G 0 40 1.05K 2.36M
xvdf 529G 415G 0 40 1.05K 2.36M
logs - - - - - -
xvdg 0 4.97G 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 529G 415G 2 364 3.70K 3.96M
xvdf 529G 415G 2 364 3.70K 3.96M
logs - - - - - -
xvdg 0 4.97G 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 529G 415G 0 613 0 4.48M
xvdf 529G 415G 0 613 0 4.48M
logs - - - - - -
xvdg 0 4.97G 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 529G 415G 0 490 0 3.67M
xvdf 529G 415G 0 490 0 3.67M
logs - - - - - -
xvdg 0 4.97G 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 529G 415G 0 126 0 2.77M
xvdf 529G 415G 0 126 0 2.77M
logs - - - - - -
xvdg 0 4.97G 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zfs-backup 529G 415G 0 29 460 1.84M
xvdf 529G 415G 0 29 460 1.84M
logs - - - - - -
xvdg 0 4.97G 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
答案 0 :(得分：2)
它可以在VPS上表现良好，还是ZFS设计时考虑到裸机？
两者都是。
最初它是专为裸机而设计的，那就是你自然会获得最佳性能和完整功能集（否则你必须信任底层存储，例如，如果在请求同步写入时写入真的提交到磁盘）。虽然它非常灵活，因为您的vdev可以包含您可用的任何文件或设备 - 当然，性能只能与底层存储一样好。
*）更确切地说：一般来说，在从RAM写入磁盘之前，所有小于一定大小的小同步写入都会在ZIL中收集，每隔五秒或大约4 GB发生一次，以先到者为准（所有那些参数可以修改）。这样做是因为：
通常ZIL驻留在池本身上，应该使用冗余vdev进行保护，使整个操作对于断电，磁盘崩溃，位错误等非常有弹性。缺点是池磁盘需要随机执行在更高效的连续传输中将相同的数据刷新到磁盘之前的小写入 - 因此建议将ZIL移动到另一个设备上 - 通常称为SLOG设备（ S eparate LOG 设备）。这可能是另一个磁盘，但是SSD在这个工作负载下表现得更好（并且会很快磨损，因为大多数事务正在通过它）。如果您从未遇到过崩溃，那么您的SSD将永远不会被阅读，只能写入。
答案 1 :(得分：1)
这个特殊问题可能是由于吵闹的邻居造成的。作为一个t2实例，你将获得最低优先级。在这种情况下，您可以停止/启动实例以获取新主机。
除非您正在使用实例存储（无论如何都不是t2实例的选项），所有磁盘写入都是基本上是SAN卷。 EBS系统的网络接口由同一主机上的所有实例共享。实例的大小将决定实例的优先级。
如果从一个卷写入另一个卷，则通过同一个接口传递所有读写流量。
根据您拥有的卷类型以及您的t2实例上是否还有任何CPU积分，可能还有其他因素在起作用