Tag: memory

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。

再來是 Intel 的 x1e.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。

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

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

把 blog 從 t4g.small 降到 t4g.micro

我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2 的 t4g.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 模擬問題，所以在記憶體架構上直接實做了對應的模式，大幅降低了當年 Microsoft 在 Surface 上遇到的問題：

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.

不過上面的 Chromium 與 Firefox 不完整支援硬體解壓影片的部份還是痛，四代的 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

前幾天在公司弄 GitLab 與 GitLab 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 EC2 的 Auto 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

EC2 推出 18TB 與 24TB 的機器...

AWS 又把機器給生出來啦：「EC2 High Memory Update – New 18 TB and 24 TB Instances」。

一樣是限制要買三年 RI 才能用，不過價錢頁面上好像還在更新，在「Amazon EC2 Dedicated Hosts Pricing」只看到了之前就公佈的 12TB 價錢，還沒看到 18TB 與 24TB 的部份...

然後以前會跟同事說，資料小於這台機器記憶體大小的不能叫 big data (當時是 12TB)，現在升級到 24TB 啦...