Java 21 (LTS) 推出

Hacker News 上注意到 Java 21 的消息:「JDK 21 Release Notes」、「Java 21 / JDK 21: General Availability」、「OpenJDK JDK 21 General-Availability Release」。

對於沒什麼在寫 Java 的人來說 (也是等於比較沒有在接觸 Java 圈子消息的人),比較意外的是這是推出的是 LTS 版本,距離上次的 LTS (Java 17) 才兩年前 (2021/09/14):

JDK 21 will be a long-term-support (LTS) release from most vendors, including Oracle. If you’re upgrading from the previous LTS release, JDK 17, then you have many more JEPs to look forward to, summarized here:

翻了一下 Java version history,可以知道同時支援的 LTS 版本變成四個了,而最近一次會終止的會是 Java 11,Red Hat 會在 2024/10 終止,而 Oracle 會在 2026/09 終止,這中間還會不會再增加 LTS...?

雖然沒什麼在寫,但還是常常會看到有人提到這次引入了 Virtual ThreadsGenerational ZGC,這應該是討論度最高的。

看了 Virtual Threads 的說明,有種「反璞歸真」的感覺...

在二十年前的時候,就已經有很多 userland threading library,讓應用程式可以用 threading design pattern 開發程式,而當時 x86 下的作業系統開始要遇到多 CPU 的環境,才開始在 kernel 裡支援 threading,讓應用程式裡面的 threading 可以打散到多個不同的 CPU 上面。

記得當年 FreeBSD 4 之後對 SMP 與 threading 的爭論導致分家出 DragonflyBSD,而 FreeBSD 的多 CPU 效能與穩定性要一直到 FreeBSD 7 才穩了下來。

現在 Java 反過來為了降低 OS thread 造成的 overhead,讓 java.lang.Thread 可以跑在 userland 裡面,不要用 kernel 提供的 OS thread...

另外又讓我想到 kqueueepoll 以及 libevent 的事情了,不過這扯遠了...

KeyDB:使用 Multithreading 改善 Redis 的效能

