Tag: t3a

Amazon EC2 上的一些小常識

在 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 都應該可以拉上來...

在 AWS 上面的 OpenVPN Server 效能

這篇的後續可以參考「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 對測了一下，發現會逐步掉速：

  • 前 15 秒可以直接到 5Gbps，就是 AWS 網頁上宣稱的最高速度，接下來降到 800Mbps 左右。
  • 到 180 秒左右後降到 300Mbps。
  • 到 210 秒左右後回到 800Mbps。
  • 到 300 秒左右後降到 500Mbps。
  • 到 300 秒左右後降到 300Mbps。
  • 到 1260 秒左右後降到 30Mbps，後面就一直維持這個速度了。

看起來 network bandwidth credit 是分階段的，但 30Mbps 真的有點低...

在換成四倍大的 t4g.small 測試後發現也只能到 40MB/sec 左右 (比較疑惑的是，居然不是四倍？)，目前上了 c6g.medium，但看起來網路的部份也還是有瓶頸，在 46MB/sec 左右，要再想一下下一步要怎麼調整...

但以目前看到的情況總結，如果能用 ARM 架構就儘量用，效率與價錢真的是好 x86-64 不少...

Amazon EC2 的 t3/t3a/t4g 的 CPU credit 保留七天的限制

Twitter 上看到朋友提到 t3 系列的機器有保留七天的 CPU credit：

在「CPU credits and baseline utilization for burstable performance instances」這邊有提到，t3/t3a/t4g 的設計都是讓你可以塞 24h 小時的量：

這邊講的七天是這段：

CPU credits on a running instance do not expire.

For T2, the CPU credit balance does not persist between instance stops and starts. If you stop a T2 instance, the instance loses all its accrued credits.

For T3 and T4g, the CPU credit balance persists for seven days after an instance stops and the credits are lost thereafter. If you start the instance within seven days, no credits are lost.

開著的機器的 CPU credit 不會過期，只會到最大上限 (在同一篇文件裡面的表格有提到)，t2 的機器關掉後 (stop) CPU credit 就會直接消失，而 t3/t3a/t4g 則在關掉後會保留七天。

之前沒注意到文件上的這點。

另外之前在測試自己架設 Sentry 時還測過 t3a.medium -> r5a.large -> t3a.medium 這樣換過去又換回來的情況，本來的 CPU credit 是可以繼續用的，看起來 CPU credit 不會因為 family type 改變就不見 (不過不確定這個是不是 undefined behavior...)。

AWS 推出使用 AMD CPU 的 t3a.*

AWS 推出了 t3a.* 的 EC2 instance：「Now Available – AMD EPYC-Powered Amazon EC2 T3a Instances」。

目前開放的區域有限，但算是個開始：

You can launch T3a instances today in seven sizes in the US East (N. Virginia), US West (Oregon), Europe (Ireland), US East (Ohio), and Asia Pacific (Singapore) Regions in On-Demand, Spot, and Reserved Instance form.

價錢大約再低個 10% 左右：

Pricing is 10% lower than the equivalent existing T3 instances; see the On-Demand, Spot, and Reserved Instance pricing pages for more info.

有些超小的機器可以考慮重開的時候就順便換過去...