在 ZFS 上跑 PostgreSQL 的調校

在「Everything I've seen on optimizing Postgres on ZFS」這邊看到如果要在 ZFS 上面跑 PostgreSQL 時的調校方式,看起來作者有一直在更新這篇,所以需要的時候可以跑去看...

主要的族群是要搞 self-hosted PostgreSQL 的人,相較於 ext4 或是 XFS,底層如果使用 ZFS 可以做許多事情,像是 compression 與 snapshot,這對於很多 DBA 相關的操作會方便不少,但也因為 ZFS 的關係,兩邊 (& PostgreSQL) 需要一起調整以確保效能...

不過短期應該還是用 RDS 就是了...

PostgreSQL 14 支援的 LZ4 壓縮

Hacker News 上看到 PostgreSQL 14 新支援的 LZ4 壓縮:「The LZ4 introduced in PostgreSQL 14 provides faster compression (fastware.com)」,在討論裡面反而有提到可以用 ZFS 的壓縮,這樣所有的資料 (包括 index) 都可以被壓縮:

If you are using ZFS, I strongly recommend using LZ4 or ZSTD compression with PostgreSQL. Performance is still awesome. On average I get 2x compressionratio with LZ4 and 4x with ZSTD.

With this, you are compressing everything, not just columns. And ZFS has dynamic block sizes which works really great together with compression. For example a 8kb PostgreSQL page, may be stored as a 1kb compressed block on disk.

而且通常開了壓縮後,整機的效率都會比較好。主要是因為資料庫的資料夠大時 (超過記憶體大小) 通常效能會先卡在 Disk I/O 的部份,這時候 CPU 會太閒;如果挑個輕量的壓縮演算法的話,雖然 CPU 使用率會拉高一些,但會大幅降低 Disk I/O 的量,在很多情況下就會提昇效能...

上面提到主要是 OLTP 的情況下,如果是在 OLAP 的場景下就更明顯了,基本上大家都是預設開著壓縮在處理所有資料。

另外在很多 RPC 類的系統也有類似的現象,資料傳輸量已經太大會超過 Network I/O 可以提供的量,這時候導入一些輕量的壓縮演算法就能大幅提昇系統效能。

以前有讀到一些壓縮演算法的比較,像是先前有翻到的「Evaluating Database Compression Methods: Update」,針對演算法的部份分析,裡面最後一張圖可以看到比較:

從比較圖可以穿來 Snappy 後來被 LZ4 淘汰掉,主要就是 LZ4 的壓縮率比較好,壓與解的速度又比較快,沒有理由繼續 Snappy。

另外 Zstandard 也逐步在淘汰 gzipzlib 類的壓縮,不過畢竟 gzip 與 zlib 的歷史真的太久,這邊淘汰的速度不快...

用 Ephemeral Storage 加速 MySQL over ZFS 的效能

Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。

一開始測試是直接當主力硬碟來測,可以看到跑 ZFS 的情況下,本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少:

但把資料放在本地的 storage 上其實有點刺激,至少在 production 應該不太會這樣搞,所以後面用 L2ARC 的方式來測,可以看到效率提昇相當明顯,甚至接近本來直接把資料放在本地的 storage:

另外測了 ext4/bcache,看起來效率就沒那麼好:

這樣看起來是個不錯的選擇...

MySQL 跑在 ZFS 與 ext4 的效能差異

Percona 的「MySQL/ZFS Performance Update」這篇又對 ZFS 做了一次測試,算是用比較新的軟體跑出來的結果,不過要注意這邊的 ZFS 版本仍然不是目前最新版:

ZFS 0.8.6-1 is not bleeding edge, there have been more than 1700 commits since and after 0.8.6, the ZFS release number jumped to 2.0. The big addition included in the 2.0 release is native encryption.

機器是在雲端上 (Azure 上),不熟悉 Azure 的機種,但看記憶體與 CPU 的量好像不是用頂規的機器:

benchmark host
Standard D2ds_v4 instance
2 vCpu, 8GB of Ram and 75 GB of temporary storage
Debian Buster

Database host
Standard E4-2ds-v4 instance
2 vCpu, 32GB of Ram and 150GB of temporary storage
256GB SSD Premium (SSD Premium LRS P15 – 1100 IOPS (3500 burst), 125 MB/s)
Debian Buster
Percona server 8.0.22-13

跑出來的結果看起來不差:

看了一下測試用的設定,似乎只測了 compression 的部份,沒測 snapshot 以及其他功能會對效能有什麼影響,但至少基本盤應該是還不錯?

ZFS 租用服務

看到「zfs.rent」這個網站:

We have a couple of ZFS-based NAS systems. We wanted a simple cloud service so we could run:

$ zfs send -v -R -I pool/snapshot_034 pool/snapshot_042 |\
    ssh marvin@marvin.zfs.rent zfs recv -v -Fu pool/snapshots

看起來是用 Linux 上的 OpenZFS 架的,每個 instance 提供 4GB RAM,這個部份應該還好,但只提供 1TB 的流量 (上傳與下載都要算),這部份看起來就有點不太夠用了,以這種服務來說蠻容易踩到 overcharge 的部份。

作業系統的部份可以選擇 Ubuntu 20.04 或是 CentOS 8.2。

以架構上來說可以當作是某種特化的 VPS (底層的 raw disk 直接掛上來),以這個角度來看的話,機器部份的費用看起來還好,但頻寬部份會拉高整體成本。

這個服務看起來比較像是噱頭吧,看看就好...

將 Ubuntu 安裝在 ZFS 上...

看到 Ubuntu 在安裝時支援 ZFS 的消息:「A detailed look at Ubuntu’s new experimental ZFS installer」。另外 Twitter 上也有截圖了:

看了一下授權問題,看起來是 Ubuntu 認定這樣做不會有問題,但目前還沒被 Oracle 出手,所以也不曉得真的出手後會發生什麼事情...

Dropbox 的 non-ext4 支援回鍋

Dropbox 去年的時候拔掉非 ext4 檔案系統的支援,被罵翻也不鳥 (參考「Linux 版的 Dropbox 在十一月後將只支援 ext4...」),結果現在又回來支援了:「Dropbox Brings Back Support For ZFS, XFS, Btrfs And eCryptFS On Linux」。

出自 beta 版的說明「Beta Build 77.3.127」這邊:

Add support for zfs (on 64-bit systems only), eCryptFS, xfs (on 64-bit systems only), and btrfs filesystems in Linux.

不過我不是因為這個而搬走 (因為我用 ext4),反而是在對免費版限制時跳走:「Dropbox 免費版限制三個裝置更新...」。

當初用 X-attrs 當理由,看起來是有人離職了所以就加回來...

Software Freedom Conservancy 對 Ubuntu 認定 ZFS 相容性的反對意見

在「Ubuntu 搞定 ZFS 授權問題,將直接納入系統中使用」這邊提到了 Canonical 的律師們認為搞定 ZFS 的授權問題。

Software Freedom Conservancy 則是提出反對意見:「GPL Violations Related to Combining ZFS and Linux」。

主要是討論 GPLv2CDDLv1 的感染性相容問題。

我是覺得 Ubuntu 的說法比較合理,但這種事情沒上法院前誰都不知道... (而且第一仗的結果會特別重要)

Ubuntu 搞定 ZFS 授權問題,將直接納入系統中使用

Canonical 的人 (Ubuntu 背後的公司) 跟律師研究後決定採用 .ko 的方式 (就像 nvidia.ko 的方式) 納入 ZFS,讓 Ubuntu 的人可以更方便使用,而不是像現在要另外手動做不少步驟:「ZFS Licensing and Linux」。

依照 Canonical 的研究,CDDL (ZFS) 與 GPLv2 (Linux) 的授權方式不同,所以可以找到方法交叉避開衝突:

While the CDDL and GPLv2 are both "copyleft" licenses, they have different scope. The CDDL applies to all files under the CDDL, while the GPLv2 applies to derivative works.

The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module -- the kernel itself is quite obviously not a derivative work of this new file system.

And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules.

至於這種說法是不是成立,至少在還沒上法院認證前也還不知道... 不過看起來 Canonical 是頗有自信,打算將 ZFS 弄進 Ubuntu,上面有不少好用的東西...

試玩 LXD

LXDCanonical (Ubuntu 的那家公司) 推的 container 系統,在「Super Fast Local Workloads With LXD, ZFS, and Juju」這篇文章裡雖然是提 ZFS + Juju 這兩個東西,但 LXD 的部份還是給了些可以直接拿來用的資訊。

首先先安裝 LXD,我是裝 ppa:ubuntu-lxc/stable 這個版本,裝完 lxd 後就照著先執行:

$ newgrp lxd
$ lxd init

由於沒有裝 zfs,就用 dir 模式跑就好了。網路的部份就先選 no 混過去,反正 NAT 會通... 接著就拉 image 回來:

$ lxd-images import ubuntu trusty amd64 --sync --alias ubuntu-trusty

拉完後就可以跑起來了:

$ lxc launch ubuntu-trust test
$ lxc exec test /bin/bash

直接打 lxc 也可以看到一些說明,用過 Docker 的人應該是沒什麼問題,還蠻簡單的。