幹壞事是進步最大的原動力
在 Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。
一開始測試是直接當主力硬碟來測，可以看到跑 ZFS 的情況下，本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少：
但把資料放在本地的 storage 上其實有點刺激，至少在 production 應該不太會這樣搞，所以後面用 L2ARC 的方式來測，可以看到效率提昇相當明顯，甚至接近本來直接把資料放在本地的 storage：
這樣看起來是個不錯的選擇...
Backblaze 昨天放出來 2021Q1 的硬碟報告：「Backblaze Drive Stats for Q1 2021」。
前半部沒有什麼意外，HGST 的硬碟比起其他家的看起來還是好不少。
比較有趣的是首次拿 SSD 與 HDD 對決，這邊比較的對象是開機碟。可以看到如果以 2021Q1 的時間來看，SSD 的 AFR 低不少：
拉長到 lifetime 來看也還是低不少：
但裡面也有提到 HDD 的最大壽命比目前 SSD 都高不少，時間看起來可能還不夠長，算是一個很初步的資料...
這篇「Achieving 11M IOPS & 66 GB/s IO on a Single ThreadRipper Workstation」用了 AMD 平台上的 PCI-e 4.0 硬幹出 4K 隨機讀取 11M IOPS 的速度，另外在大區塊讀取可以到 66GB/sec，後面這個速度應該是可以把 DDR4 記憶體頻寬吃滿...
硬體的部份，作者用了 8*1TB + 2*500GB 的 M.2 SSD 來建這組系統，然後接到卡上：
不過他好像沒提到這組機器的價錢 (雖然每個單品都查的到)，大概算了一下 storage 的部份其實不怎麼貴，Samsung 980 Pro PCIe 4.0 M.2 SSD 的部份，1TB 每一條要 USD$160，500GB 要 USD$120，旁邊那些 CPU 與記憶體反而貴不少... 不過整台機器應該有機會在 USD$10000 搞定？
感覺拿來給剪片的人用很爽？至少在處理讀寫的時候應該是很順...
可以先參考「Amazon EBS 推出了 gp3」這篇，但剛出來的時候大家都有發現無論是透過 web console 還是透過 awscli，boot disk 都沒辦法改成 gp3，可是在官方的文件上又說可以用 gp3，所以就有人在 AWS 的 forum 上發問了：「EBS GP3 Boot Volume Issues」。
直到剛剛發現已經可以改成 gp3 了... 一個一個手動改當然也是 OK，但對於有一卡車 EBS 要換的人來說鐵定得弄指令來換，這邊搭配了 jq 一起改：
aws ec2 describe-volumes | jq '.Volumes[] | select(.VolumeType == "gp2") | .VolumeId' | xargs -n1 -P4 env aws ec2 modify-volume --volume-type gp3 --volume-id
這邊是把 gp2 都改成 gp3，沒有考慮到空間大小的問題 (因為超過 1TB 時 gp2 給的 IOPS 會比較多)，另外 -P4 是平行四個 process 跑，改起來會快一些...
Amazon EBS 的另外一個新推出的東西，是針對 io2 的改善：
前面兩則消息可以一起看，主要是推出了 EBS Block Express，有著效能上的提昇：
Built on our new EBS Block Express architecture that takes advantage of some advanced communication protocols implemented as part of the AWS Nitro System, the volumes will give you up to 256K IOPS & 4000 MBps of throughput and a maximum volume size of 64 TiB, all with sub-millisecond, low-variance I/O latency. Throughput scales proportionally at 0.256 MB/second per provisioned IOPS, up to a maximum of 4000 MBps per volume. You can provision 1000 IOPS per GiB of storage, twice as many as before. The increased volume size & higher throughput means that you will no longer need to stripe multiple EBS volumes together, reducing complexity and management overhead.
目前因為是 preview 階段，想要用的人需要申請測試。要注意目前支援的區域有限 (不像這次推出 gp3 的時候就是全區)，而且需要搭配 r5b 的機器：
The preview is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), and Europe (Frankfurt) Regions. During the preview, we support the use of R5b instances, with support for other Nitro-powered instances in the works.
第三則消息則是在講 io2 的 IOPS 的折扣，針對購買 32K IOPS 以上的部份會有 30% 折扣：
Now, with the new tiered pricing structure, the first 32,000 IOPS provisioned on a volume are charged at the current base rate ($0.065 per provisioned IOPS-mo) and the second tier between 32,001 and 64,000 is charged at a 30% lower rate ($0.046 per provisioned IOPS-mo).
針對前面提到的 preview 版本 (EBS Block Express)，因為可以超過 64K IOPS，這個部份的價錢會更低，再疊一次 30% 的折扣：
Furthermore, for customers who have even higher performance requirement than currently supported by a single io2 volume today, we are previewing io2 volumes that run on EBS Block Express, the next generation of our block storage architecture. io2 Block Express volumes can be provisioned to deliver peak IOPS of 256,000. For these volume, any IOPS provisioned over 64,000 IOPS will be charged at a further 30% lower rate than the second tier ($0.032 per provisioned IOP-mo for IOPS over 64,000). This lowers the effective rate to $0.038 per provisioned IOPS on a volume provisioned with 256,000 IOPS.
算是要衝效能的人用的，目前平常應該還是會用 gp2 或是 gp3 的 SSD...
今年的 AWS re:Invent 又開始了，不過因為疫情的關係，這次是線上為主... 這邊先來整理一下 Amazon EBS 相關的更新。
首先是推出了新的 gp3 類型，也是 SSD 類：「New – Amazon EBS gp3 Volume Lets You Provision Performance Apart From Capacity」。
每 GB 單位成本比 gp2 低 20%：
Today I would like to tell you about gp3, a new type of SSD EBS volume that lets you provision performance independent of storage capacity, and offers a 20% lower price than existing gp2 volume types.
然後直接給你 3000 IOPS 與 125MB/sec，有需要更高的話可以「加購」：
gp3 is designed to provide predictable 3,000 IOPS baseline performance and 125 MiB/s regardless of volume size. It is ideal for applications that require high performance at a low cost such as MySQL, Cassandra, virtual desktops and Hadoop analytics. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MiB/s for an additional fee. The top performance of gp3 is 4 times faster than max throughput of gp2 volumes.
但照「Amazon EBS volume types」這邊的列表可以看到，要注意 gp2 可以 burst 的 throughput (250MB/sec) 比 gp3 的 baseline (125MB/sec) 高。
也因為這樣，可以把一些 random access 比較多的 /data 這類的 EBS 換過去，但如果是要大量 sequential access 的也許就不適合了。
IOPS 的部份，1TB 以下的 gp2 換過去應該是沒什麼太大問題，因為在 gp2 的時候是 1GB 給 3IOPS，所以 1TB 以下的 gp2 都低於 3000IOPS。
轉移的部份可以在 AWS 的 console 上直接 migrate 到 gp3：
If you’re currently using gp2, you can easily migrate your EBS volumes to gp3 using Amazon EBS Elastic Volumes, an existing feature of Amazon EBS. Elastic Volumes allows you to modify the volume type, IOPS, and throughput of your existing EBS volumes without interrupting your Amazon EC2 instances.
像是這樣：
但照「Amazon EBS volume types」這邊的列表，gp3 可以是開機硬碟
Update：剛剛發現文件被修正了，看起來不能當開機硬碟...
不知道哪邊搞錯了，過幾天看看吧 XDDD
在 Hacker News 看到 Raspberry Pi 400 的使用心得：「I've now played with a Raspberry Pi 400 for a week and here are my conclusions」，先前在「Raspberry Pi 400」這邊有提到 Raspberry Pi 400，主要就是一台 Raspberry Pi 4 Model B 的主機，但跟鍵盤整合在一起。
在文章裡提到了 Raspberry Pi 4 可以 USB Boot 後帶來的改變 (參考之前寫的「Raspberry Pi 4 可以透過 USB 開機了」這篇)，主要是透過 USB3 外接硬碟可以讓讀寫速度大幅提昇 (尤其是 SSD)，這一直都是 Raspberry Pi 上面用 SD card 的問題，看起來唯一的問題還是 CPU 的速度還是沒有像目前常見的 x86-64 強。
If you give it fast enough "disk" storage it really moves. I plugged in a Kingston brand 120GB SSD on a USB3 adapter. hdparm -t gave 292MB/s read speed and the default LXDE environment was really crisply responsive, with even a first launch of Chromium taking less than two seconds. With such good storage, the only real limitation is that heavy Javascript stuff is too slow - 5+ seconds to switch between folders in Chrome, or for the thumbnail gallery to appear in Youtube. Also, video calling is marginal. Aside from that the CPU is fast enough.
另外討論裡面也有人希望 Raspberry Pi 考慮引入 eMMC 或是提供 M.2 界面改善讀寫速度，不過我覺得 SD card 的設計算是 Raspberry Pi 當初的方向，本來就有取捨，不太可能什麼都做進去...
回到作者的心得，雖然 USB3 轉 SSD 看起來 i/o 速度快不少，但我好像主要不是遇到 i/o 速度問題，反倒是最近 chromium 的硬體解碼好像有些進度，也許看影片有機會用硬體處理 (至少一部份？)，希望至少可以輕鬆看 1080p60 啊...
Amazon EBS 保障 IO 效能的版本 Provisioned IOPS io1 進化了，推出了 Provisioned IOPS io2：「New EBS Volume Type (io2) – 100x Higher Durability and 10x More IOPS/GiB」。
目前先看了一下美國與新加坡的價錢，應該都還是一樣，看起來這次主要是功能性上的進步，有兩個比較顯著的改變。
第一個是每 GB 可以租用的 IOPS 數量上升了，io1 是 50 IOPS，在 io2 給到 500 IOPS；不過最大值不變，都還是 64k IOPS。這個看起來對於追求 IOPS 的人彈性增加不少，不過算了一下成本差距應該是還好，以最大的 64k IOPS 來算，光 IOPS 的費用就要 USD$4160/month，而最低的空間租量上，io1 租 1280 GB (USD$160/month) 與 io2 租 128 GB (USD$16/month) 在這個部分只能算零頭了...
第二個是持久性 (durability)，從 io1 的 99.9% 到 io2 變成 99.999% 了，這邊應該主要是受益於這十年 SSD 技術的進步。我猜本來的 io1 其實也拉高不少，只是 SLA 合約上沒有增加而已...
應該還是會守在 gp2 上，便宜大碗，不過效能的保證少了些，對於一般性的應用來說應該是夠用。
看起來應該是找 Percona 的人幫忙轉移到 MyRocks 上，然後整理出來的成功案例：「The Road Story of a MyRocks/MariaDB Migration」。
看起來是跑在獨立機器上，而不是雲端的虛擬機上，所以不是想 scale up 就可以把硬體規格拉上去 (說不定記憶體插槽已經滿了之類的...)：
Replicas run on bare metal servers, usually Dual Xeon E5 v3 or v4, with 192 GB to 384 GB of RAM.
這次遇到的主要的問題是發現效能跟不上。另外在文章裡面沒寫到，但可以猜到的是，他們目前不打算改架構，而是想要藉由改善資料庫的效能來解決問題：
The servers were close to their limits and were slow to catch up with replication after a maintenance period
後面可以看到不少過程，主要是重新編一份 MariaDB，讓 MyRocks 支援 Zstandard (MyRocks 支援 Zstandard，不過 MariaDB 內的 MyRocks 不知道為什麼關掉了...)，這點大幅降低了空間的佔用。
另外是遇到 OOM 問題，在改用 jemalloc 解決記憶體用量的問題後就解決了 (這個在使用 InnoDB 的時候也算是標配了)。
不過在「Increased Read Load Over Time」那段還是看到了 workaround：
The read load was still rising a bit but at a much smaller pace. Instead of hours, it was days. That’s kind of expected given the workload and we were already planning for periodic manual compactions.
目前看起來 MyRocks 的強項主要是在省資源，但缺點就是有不少眉眉角角得小心處理。這樣的話，一般應該還是會先用 InnoDB，真的搞大了再考慮要不要換過去...
前陣子的文章，Cloudflare 將不熱門的資料放到記憶體內，不寫到磁碟裡面：「Why We Started Putting Unpopular Assets in Memory」。
主要的原因是這些不熱門的資料常常是一次性的，寫到 SSD 裡面反而浪費 SSD 的生命。而且這樣做因為減少了寫入，反而可以讓 SSD 的讀取變快：
The result: disk writes per second were reduced by roughly half and corresponding disk hit tail latency was reduced by approximately five percent.
這個想法還蠻特別的，但好像印象中之前有人有提過類似的方法...
Anyway，這個想法不只在 CDN 這邊可以用到，對於有 memory + storage 架構的 cache system 也可以套用類似的道理，而要怎麼決定哪些 object 要寫到磁碟裡面的演算法就是重點了...
題外話，剛剛因為突然想到，瞄了一下 Squid，發現連 HTTPS 都還沒上...