parallel

Java 17 (JDK 17)，新的 Java LTS 版本 (然後來看 GC)

Java 17 (JDK 17) 釋出，這是 Oracle 本家新的 LTS 版本，引用的是 jdk-dev 的 mailing list：「Java 17 / JDK 17: General Availability」。另外在 Hacker News 上的討論可以翻一下：「Java 17 / JDK 17: General Availability (java.net)」。

上一個 LTS 版本是 Java 11，所以很自然的也會有從 Java 11 之後的新功能說明：「JEPs in JDK 17 integrated since JDK 11」。

對於只是拿來用，而不是拿來開發的人來說，我的重點都放在 JVM 的 GC 效能以及特性。

從 Java 11 預設的 G1GC 來看，可以看到一些改善，從「JEP 345: NUMA-Aware Memory Allocation for G1」(Java 14) 這個看起來會改善 G1GC 在多實體 CPU 的情況下效能，不過看起來有 -XX:+UseNUMA 這個參數要加。

再來是「JEP 346: Promptly Return Unused Committed Memory from G1」(Java 12) 可以在閒閒的時候跑個 GC 把記憶體給 OS。

接下來是兩個新的 GC (相較於 11 版)，一個是 ZGC，另外一個是 Shenandoah，都沒有取代 G1GC，但兩個都有對應使用的場景。

ZGC 有列兩個 JEP：「JEP 376: ZGC: Concurrent Thread-Stack Processing」、「JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)」，目標是讓 GC pause time 盡可能的低，另外在 wiki 上面的說明則是有提到目標在 1ms 以下：

The ZGC garbage collector (GC) aims to make GC pauses and scalability issues in HotSpot a thing of the past.

Sub-millisecond max pause times

Shenandoah 列出了「JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)」，不過先前的「JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)」講的比較詳細，目標是希望 GC 不影響目前正在執行的程式：

Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.

可以看出來兩個新的 GC 都是希望降低 pause time，對於 latency 敏感的應用應該都可以測試看看，可以預期整體的 throughput 會低一些。

回頭來看 G1GC，有人跑了 benchmark 測試了 Java 11 與 Java 17 的 G1GC 差異：「How much faster is Java 17?」。

可以看到 G1GC 的改善 (藍色的部份) 看起來還是不少，不過有些情況下是會變慢的。文章裡面還有提到 Parallel GC，這邊就不提了，可以自己看...

等各家 build 出來後來測看看 Cassandra 的效能影響如何...

讓 Firefox 連線數變多 (然後加快速度)

最近換到 Firefox 後覺得開很多 tab 時很卡，但 CPU 也沒滿，大概是某種 lock/mutex/semaphore 機制導致硬體資源沒用完但是自己限制住...

找資料研究的時候發現 Firefox 對單一 server 的最大連線數是 6 個，而 Chrome 是 10 個：「Max parallel http connections in a browser?」。這對於網路速度夠的使用者就很卡，像是透過 RSS reader 同時對一個站台狂開分頁時就會卡住。

翻了一下 Firefox 的設定，找到相關的幾個設定，其中上面提到的是 network.http.max-persistent-connections-per-server，預設的確是 6 個，改成 10 個後測了一天好不少，決定改成跟 IE11 一樣的 13 個... (奇怪的數字)

另外一個是 network.http.max-connections，預設是 900 了，應該夠用...

Amazon Aurora 支援 Parallel Query 加速

Amazon Aurora 推出了 Parallel Query，可以加速計算速度：「New – Parallel Query for Amazon Aurora」。原理是利用 Aurora 把 storage 層打散的前提，所以有機會透過螞蟻雄兵處理：

官方給的範例可以連到原文去看，可以看到有打開 aurora_pq 與沒打開的效能差異：

15 rows in set (1 min 53.36 sec)
15 rows in set (1 hour 25 min 51.89 sec)

打開後大約是原來的 1/45 時間，提昇超多...

不過還是有些限制，我最在意的就是目前只支援相容於 MySQL 5.6 的版本 (居然不是先支援 5.7)：

Engine Support – We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL.

然後沒有多餘費用，只是 i/o cost 可能會增加：

Cost – You can make use of Parallel Query at no extra charge. However, because it makes direct access to storage, there is a possibility that your IO cost will increase.

Amazon Aurora (MySQL) 提供 Parallel Query 讓人申請使用

AWS 宣佈了 Amazon Aurora (MySQL) 支援 Parallel Query：「Amazon Aurora Parallel Query is Available for Preview」。

這邊提到的 Parallel Query 比較像是 Amazon Athena，直接把單一 Query 打散到多台機器上跑：