Hacker News 上看到有支援 Multithreading 的 Redis fork:「KeyDB – A Multithreaded Fork of Redis (」,官網在「KeyDB - The Faster Redis Alternative」這邊。

不過這篇是要記錄從 Hacker News 看到的雷點,這樣以後自己再找資料的時候會比較容找到。

36022425 這篇是跳下去用發現不太行,最後在 application 端實作需要的 feature,後端還是用原廠的 Redis:

To counter what the other active business said, we tried using KeyDB for about 6 months and every fear you concern you stated came true. Numerous outages, obscure bugs, etc. Its not that the devs aren’t good, its just a complex problem and they went wide with a variety of enhancements. We changed client architecture to work better with tradition Redis. Combined with with recent Redis updates, its rock solid and back to being an after-thought rather than a pain point. Its only worth the high price if it solves problems without creating worse ones. I wish those guys luck but I wont try it again anytime soon.

* its been around 2 years since our last use as a paying customer. YMMV.

另外是在專案裡搜尋「is:open is:issue label:"Priority 1"」的結果可以看到不太妙,在 36021108 這邊有提到的問題:

Filed July, eventually marked priority 1 in early December, not a single comment or signs of fix on it since. That doesn't look good at all.

然後 36020184 有提到 Snap 買進去後沒有什麼在管 open source project 的部分了:

I think I'll stay far away from this thing anyway. Numerous show-stopper bug reports open and there hasn't been a substantial commit on the main branch in at least a few weeks, and possibly months. I'll be surprised if Snap is actually paying anybody to work on this.

Python 的原生 multithreading 支援

Simon Willison 這邊看到的:「Real Multithreading is Coming to Python - Learn How You Can Use It Now」,他引用的原文在「Real Multithreading is Coming to Python - Learn How You Can Use It Now」這邊,在講 Python 3.12 將會有原生 multithreading 支援。

Python 裡知名的 GIL 問題將會用 Per-Interpreter GIL 的技術來解決,把 GIL 的 global-based 改寫變成 thread-based:

With introduction of "Per-Interpreter GIL", individual Python interpreters don't share the same GIL anymore. This level of isolation allows each of these sub-interpreters to run really concurrently.

這算是基礎建設,之後應該會有蠻長的陣痛期要轉換,尤其是各個其他程式語言寫的 library 要考慮到 thread-safe 的問題。

話說回來,PHP 就沒繼續討論過 threading 這個問題了,大家還是繼續用 process 架構在搞 XD

Multithreading 版本 pt-online-schema-change

看起來是個嘗試,Percona 的人試著修改 pt-online-schema-change,讓他可以在 INSERT 時 multi-threading,然後看效果:「Multithreaded ALTER TABLE with pt-online-schema-change and myloader」。

可以看出來 thread 夠多的情況下其實都變快不少 (上圖主要是看絕對數字,下圖是看相對比率):


Linux 上 Intel CPU 的安全性修正與效能的影響

Hacker News Daily 上看到在講 Intel CPU 因為各種安全性問題,而需要在 Linux Kernel 上修正,所產生的效能問題:「HOWTO make Linux run blazing fast (again) on Intel CPUs」。

這一系列的子彈也飛得夠久了 (雖然還是一直有其他的小子彈在飛),所以回過頭來看一下目前的情況。

這邊主要的測試是針對 mitigations=off 與 SMT 的啟用兩個項目在測 (SMT 在 Intel 上叫做 Hyper-threading),可以看到這兩份測試結果,目前的 mitigation 對效能的影響其實已經逐漸降到可以接受的程度 (小於 5%),但關閉 SMT 造成的效能影響大約都在 20%~30%:

但是開啟 SMT 基本上是個大坑,如果有關注大家在挖洞的對象,可以看到一堆 Intel CPU 上專屬的安全性問題都跟 SMT 有關...

剛好岔個題聊一下,先前弄了一顆 AMDRyzen 7 3700X 在用 (也是跑 Linux 桌機),才感受到現在的網頁真的很吃 CPU,開個網頁版的 SlackOffice 365 的速度比原來的老機器快了好多,差點想要把家裡的桌機也換掉...

MySQL 總算要拔掉 mysql_query_cache 了

半官方的 MySQL blog 上宣佈了拔掉 mysql_query_cache 的計畫:「MySQL 8.0: Retiring Support for the Query Cache」。

作者開頭引用了 ProxySQL 的人對 MySQL Query Cache 的說明:

Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.

主要問題在於 MySQL Query Cache 在多 CPU 環境下很難 scale,很容易造成一堆 thread 在搶 lock。而且作者也同意 ProxySQL 的說法,將 cache 放到 client 的效能比較好:

We also agree with Rene’s conclusion, that caching provides the greatest benefit when it is moved closer to the client:

可以看到 Query Cache 在複雜的環境下對效能極傷。而之前也提到過類似的事情了:「Percona 對 mysql_query_cache 的測試 (以 Magento 為例)」、「關閉 MySQL 的 Query Cache」。

一般如果要 cache 的話,透過 InnoDB 裡良好的 index 應該還可以撐不少量起來。

支援多 CPU 的 ab:wrk

在「wrk」這邊看到 wrk 這個工具:「Modern HTTP benchmarking tool」。

利用 multi-threading 與 epoll/kqueue 撐出效能:

wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue.

MySQL 的 Parallel Replication

Multithreaded Replication to the Rescue」這篇提到了 Replication 的 Parallel Worker 機制。

作者給了平行的數量對 replication lag 的影響:

可以看得出來 Parallel Worker 機制對 Replication Lag 改善頗大,不過作者在 comment 提到中雷了:「MTS breaks in after restart」。

對於還在使用 traditional master-slave 架構的人可以參考看看。

C 對 Go Channel 的實做

在「Pure C implementation of Go channels.」這邊看到有人在 C 語言裡面實做 Go 的 Channel,包括了 Unbuffered 與 Buffered 版本。

看起來是支援 multithreading 的:「Add missing pthread_cond_destroy in chan init cleanup」、「Add -lpthread to CFLAGS」。