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,直接買三年解決掉...

AT&T 網路的問題

Hacker News Daily 上看到個有趣的 troubleshooting 過程,AT&T 的線路會造成 random bit flipping 的問題,另外在 Hacker News 上的討論野蠻熱鬧的:「AT&T Fiber in the SF Bay Area is flipping bits (twitter.com/catfish_man)」。

有人生了一個 script 出來測試,這隻 script 會抓 www.example.com 的 HTTP 與 HTTPS 結果比較,從下面大家的留言回報,可以看出來有 random bit flipping 的問題:「bmastenbrook/example-test.sh」。

然後總算是解決了:

可惜看不到 AT&T 的回應,大家只能猜測是 memory 相關的問題,也許壞的部份有多個地方,造成 ECC 機制在某些情況下不夠用...

Apple M1 的效能與省電原因

Hacker News Daily 上看到 Apple M1 為什麼這麼快又省電的解釋,可以當作一種看法:

可以在 Thread reader 上面讀:「Thread by @ErrataRob on Thread Reader App – Thread Reader App」。

看起來 Apple 在規劃的時候就有考慮 x86 模擬問題,所以在記憶體架構上直接實做了對應的模式,大幅降低了當年 MicrosoftSurface 上遇到的問題:

3/ The biggest hurdle was "memory-ordering", the order in which two CPUs see modifications in memory by each other. It's the biggest problem affecting Microsoft's emulation of x86 on their Arm-based "Surface" laptops.

4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering.

另外一個比較有趣的架構是,Apple M1 上面的兩個 core 有不同的架構,一顆對效能最佳化,另外一顆對效率最佳化:

13/ Apple's strategy is to use two processors: one designed to run fast above 3 GHz, and the other to run slow below 2 GHz. Apple calls this their "performance" and "efficiency" processors. Each optimized to be their best at their goal.

在 wikipedia 上的介紹也有提到這兩個 core 的不同,像是 L1 cache 的差異 (128KB 與 192KB),以及功耗的差異:

The M1 has four high-performance "Firestorm" and four energy-efficient "Icestorm" cores, providing a configuration similar to ARM big.LITTLE and Intel's Lakefield processors. This combination allows power-use optimizations not possible with Apple–Intel architecture devices. Apple claims the energy-efficient cores use one tenth the power of the high-performance ones. The high-performance cores have 192 KB of instruction cache and 128 KB of data cache and share a 12 MB L2 cache; the energy-efficient cores have a 128 KB instruction cache, 64 KB data cache, and a shared 4 MB L2 cache. The Icestorm "E cluster" has a frequency of 0.6–2.064 GHz and a maximum power consumption of 1.3 W. The Firestorm "P cluster" has a frequency of 0.6–3.204 GHz and a maximum power consumption of 13.8 W.

再加上其他架構上的改善 (像是針對 JavaScript 的指令集、L1 的提昇,以及用 TSMC 最新製程),累積起來就變成把 Intel 版本壓在地上磨蹭的結果了...

最近討論到的二分搜尋法...

應該是直接在 Hacker News 上看到的東西,有人丟出一個二分搜尋法實做,宣稱比標準實做快不少:「Binary Search: A new implementation that is up to 25% faster (github.com)」。

實做的程式碼放在 GitHub 的「scandum/binary_search」這邊,讀了 source code 後可以看到一臉就要利用現代 CPU 預測平行化的能力加速 XDDD

另外看了 Hacker News 上的討論,這種寫法會透過 CPU 預測平行化的能力善用記憶體頻寬,這應該是測起來比較快的主因。

不過這只算是個開頭,丟出一些方向讓社群可以研究,實際上還是得看看負面影響的部份,像是比較舊的 CPU 會不會有很重的 penalty (overhead),以及其他類型 CPU 上的情況...

Raspberry Pi 4 推出 8GB 版本

Raspberry Pi 宣佈了 8GB 版本:「8GB Raspberry Pi 4 on sale now at $75」。

除了記憶體變成 8GB 以外,也因為記憶體加大而需要更多電力,所以電供元件的部份也跟著改動,然後也提到 COVID-19 造成的延遲:

