把 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

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 啦...

Slack 改善桌面應用程式的效能與記憶體用量

Slack 桌面版改版的消息,在「Slack’s new desktop app loads 33 percent faster and uses less RAM」與「Slack speeds up its web and desktop client」這邊都有提到這兩個數字,不過看了官方的「When a rewrite isn’t: rebuilding Slack on the desktop」這篇,好像沒提到這兩個數字... 但看引用的圖片似乎是官方的評估數字,不知道是從哪邊得到的。

這是一個堅持繼續使用 Electron 的前提下改善效能的過程。如果過個幾年他們決定寫 native application 也不意外就是了,要一直壓榨效能,最後大概都會走到這邊... 當然也有可能靠 Google 一直改善 V8 engine 的效能撐很久 (畢竟 Google 是真狂砸人改善),現在大家都在賭可以改善多少 XD

這一波最主要的記憶體用量改善是來自於現在使用的 workspace 當然要有完整資料,而其他 workspace 的頁面就只保留狀態 (透過 Redux):

從記憶體用量可以看出來:

也可以理解因為這樣就不需要在啟動時馬上處理所有 workspace 的資料,所以啟動時間也就下降了不少,但這邊的 trade-off 是切換時的速度就會變慢 (需要重新 render),不過大概是考慮到常見情境下的切換次數而決定這樣做,應該還算 ok...