幹壞事是進步最大的原動力
AWS 在「Introducing Amazon EC2 M7a instances (Preview)」這邊看到 m7a 會比 m6a 快 50% 的宣稱：
These instances deliver up to 50% greater performance on average compared to M6a instances.
目前還是 preview 階段，需要申請才有機會用，所以還不知道他的真實性能是怎麼樣？另外一方面，價錢也還沒查到... 但如果價錢不要漲太多的話，算一下好像有可能跟上 ARM 的 m7g 了？
另外這樣也就蠻值得期待會不會有 t4a？
把一台本來跑在 Vultr 上的機器搬到 AWS 的 us-east-1 上面，除了剛好把 Ubuntu 18.04 換成 Ubuntu 22.04 外，也把本來用 x86-64 架構的機器換成用 ARM 的 t4g.micro (都是 1GB RAM)。
就效能上來說，t4g 機器的效能很不錯，這兩年 blog 跑的也都還算順，先前公司用起來感覺也很好，然後價錢更便宜，另外加上 AWS 的三年 RI 折扣大約是 4 折的價錢，算是會想要換的主因。
在確認應用跑得起來後，買三年 RI 是 $87.15/3y，所以機器本身的費用大約是 $29.05/y，就算加上 8GB 的 EBS (gp3) 空間費用，整體比本來在 Vultr 的 $6/mo 低不少。
上面跑的是我自己的 Trac，想搬到 AWS 上一陣子了，但有幾個不確定的因素，所以連假期間才有空多花一些時間確認。
第一個是 MySQL 的部份，我自己習慣用 Percona Server 的版本，但目前還沒有 arm64 的套件可以直接裝，要用的話就得自己編以及升級。
在 2021 年的時候 blog 搬到 AWS 的時候就遇過了，本來以為這次有機會，但看了一下還是沒支援，所以還是得用 MariaDB。
第二個是 Trac 1.4 只能跑在 Python 2.7 上 (mailing list 上有在討論轉到 Python 3 的事情，但看起來官方的動力也不大...)，這在 18.04 的時代是沒什麼問題，但 22.04 下面不知道會爛掉多少東西。
所以只能繼續用 pyenv 扛著，但已經有預期會遇到問題，加上這次又從 MySQL 轉到 MariaDB，應該也會有些地雷...
所以跳下去後遇到的問題就跟上面提到的類似，分成兩塊。
在 MariaDB 這邊第一個遇到問題是，雖然官方有提供 APT server，但沒有在 HTTPS server 上放新的 public key，所以一定得從 key server 撈。
但 GnuPG 就是沒有直接從 key server 下載變成檔案的功能，一定要先塞到 keystore 裡面再 export 出來，就覺得很...
所以就冒出利用 mktemp -d 在 /tmp 下產生暫存目錄這樣的寫法，讓 GnuPG 把 keystore 放進去，這樣至少在重開機後就會消失：
export GNUPGHOME=$(mktemp -d); gpg --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x177F4010FE56CA3336300305F1656F24C74CD1D8; gpg --export 0x177F4010FE56CA3336300305F1656F24C74CD1D8 | sudo tee /etc/apt/trusted.gpg.d/mariadb.gpg > /dev/null; unset GNUPGHOME
這邊為了安全性，還得把官方提供的 0xF1656F24C74CD1D8 換成 0x177F4010FE56CA3336300305F1656F24C74CD1D8。
另外就是整理 MariaDB 需要的 my.cnf 內容，我是拿 Percona Server 5.7 的設定檔來改，只刪掉了跟 GTID 相關的設定就會動了。
而其他 MariaDB 遇到的問題主要是設計改變的問題，在 wiki 上有提到。
接下來是 Trac 1.4 的問題，本來的安裝是用 libmysqlclient-dev，然後再安裝 mysql-python：
sudo apt install -y libmysqlclient-dev pip install mysql-python PyMySQL Pygments Trac
但單純把 libmysqlclient-dev 換成 libmariadb-dev 後，mysql-python 還是編不動，照著錯誤訊息試著 workaround (像是試著把 /usr/bin/mysql_config 指到 /usr/bin/mariadb_config) 半天還是不過，最後找資料發現要改用 mysqlclient：
sudo apt install -y libmariadb-dev pip install mysqlclient PyMySQL Pygments Trac
搞定後後續就一路看錯誤訊息解就可以了...
Amazon EC2 推出了 Graviton3 的機種：「New Graviton3-Based General Purpose (m7g) and Memory-Optimized (r7g) Amazon EC2 Instances」。
第一波只有一般的 在去年五月就推出了：「AWS 推出 c7g 機種」。m7g 與記憶體型的 r7g，而計算型的 c7g 大家在 Twitter 上猜應該晚點會放出消息。
目前只在歐美的 us-east-1、us-east-2、us-west-2 與 eu-west-1 區提供，亞洲目前都還沒有這些機種可以用：
M7g and R7g instances are available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Ireland) AWS Regions in On-Demand, Spot, Reserved Instance, and Savings Plan form.
官方宣稱比 Graviton2 的 m6g & r6g 多了 25% 的效能，不過我另外查了一下 us-east-1 上的價錢，也貴了 6% 左右，如果依照官方宣稱的數字計算，大約是 18% 左右的 CP 值提昇，對於有實際上跑滿的 CPU 的人是個不錯的效能提昇：
Today I am happy to tell you about the newest Amazon EC2 instance types, the M7g and the R7g. Both types are powered by the latest generation AWS Graviton3 processors, and are designed to deliver up to 25% better performance than the equivalent sixth-generation (M6g and R6g) instances, making them the best performers in EC2.
裡面有提到在 Graviton3 的一個架構上的大改變是記憶體從 DDR4 變到 DDR5，這使得記憶體的傳輸頻寬提昇了 50%：
Both types of instances are equipped with DDR5 memory, which provides up to 50% higher memory bandwidth than the DDR4 memory used in previous generations.
接下來是看有沒有下放到 t 系列的計畫，像是 t5g 之類的，有的話再用看看好了，不過 blog 這台已經買了三年 RI，等到期間滿了之後說不定都有 Graviton4 或是 Graviton5 了...
AWS 在 Amazon EC2 產品線上推出了新一代的 ARM 產品，AWS Graviton3 架構，c7g 系列機種：「New – Amazon EC2 C7g Instances, Powered by AWS Graviton3 Processors」。
Graviton3 宣稱比 Graviton2 多 25% 的一般性效能，以及多了一倍的浮點效能，還有 DDR5 的頻寬優勢：
Our next generation, Graviton3 processors, deliver up to 25 percent higher performance, up to 2x higher floating-point performance, and 50 percent faster memory access based on leading-edge DDR5 memory technology compared with Graviton2 processors.
在「FreeBSD on the Graviton 3」這邊也可以看到一些效能數據 (雖然是跑在 FreeBSD 上)，可以看到基本上符合 AWS 的宣稱。
目前只有 us-east-1 與 us-west-2 有這個機種，不過 Graviton 系列一直都是 AWS 的強主打項目，其他區域應該很快就會看到：
C7g instances are initially available in US East (N. Virginia) and US West (Oregon) AWS Regions; other Regions will be added shortly after launch.
價位上比 c6g 貴了一些，在 us-east-1 上 c7g.16xlarge (64 vCPU + 128 GB RAM) 是 US$2.32/hour，而 c6g.16xlarge 是 US$2.176/hour，大約貴了 6.6%，但如果是 CPU bounded 的應用來說，應該還是蠻划算的。
另外一方面是等後續的 m7g 與 r7g 系列出現...
前幾天提過「Raspberry Pi OS 64-bit 版本正式推出」，而 Phoronix 實際拿正式版測試 64-bit 與 32-bit 的系統差異了，在「Raspberry Pi OS 32-bit vs. 64-bit Performance」這邊可以看到每一個測試項目的結果。
測試的硬體是 Raspberry Pi 400，這台機器基本上就是 4GB 版本的 Raspberry Pi 4 加上週邊配件：
Using a Raspberry Pi 400 keyboard computer with 4GB of RAM, I ran some fresh benchmarks of Raspberry Pi OS in its default 32-bit build and then again with the new 64-bit build.
先講結果，在 Phoronix 的 33 個測試裡面，64-bit 全部都比 32-bit 好，而且是很明顯的差異：
Across the few dozen different workloads tested, switching Raspberry Pi OS 11 for the 64-bit version improved the performance on average by about 48%. See all the 32-bit vs. 64-bit Raspberry Pi benchmarks over on OpenBenchmarking.org.
之前 64-bit OS 還在 beta 的時候就已經知道這個情況了，所以不會覺得太意外。當時提出的解釋是指令集的差異，aarch64 提供的指令集比 armv6 有效率多了，這點在 2016 年的文章「64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions」這邊可以看到說明。
所以正式版出來以後，只要硬體有支援，基本上都建議裝 64-bit OS 了...
AWS 打算要推出 Graviton3 的機種了，目前還在 preview 階段：「Join the Preview – Amazon EC2 C7g Instances Powered by New AWS Graviton3 Processors」。
目前是宣稱與前一代的 Graviton2 相比有 25% 的效能提昇，另外在浮點數與密碼相關的運算上面也會有改善 (這個效能提昇的數字應該是有指令集的幫助)：
In comparison to the Graviton2, the Graviton3 will deliver up to 25% more compute performance and up to twice as much floating point & cryptographic performance. On the machine learning side, Graviton3 includes support for
bfloat16data and will be able to deliver up to 3x better performance.
另外提到了 signed pointer，可以避免 stack 被搞，不過這邊需要 OS 與 compiler 的支援，算是針對 stack 類的攻擊提出的防禦方案：
Graviton3 processors also include a new pointer authentication feature that is designed to improve security. Before return addresses are pushed on to the stack, they are first signed with a secret key and additional context information, including the current value of the stack pointer. When the signed addresses are popped off the stack, they are validated before being used. An exception is raised if the address is not valid, thereby blocking attacks that work by overwriting the stack contents with the address of harmful code. We are working with operating system and compiler developers to add additional support for this feature, so please get in touch if this is of interest to you.
然後是使用 DDR5 的記憶體：
C7g instances will be available in multiple sizes (including bare metal), and are the first in the cloud industry to be equipped with DDR5 memory. In addition to drawing less power, this memory delivers 50% higher bandwidth than the DDR4 memory used in the current generation of EC2 instances.
現在還沒看到價錢，不過有可能是跟 c6g 一樣的價位？但考慮到記憶體換架構，也有可能是貴一些的？
另外翻了一下資料，ARM 有發表過新聞稿提到 Graviton2 是 ARM 的 Cortex-M55 機種：「Designing Arm Cortex-M55 CPU on Arm Neoverse powered AWS Graviton2 Processors」，這次的 Graviton3 應該在之後完整公開後會有更多消息出來...
在 Hacker News 首頁上看到 Netflix 在 EuroBSDCon 2021 上發表的投影片：「Serving Netflix Video at 400Gb/s on FreeBSD」，對應的討論則是在「Serving Netflix Video at 400Gb/s [pdf] (freebsd.org)」這邊可以翻到，投影片的作者有在上面回答一些問題。
投影片在講的應該就是 Netflix 的 Open Connect。
主要是因為 Open Connect 的伺服器是放到各家 ISP 機房，在單一 IP 且單一伺服器的限制下，要想辦法壓榨出最高的效能。
硬體是 AMD 的 EPYC，在先前的版本可以達到 240Gbps，經過分析與嘗試解決了一堆問題後，最後是在原來的 AMD 機器上跑到了 380Gbps (另外有測 ARM 以及 Intel 的數字)，然後之後機房有可能會有 800Gbps 的標準，他們又要繼續煩惱...
有看到 Mellanox ConnectX-6 Dx (CX6-DX) 這個東西，看起來很有趣啊，有 200Gbps 的能力，而且可以把 TLS 的事情推到卡上面處理... 然後這家公司被 Nvidia 買走了。
另外當然也會有人問為什麼不用 Linux，作者在討論串裡面也有回答一些，有興趣的可以自己去搜一下。
這兩篇剛好一起看，Amazon RDS 支援了 ARM 架構的 t4g 與 x2g：「Amazon RDS now supports X2g instances for MySQL, MariaDB, and PostgreSQL databases.」與「Amazon RDS now supports T4g instances for MySQL, MariaDB, and PostgreSQL databases.」。
目前主要是關注 t4g，因為目前量的關係反而是大量使用 t4g 類的機器，如果上面的 PostgreSQL 可以跑 t4g 的話，看起來只要沒有買 RI 的可以換過去，主要是比 t3 再省一些錢：以新加坡區的 PostgreSQL 來說，db.t4g.micro 目前是 $0.025/hr，而 db.t3.micro 則是 $0.028/hr，差不多是九折。
沒意外的話效能應該也會提昇一些，不過用 t 系列的機器本來就沒有太大的量在上面跑，這點應該是還好...
在 Twitter 上看到 Laravel News 轉發了「Mistakes I've Made in AWS」這篇，講 Amazon EC2 上面的一些小常識。
在 EC2 中，T 系列的機器 (目前主要是 t2/t3/t3a/t4g) 對於開發很好用，甚至對於量還不大的 production system 也很好用，加上 Unlimited 模式可以讓你在 CPU credit 用完時付錢繼續 burst。
文章裡面有討論到，使用 T 系列機器時，常常是不怎麼需要大量 CPU 資源的情境，這時候 AMD-based 的 t3a 通常都是個還不錯的選擇，大概會比 Intel-based 的 t3 省 10% 的費用。另外如果可以接受 ARM-based 的話，t4g 也是個選項，價錢會更便宜而且在很多應用下速度會更快。不過同事有遇到 Python 上面跑起來的行為跟 x86-64-based 的不同，這點就得自己琢磨了...
另外就是目前的 EBS 預設還是會使用 gp2，而在 gp3 出來後其實大多數的情況下應該可以換過去，主要就是便宜了 20%，加上固定的 3000 IOPS。
不過也是有些情境下是不應該換的，主要是 gp2 可以 burst 到 250MB/sec，但 gp3 只給了 125MB/sec。雖然 gp3 可以加價買 throughput，但加價的費用不低，這種需求改用 gp2 應該會比較划算。
不過這邊推薦比較技術的作法，可以掛兩個 gp3 (也可以更多) 跑 RAID0 (像是在 Linux 上可以透過 mdadm 操作)，這樣 IOPS 與 throughput 都應該可以拉上來...
這篇的後續可以參考「Amazon EC2 的網路效能」這篇。
最近在在調整跑在 Amazon EC2 上 OpenVPN server 的效能，要想辦法把 network throughput 拉高，當作在導入 WireGuard 之前的 workaround，但看起來還是頗有用，記錄一下可以調整的部份...
在還沒灌大量流量前是用 t3a.nano (開 Unlimited mode)，然後會觀察到的瓶頸是 OpenVPN 的 daemon 吃了 100% CPU loading，最高速度卡在 42MB/sec 左右。
第一個想到的是看看 OpenVPN server 有沒有可以使用多 CPU 的方式，但查了資料發現 OpenVPN server 無法使用 threading 或是 fork 之類的方法善用多顆 CPU，所以就開始想其他方法...
接著看到我們目前用的是 AES-256-CBC 了，網路上很多文章都有提到 AES-128-CBC 會快一些，但我們的 OpenVPN client 已經是設死都用 AES-256-CBC 了，這個就沒辦法了...
而第一個可行的解法是把 AMD-based 的 t3a.nano 換成 ARM-based 的 t4g.nano，還是 100% 的 CPU loading，但直接多了 50%+ 的效能，到了 69MB/sec。
第二個解法是找資料時發現的 fast-io 參數，加上去以後可以再快一些，到 77MB/sec。
有了這兩個 workaround 應該就堪用了，接下來是發現在傳大量資料跑一陣子後速度會掉下來，於是開了兩台 t4g.nano 用 iperf 對測了一下，發現會逐步掉速：
看起來 network bandwidth credit 是分階段的，但 30Mbps 真的有點低...
在換成四倍大的 t4g.small 測試後發現也只能到 40MB/sec 左右 (比較疑惑的是，居然不是四倍？)，目前上了 c6g.medium，但看起來網路的部份也還是有瓶頸，在 46MB/sec 左右，要再想一下下一步要怎麼調整...
但以目前看到的情況總結，如果能用 ARM 架構就儘量用，效率與價錢真的是好 x86-64 不少...