To supply the slightly higher peak currents required by the new memory package, James has shuffled the power supply components on the board, removing a switch-mode power supply from the right-hand side of the board next to the USB 2.0 sockets and adding a new switcher next to the USB-C power connnector. While this was a necessary change, it ended up costing us a three-month slip, as COVID-19 disrupted the supply of inductors from the Far East.

超過 4GB 的時候一定會檢視 32-bit 與 64-bit 環境的差異,所以就會發現,在預設的 kernel 因為使用 32-bit LPAE (ARM 上的 PAE),所以雖然是有機會可以使用到 8GB,但單一程式會有 3GB 限制:

Our default operating system image uses a 32-bit LPAE kernel and a 32-bit userland. This allows multiple processes to share all 8GB of memory, subject to the restriction that no single process can use more than 3GB.

目前如果想要原生支援 64-bit 環境的話,需要使用其他作業系統:

But power users, who want to be able to map all 8GB into the address space of a single process, need a 64-bit userland. There are plenty of options already out there, including Ubuntu and Gentoo.

不過另外官方也在測自家的 64-bit 版本,已經有 early beta 版本可以測試看看了 (話說 early beta 這個詞,可以解釋成 alpha 的品質...):

Not to be left out, today we’ve released an early beta of our own 64-bit operating system image. This contains the same set of applications and the same desktop environment that you’ll find in our regular 32-bit image, but built against the Debian arm64 port.

不過上面的 ChromiumFirefox 不完整支援硬體解壓影片的部份還是痛,四代的 CPU 在 YouTube 上是可以硬撐 1080p30 解碼,但畫面順暢度就不太行了,客廳還是用老 Mac Mini (2011 的版本) 來撐場...

Cloudflare 的另外一個策略:不熱門的資料只放到記憶體內

前陣子的文章,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 都還沒上...

OpenVZ 裡的 Docker

前幾天在公司弄 GitLabGitLab CI,前者光跑起來都還沒動他就先吃 1.5GB 左右的記憶體,動兩下就 2.5GB 了。後者的 CI 隨著使用的情況而改變,不過最少丟個 1GB 差不多...

公司用的機器當然是還好,先簡單弄一台 t3a.medium (4GB) 跑 GitLab 主體,然後另外一台 t3a.small (2GB) 跑 CI 的 Runner,真的有需要的時候可以再往上拉...

不過自己也要弄的時候就會考慮到成本問題,畢竟也只有自己一個人用,如果在 Vultr 上面租類似的機器就要 USD$30/month,其他的 KVM VPS 也都差不多價錢。

OpenVZ 的 VPS 主機一向都比 KVM 的 VPS 便宜不少,但有不少限制。其中一個限制就是沒辦法跑 Docker,這樣就沒辦法把 GitLab CI 的 Runner 跑上去了 (有其他模式可以跑,但我這邊偏好用 Docker)。

查了一下資料 (因為記得 OpenVZ 有計畫要支援 Docker),發現 OpenVZ 7 已經支援 Docker 了,而且在官方文件上面也都已經有說明了:「10.3. Setting Up Docker in Virtuozzo Containers」、「Docker inside CT vz7」。

然後順著找一下,發現市場上也已經有 OpenVZ 7 的 VPS,而且會宣傳支援 Docker,試著租一個月也確認可以跑,這樣代表之後又有更多選項啦...

EC2 的 Auto Scaling 增加了兩個功能

Amazon EC2Auto Scaling 增加了兩個功能,一個是 instance 可以有權重了:「Amazon EC2 Auto Scaling Now Supports Instance Weighting」,另外一個是可以設定 instance 活多久就要換一台:「Amazon EC2 Auto Scaling Now Supports Maximum Instance Lifetime」。

前面的 instance weighting 這個功能對於會混多種不同 family type 的情境會好用不少 (像是同時混用 {c3,c4,c5}.xlarge),可以讓設定上細緻一些,不然就只能以效能最低的那個類型規劃...

後面的 maximum instance lifetime 這個功能看起來可以拿來解各種 resource leak 的情境,而且現在 EC2 instance 是以秒計費,所以不用太擔心成本浪費太多的問題... 這樣不管是 memory leak 還是 /tmp 下暫存檔懶的清的問題,都可以很順利的逃避現實 XDDD