Amazon Aurora Parallel Query improves the performance of large analytic queries by pushing processing down to the Aurora storage layer, spreading processing across hundreds of nodes.

也就是說，這算是單一 SQL Query 平行運算的進階版本。

在這之前，AWS 都已經支援單一 Query 在單台機器上利用多 CPU 平行運算。其中 PostgreSQL 是 9.6+ 本身就有支援。Amazon Aurora (MySQL) 則是在 2016 時透過 Parallel Read Ahead 支援某些情境下的的單一 Query 多 CPU 運算了 (發現之前沒寫到...)：「Amazon Aurora Update – Parallel Read Ahead, Faster Indexing, NUMA Awareness」。

這個功能目前是 Preview 階段，然後開在這些地區讓大家測試使用：

The preview is available for the MySQL-compatible edition of Amazon Aurora, and is currently available in the US East (N. Virginia), US East (Ohio), US West (Oregon), and Europe (Ireland) Regions. Sign up to get access.

這個功能提供了想要提昇效能，但懶得改架構的人可以用錢直接硬換出來...

Git 2.8 的平行下載 submodule 加速

Git 推出新版的時候，幾家 Git Hosting 都會撰文寫一些重要的進展，像是 GitHub 這次的內容：「Git 2.8 has been released」。

GitHub 這次說明平行下載的範例直接清楚表示出來功能：

git fetch --recurse-submodules --jobs=4

用 Google 找了一個 .gitmodules 裡面有很多筆的 repository 測了一下，的確是快了不少...

PostgreSQL 的 Parallel Aggreation

PostgreSQL 9.6 將會支援 Parallel Aggreation，在多 CPU core 下 aggreation operation 單一 query 的平行化效能改善 (改善非常多)：「pgsql: Support parallel aggregation.」：

Parallel workers can now partially aggregate the data and pass the transition values back to the leader, which can combine the partial results to produce the final answer.

在「Parallel Aggregate – Getting the most out of your CPUs」這邊有測試 worker 數量與執行的速度差異：

We performed some tests on a 4 CPU 64 core server with 256GB of RAM using TPC-H @ 100 GB scale on query 1. This query performs some complex aggregation on just over 600 million records and produces 4 output rows.

由於是 64 cores，所以作者測 1 到 64 workers 的效能，這是測試出來的結果：

要注意 Y 軸是對數比例，紅色是理論值，藍色是實際值，可以看出來平行化的效能頗不錯，雖然開到 64 workers 時效率已經不到一半了。

這對離鋒時間的報表運算超好用啊...

PostgreSQL 9.5 將會有 Parallel Sequential Scan

在「Parallel Sequential Scan is Committed!」這邊看到 PostgreSQL 9.5 (還沒出) 將會有 Parallel Sequential Scan 的功能。

文章的作者直接拿了一個大家超常用的惡搞來示範，也就是經典的 LIKE '%word%'：

rhaas=# \timing
Timing is on.
rhaas=# select * from pgbench_accounts where filler like '%a%';
 aid | bid | abalance | filler
-----+-----+----------+--------
(0 rows)

Time: 743.061 ms
rhaas=# set max_parallel_degree = 4;
SET
Time: 0.270 ms
rhaas=# select * from pgbench_accounts where filler like '%a%';
 aid | bid | abalance | filler
-----+-----+----------+--------
(0 rows)

Time: 213.412 ms

這功能真不錯 XD

MySQL 5.7 將會有新的備份工具 mysqlpump

在「Introducing mysqlpump」這邊提到了 MySQL 5.7 將會有 mysqlpump 這個新工具，主要是避免影響 mysqldump，但又可以產生容易平行處理的 dump data：

The goal of mysqlpump is to have a modern utility that is extendable and has native support for parallelization.

看了一下範例還蠻簡單的 (目標也很明確)，應該是之後的參考工具...

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 架構的人可以參考看看。

MySQL 平行執行的 Replication...

「MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。

在文章裡提到，在 5.6.3 之前的版本，MySQL replication 都是 single-threaded，所以當 master 可以充分發揮多 CPU 能力時，slave 仍然要一個更新跑完才會跑下一個更新。

舉例來說，假設 master server 上有兩個 thread 在跑：

thread 1 正在執行 UPDATE table1 SET foo = 0 WHERE ...; (SQL 1，假定是 CPU bound，需要跑 100 秒)
thread 2 正在執行 UPDATE table2 SET bar = 1 WHERE ...; (SQL 2，也假定是 CPU bound，也需要跑 100 秒)

假設 thread 1 先執行完，這時候 slave 就會在跑完的時候收到 SQL 1，然後把資料同步進去。等到 100 秒過去後，再跑 SQL 2，再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。

在 master server 執行時會是這樣：