Go 1.9 的 GC 改善

Update:被提醒後仔細看了一下,是 1.8 預設生效 (但保留選項切回來 debug),如果沒問題的話 1.9 把舊的方式拔乾淨:

Assuming things go smoothly, we will remove stack re-scanning support when the tree opens for Go 1.9 development.

標題就不改了... 以下原文。

在「Sub-millisecond GC pauses」這邊看到的。Golang 想辦法將 GC 造成的影響降低:「Proposal: Eliminate STW stack re-scanning」。

目標是解決最大的 GC pause 來源:

As of Go 1.7, the one remaining source of unbounded and potentially non-trivial stop-the-world (STW) time is stack re-scanning.

然後拿新的解法來戰,目前初步的測試看起來可以降到 50µs (== 0.05ms):

We propose to eliminate the need for stack re-scanning by switching to a hybrid write barrier that combines a Yuasa-style deletion write barrier [Yuasa '90] and a Dijkstra-style insertion write barrier [Dijkstra '78]. Preliminary experiments show that this can reduce worst-case STW time to under 50µs, and this approach may make it practical to eliminate STW mark termination altogether.

在「runtime: eliminate stack rescanning · Issue #17503 · golang/go」這邊可以看到進度,現在已經在 master branch 上了,看起來會在 1.9 的時候被放出來... 不過 worst case 的時間上修了 XDDD

The high level summary is that this reduces worst-case STW time to about 100 µs and typical 95%ile STW time to 50 µs (assuming, of course, that the OS doesn't get in the way and that the system isn't otherwise overloaded).

但看起來應該還是很大的效能改善,尤其是 CPU bound 的應用?

商業版本的 Zing JVM 對 GC 的改善

在翻「Stuff The Internet Says On Scalability For February 19th, 2016」這邊的資料時看到這篇文章講到 Zing JVM 大幅降低了他們在 C10M 時遇到的 latency 問題:「Fast C10M: MigratoryData running on Zing JVM achieves near 1 Gbps messaging to 10 million concurrent users with 15 millisecond consistent latency」。

包括了平均值、99% 值、最大值都大幅下降:

In this post, we show that by simply replacing the JVM with Zing JVM out-of-the-box (without any tuning), and preserving the same C10M benchmark scenario and setup, we can reduce the average latency from 61 milliseconds to under 15 milliseconds. Moreover, and more importantly, the latency spikes can be significantly reduced from 585 milliseconds to 25 milliseconds for the 99th percentile latency and from 1700 milliseconds to 126 milliseconds for the maximum latency. Therefore, every single message can be delivered, even in the worst case, with almost no delay.

而且他們發現最高的 126ms 也不是 GC 造成的,而是 benchmark 這邊造成的:

And so, the relatively high latency spikes we saw in the previous C10M benchmark were due to JVM’s Garbage Collection (GC). In the new benchmark, not only Zing JVM didn’t introduce high latency spikes, but based on analyzing the logs, it appears that GC effects no longer dominate latency behavior. The dramatically improved 126 ms max latency is not caused by GC but by other condition of the benchmark setup. Anyway, this max latency was so small for a web architecture that we did not spend time to determine at which level exactly it occurred.

Zing 的價錢是一台 USD$8000/year,另外也有虛擬機版本 (另外報價),如果遇到 JVM GC 問題,看起來會是個可以花錢解決問題的方案:

Zing® is priced on a subscription basis per server. With per-server pricing, you don’t need to worry about core counts, memory size, or number of instances deployed per server. The annualized subscription price for Zing per physical server ranges from $8000 (for a single license) to under $2000 (for orders above 1000 servers). Higher volumes and longer subscription terms will reduce the per-server price for Zing. Pricing for virtual servers is also available upon request.

ScyllaDB:用 C++ 改寫相容於 Cassandra 的系統

Scylla 是出自希臘神話,維基百科對應的連結:「斯庫拉」、「Scylla」。而在 ScyllaDB 官網副標題寫著:

Fully compatible with Apache Cassandra at 10x the throughput and jaw dropping low latency

JVM 的 GC 老問題在 Cassandra 中帶來的 latency 不穩定本來就是個痛苦的問題,要花很多力氣去調整,而用 C++ 改寫等於是自己處理這一塊。

這帶來的效能提昇可以從各種測試結果看出來,像是單機的測試:「Scylla vs. Cassandra benchmark」,以及多機的測試:「Scylla vs. Cassandra benchmark (cluster)」(可以參考下圖)。

而 Latency 的改善也是極為明顯:「Latency benchmark」。

其中另外一個重要的技術是 IntelDPDK,可以大幅降低現有 Linux Kernel 在網路架構上的損耗:「Dedicated fast network stack for modern hardware」。

很有趣的專案,好久沒碰 Cassandra 了...

Go 1.5 的進展

Andrew Gerrand 在「The State of Go - Where we are in May 2015」這份投影片裡面提到了不少 1.5 的改變與改善,預定在今年八月釋出。

首先是全部都改用 Go 寫,不再需要 C 語言的協助了:

The gc tool chain has been converted from C to Go.

而效能上的改善最大的是 GC 的部份:

另外是對行動平台的發展:

Go 1.5 provides support for Android and experimental support for iOS.

這樣變得頗有趣的,自家的 Android 有打算換掉 Java 嗎?

Ruby 2.2.0:放假前的新版本

Ruby 2.2.0 在假期前釋出:「Ruby 2.2.0 Released」。

在「Notable Changes since 2.1」的部份有提到新的 GC algorithm (Incremental GC) 以及讓 Symbol 可以被 GC (Symbol GC),而且提到了 Rails 5.0 會受益於此:

Recent developments mentioned on the Rails blog suggest that Rails 5.0 will take advantage of Incremental GC as well as Symbol GC.

在 Rails 這邊的說明:

Rails 5.0 will target Ruby 2.2+ exclusively. There are a bunch of optimizations coming in Ruby 2.2 that are going to be very nice, but most importantly for Rails, symbols are going to be garbage collected.

增加一行程式碼讓 PHP Composer 效率爆增

可以直接看 GitHub 上的 commit log:「Disable GC when computing deps, refs #3482」。

      */     public function run()
     {
+        gc_disable();
+
         if ($this->dryRun) {
             $this->verbose = true;
             $this->runScripts = false;

下面變成祭典了 XDDD

然後依照「Avoid generating duplicate conflict rules by naderman · Pull Request #3482 · composer/composer」這邊的測試 (要看下面的討論),設 zend.enable_gc=0 會省的更多,效率用倍數在跳的...

因為 Composer 的效率為人詬病很久了,這次有人暴發出來,會讓一群人投入資源找更多 optimization... XD

Datomic 以及 RethinkDB...

Baron Schwartz (Percona 的 Chief Performance Architect) 寫了一篇「Immutability, MVCC, and garbage collection」狂酸 DatomicRethinkDB (喔,還稍微提到 CouchDB)。

裡面提到了 append-only B-tree 這的資料結構,優點以及會遇到的問題。(而這些問題都是致命的...)

下面的 comment 就看到 Datomic 的人跑出來反擊了,不過我懶的看了... XD

RDBMS 這麼多人發展這麼久了,不太有機會有萬靈丹突然出現解決一切問題... (這表示之前的人都是笨蛋?)

新出來一個 RDBMS 系統,官網做的很漂亮,是由一個商業公司拿錢發展出來,號稱可以解決很多問題,大概都可以先跳過去... XD