AWS 推出 32TB RAM 的機種 u7in-32tb.224xlarge

最近是 AWS re:Invent 2023,會有蠻多消息陸陸續續冒出來。

剛剛看到「Introducing Amazon EC2 high memory U7i Instances for large in-memory databases (preview)」這個,AWS 推出了 u7in-32tb.224xlarge,896 vCPU + 32TB RAM 的機器。

先前最大的應該是 u-24tb1.112xlarge,448 vCPU + 24TB RAM 的機器 (包括 vCPU 數量與記憶體大小),所以這次 vCPU 數量多一倍,記憶體多 50%。

很理所當然的又拿 SAP 來介紹了:

The new U7i instances are designed to support large, in-memory databases including SAP HANA, Oracle, and SQL Server.

比較特別的是 us-east-1 沒有在第一波的名單,反而是 us-west-2 以及其他的區域,不確定當初怎麼決定的:

Powered by custom fourth generation Intel Xeon Scalable Processors (Sapphire Rapids), the instances are now available in multiple AWS regions in preview form, in the US West (Oregon), Asia Pacific (Seoul), and Europe (Frankfurt) AWS Regions, as follows[.]

因為是 preview 階段,可能是這些區域有大客戶有需求,所以先佈到這幾區?

Sentry 的替代品:GlitchTip

GlitchTipSentry 的替代品,你仍然可以用 Sentry SDK 發送錯誤訊息,但接收端則是換成 GlitchTip。

Sentry 本身已經是 open source software 了 (可以在 getsentry/self-hosted 這邊裝) (參考「Sentry 的 License 不是 Open Source License...」),但最近的版本愈來愈肥,8GB RAM + 512MB Swap 的機器,光跑起來就蠻吃緊的。

對於在 AWS 的人來說,這等於被迫要用 16GB RAM 的機器跑 Sentry,像是 r6a.large (在 us-east-1 為 $0.1134/hr,約 $81.6/mo),如果是一年 RI 的話可以六折,三年 RI 可以四折,是有點費用,但這個費用對於公司用戶來說通常沒有太大問題。

GCP 的話也類似,但可以開 10GB RAM 來用,真的有用到的時候再逐步拉高記憶體空間,不過成本結構跟 AWS 是差不多的,所以對於公司也不是太大問題。

但對個人來說,光一個 Sentry 一個月就得花個 $80/mo 實在是太貴,而且考慮到這兩年的 Sentry 愈來愈沒有在管記憶體用量了:從之前 4GB RAM 能跑,到現在 8GB RAM 光開機就沒有 free memory,可以想像之後應該會愈來愈肥,所以試著找了替代方案。

目前看到的替代方案是 GlitchTip,在 server 端吃同樣的 input,所以 client 端可以維持原來的 sentry sdk,可以用雲端服務,也可以自己架設:「GlitchTip Installation Guide」。

跑起來後大約吃 500MB RAM,基本的功能都有,包括基本的 event group & call stack information,以及常用的 integration (像是 E-mail 通知與 Slack 通知),但畫面上沒有 Sentry 那麼好看,不過還算是乾淨。

有些功能要找文件 trial and error,跟 Sentry 文件相比起來完整度差一點,但還行...。

目前看起來自己用可以用這個,Sentry 真的太胖了...

Alpaca.cpp 有 13B 與 30B 的 model 可以玩了

在「Stanford Alpaca 與 Alpaca.cpp」這邊有提到 Alpaca 有放出 7B 的 model 可以用,後來 community 也照著同樣的方式訓練出對應的 13B 與 30B 的 model 了,在 Alpaca.cpp 專案的 README.md 有寫怎麼取得。

看起來比較大的限制是記憶體,13B 與 30B 的記憶體建議是 >10GB RAM 與 >32GB RAM,不知道剛好 32GB RAM 跑不跑得動,先拿 32GB RAM 的機器跑看看,如果真的不行的話家裡桌機是 64GB RAM,應該是不會有大問題...

不過 13B 的 model 檔案位置是放在 IPFS 上,透過這幾個 gateway 下載起來都有點慢,有需要的人用 BitTorrent 可能會快一點?

Update:測了一下 13B 的版本:

> Explain FAANG.
FAANG refers to five of America's largest technology companies - Facebook, Apple Inc., Amazon, Netflix and Google (Alphabet). These are some of the most valuable brands in today’s marketplace with a combined value that exceeded $3 trillion as at 2018.

以及 30B 的版本:

> Explain FAANG.
FAANG stands for Facebook, Amazon, Apple, Netflix and Google - five of the most powerful technology companies in today's world. These tech giants have become increasingly influential over recent years due to their dominance in various markets such as social media platforms (Facebook), e-commerce websites (Amazon) or streaming services (Netflix).

Windows 11 瘦身版本的 Tiny11

Tiny11NTDEV 弄出來的精簡版 Windows 11:「De-Bloated Windows 11 Build Runs on 2GB of RAM」。HN 上對應的討論在「De-Bloated Windows 11 Build Runs on 2GB of RAM (tomshardware.com)」。

It just uses around 8GB of space compared to the 20+GB that a standard installation does.

但有些限制,像是安全性更新需要自己來:

This OS install “is not serviceable,” notes NTDev. “.NET, drivers and security definition updates can still be installed from Windows Update,” so this isn’t an install which you can set and forget.

另外像是透過 WinSxS 安裝的功能 (包括語言) 會無法安裝:

Moreover, removing the Windows Component Store (WinSxS), which is responsible for a fair degree of Tiny11’s compactness, means that installing new features or languages isn’t possible.

但我記得拔掉 WinSxS 應該會影響蠻多東西的?這樣的系統應該是拿來跑跑 CI 或是固定用途還行,一般性的用途不知道會卡多少東西...

另外除了使用的磁碟空間變小以外,記憶體的使用量也大幅下降,畢竟也拔掉了一堆肥大的軟體:

In testing, NTDev said that Tiny11 could “run great” on a system with just 2GB of RAM.

AWS 東京區有 12TB 記憶體的機器了

月初 AWS 宣佈東京區有 u-12tb1.112xlarge 可以用了:「Amazon EC2 High Memory instances with 3, 6, 9, and 12TiB of memory are now available in Asia Pacific (Tokyo) region」。查了一下 on-demend 的價錢是 $131.733/hr,如果一個月以 720 小時來算,要 $94847.76/mo...

沒記錯的話,這種機器應該是要另外申請 limit 才能開,沒辦法說測就測。另外在公告裡面有提到 savings plan ,但沒提到 RI (reserved instance),不確定是不是還沒開 RI 讓使用者買 (不過我記得 savings plan 好像也有類似的折扣結構):

Starting today, Amazon EC2 High Memory instances with 3TiB (u-3tb1.56xlarge), 6TiB (u-6tb1.56xlarge, u-6tb1.112xlarge), 9TiB (u-9tb1.112xlarge), and 12TiB of memory (u-12tb1.112xlarge) are available in Asia Pacific (Tokyo) region. Customers can start using these new High Memory instances with On Demand and Savings Plan purchase options.

這種機器是用暴力解決問題的機器...

Ribbon filter

RocksDB 的 blog 上看到「Ribbon Filter」這個,主要是 RocksDB 從 6.15 開始支援 Ribbon filter,取代本來的 Bloom filter 機制。

RocksDB 的 wiki 上面是說用 CPU 資源換 memory 的使用量:

A new Bloom filter alternative is available as a drop-in replacement (since version 6.15.0), saving about 30% of Bloom filter space (most importantly, memory) but using about 3-4x as much CPU on filters. Most of the additional CPU time is in the background jobs constructing the filters, and this is usually a good trade because it is common for SST filters to use ~10% of system RAM and well under 1% of CPU.

論文則是在「Ribbon filter: practically smaller than Bloom and Xor」這邊可以看到,Facebook 之前也有提到 Ribbon filter:「Ribbon filter: Practically smaller than Bloom and Xor」,在 Hacker News 上有對應的討論可以翻:「Ribbon filter: Practically smaller than Bloom and Xor (fb.com)」。

在 Ribbon filter 的資料裡面都提到了 Xor filter 當作比較,先前在「比 Bloom filter 與 Cuckoo filter 再更進一步的 Xor filter」這邊有提到 Xor filter。

用 CPU 去換記憶體,算是特化的版本...

EC2 的大記憶體機器又推新規格了...

這次 Amazon EC2 的機器又推出一些新規格了:「Amazon EC2 High Memory Instances now available for on-demand usage」。

然後每次推這些機器的時候都會提到 SAP HANA,都沒有其他的例子可以說... 話說業界就只剩下這套系統是完全都沒在考慮分散式架構嗎 XDDD (完全沒用過)

SAP customers continue to leverage AWS as their platform of choice and innovation. Some are in the early stages of their SAP cloud journeys and are focused on executing their migration. Others have hardened their SAP systems on AWS and are innovating around their core business processes with advanced AWS services.

另外他有提到 24TB 的機器,在 Amazon EC2 Instance Types 這邊可以翻到 u-24tb1.metal

In 2018, we released High Memory Instances in response, which now offer up to 24TB of memory in a single instance.

不過你會發現在 Amazon EC2 On-Demand Pricing 這邊翻不到 24TB 的價錢,先前在「EC2 推出 18TB 與 24TB 的機器...」這邊有過這些機器買三年 RI 才能用,所以這次推出來 12TB 的機器算是隨時租用的機器裡面記憶體最多的了...

u-12tb1.112xlargeus-east-1 的價錢是 USD$109.2/hour,想要玩的人可以測試看看,至少應該玩的動 XD

AWS 推出 X2gd 機種,針對記憶體再提供更便宜的方案

AWS 推出了 X2gd 機種,用 ARM 的 CPU,然後給更少顆,disk 也更小,但換來的就是價錢更低:「New Amazon EC2 X2gd Instances – Graviton2 Power for Memory-Intensive Workloads」。

把兩個用 ARM 的主機拿出來看看 us-east-1 的價錢,第一個是這次的 x2gd.medium,只有 1 vCPU + 59 GB SSD,但有 16 GB RAM,現在的價錢是 $0.0835/hr。

另外一個 r6g.large 則是 2 vCPU + 16 GB RAM,然後 EBS only,則是 $0.1008/hr。

再來是 Intelx1e.xlarge,這邊是 4 vCPU + 12 GB RAM + 120 GB SSD,單價也差不多,不過記憶體少了點,$0.834/hr。

另外 Intel 也有 r5.large,2 vCPU + 16 GB RAM + EBS only,$0.126/hr。

最後一個是 AMDr5a.large,跟 Intel 的 r5.large 也很像,2 vCPU + 16 GB RAM + EBS only,$0.113/hr。

這次推出的 X2gd 機種提供了只要記憶體的極端選擇,而且依照先前的經驗,Graviton2 真的很快,1 vCPU 未必會不夠用... 至少我 blog 的 PHPMariaDB 都是跑在 t4g 上面,看起來比之前放在 VPS 上快不少 :o

把 blog 從 t4g.small 降到 t4g.micro

我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2t4g.small 上 (2GB RAM + 20% CPU credit),跑了一陣子把 CPU usage 拉出來看:

當初估大約要 20% 的 CPU credit,結果發現 CPU credit 大概用 5% 就夠了。另外記憶體的部份大約要給 1GB,這個量可以看出來一些沒在用的 process 會被丟到 swap:

              total        used        free      shared  buff/cache   available
Mem:          952Mi       380Mi        79Mi       110Mi       492Mi       368Mi
Swap:         511Mi       152Mi       359Mi

把條件綜合起來計算,就往下降一階變成 t4g.micro 了 (1GB RAM + 10% CPU credit)。

另外新機種比較不用擔心淘汰速度,就看了一下 Reserved Instances 的價錢,一年 USD$44,三年 USD$84,看起來只要有用兩年就算是 OK,直接買三年解決掉...

Percona 對 MongoDB 的建議

看到「5 Things DBAs Should Know Before Deploying MongoDB」這篇,裡面給了五個建議,其中第五點頗有趣:

5) Whenever Possible, Working Set < RAM

As with any database, fitting your data into RAM will allow for faster reads than from disk. MongoDB is no different. Knowing how much data MongoDB has to read in for your queries can help you determine how much RAM you should allocate to your database.

這樣的設計邏輯很奇怪啊,你不要扯其他 database 啊,你們家主力的 InnoDB 一直都沒有推薦要 Working Set < RAM 啊,反過來才是用 InnoDB 的常態吧,而且在 PostgreSQL 上也是這樣吧 XDDD

現在上面的文章真的是挑著看了... XD