單機 10 萬個連線 MySQL

也是在「Links: February 2019」這邊看到的,裡面提到了 Percona 的「MySQL Challenge: 100k Connections」。

Percona 的測試是希望每個連線都有在做事,而不是 idle connection,這個測試有點像是卡住時的情況?看起來只有這幾個參數比較特別:

table_open_cache = 200000
back_log=3500
max_connections=110000
max_prepared_stmt_count=1000000

max_connections 開多一點算是廢話,然後因為要做事所以 max_prepared_stmt_count 也多一些,back_log 可以讓 kernel 保留來不及處理的 TCP 連線。

看起來用 sysbench 測試還撐的住,跟理論差不多,隨著連線數的增加 latency 也會增加...

PostgreSQL 對 fsync() 的修正

上次寫了「PostgreSQL 對 fsync() 的行為傷腦筋...」提到 fsync() 有些地方是與開發者預期不同的問題,但後面忘記跟進度...

剛剛看到 Percona 的人寫了「PostgreSQL fsync Failure Fixed – Minor Versions Released Feb 14, 2019」這篇才發現在 2/14 就出了對應的更新,從 release notes 也可以看到:

By default, panic instead of retrying after fsync() failure, to avoid possible data corruption (Craig Ringer, Thomas Munro)

Some popular operating systems discard kernel data buffers when unable to write them out, reporting this as fsync() failure. If we reissue the fsync() request it will succeed, but in fact the data has been lost, so continuing risks database corruption. By raising a panic condition instead, we can replay from WAL, which may contain the only remaining copy of the data in such a situation. While this is surely ugly and inefficient, there are few alternatives, and fortunately the case happens very rarely.

A new server parameter data_sync_retry has been added to control this; if you are certain that your kernel does not discard dirty data buffers in such scenarios, you can set data_sync_retry to on to restore the old behavior.

現在的 workaround 是遇到 fsync() 失敗時為了避免 data corruption,會直接 panic 讓整個 PostgreSQL 從 WAL replay 記錄,也代表 HA 機制 (如果有設計的話) 有機會因為這個原因被觸發...

不過也另外設計了 data_sync_retry,讓 PostgreSQL 的管理者可以硬把這個 panic 行為關掉,改讓 PostgreSQL 重新試著 fsync(),這應該是在之後 kernel 有修改時會用到...

Percona 推出 MySQL 8.0 的對應版本了...

Percona 在過節前推出 Percona Server for MySQL 8.0 了:「Announcing General Availability of Percona Server for MySQL 8.0」。

Oracle 版的 MySQL 8.0 多了不少功能,像是往 NoSQL 靠的功能與 GIS 相關的功能,但讓我注意到的是 Percona 自己的事情... TokuDB 因為 MyRocks 而要被放生了:

Features Being Deprecated in Percona Server for MySQL 8.0
TokuDB Storage Engine: TokuDB will be supported throughout the Percona Server for MySQL 8.0 release series, but will not be available in the next major release. Percona encourages TokuDB users to explore the MyRocks Storage Engine which provides similar benefits for the majority of workloads and has better optimized support for modern hardware.

Percona Server 8.0 推出 RC 版本了...

Percona Server 8.0 推出 RC 版了:「Release Candidate for Percona Server 8.0.12-2rc1 Is Available」。

差不多一個月前才推出 Alpha (可以參考「Percona 要推出 Percona Server 8.0 了...」),現在跳過中間的 Beta 直接推出 RC...

效能上應該還是吃 MySQL 8.0 的改進,Percona Server 主要是一些 patch... 這樣正式版應該也快了,不知道今年有沒有機會推出?

Percona 要推出 Percona Server 8.0 了...

MySQL 8.0 從四月推出到現在也快半年了,Percona 總算是要推出對應的 Percona Server 8.0 了。目前提供 alpha 版本讓大家測試:「Announcement: Alpha Build of Percona Server 8.0」。

要把現在的 patch 都轉移到 8.0 上應該是個超級大工程,可以預期系統不會很穩定... 要用來做事的最好還是先維持 5.7,可以省掉很多麻煩。

MySQL 裡 performance_schema 對效能的影響

最近在弄 MySQLperforemance_schema,開起來後發現效能影響沒有很大,跟印象中不太一樣... 找了一下文章發現 Percona 在 2017 年年初時有針對效能測試過:「Performance Schema Benchmarks: OLTP RW」。重點在這張圖:

圖上可以看到 Default 其實對效能的影響有限,另外文章也整理出來,有哪些設定對效能影響不會太大,可以考慮平常就開著:

Using Performance Schema with the default options, Memory, Metadata Locks and Statements instrumentation doesn’t have a great impact on read-write workload performance. You might notice slowdowns with Stages instrumentation after reaching 32 actively running parallel connections. The real performance killer is Waits instrumentation. And even with it on, you will start to notice a performance drop only after 10,000 transactions per second.

在 Ubuntu 18.04 (Bionic) 上跑 Percona Server 5.7

Percona 的文件「Installing Percona Server on Debian and Ubuntu」這邊雖然還沒列 Ubuntu 18.04 上去,但已經有東西在裡面可以安裝了。不過還是屬於官方未正式支援的情況,用的時候自己要注意。

另外查資料的時候有看到「Ubuntu 18.04 (bionic) - percona-xtradb-cluster-server installation break」這篇提到 Percona XtraDB Cluster 裝不起來,但有 workaround 可以硬裝進去,要玩的人也可以參考一下 XD

這樣可以把 14.04 機器換一換了。(先前清點時本來以為已經是 16.04,做一些操作時才發現是 14.04...)

MySQL 的 binlog 對效能的影響

Percona 的 CTO Vadim Tkachenko 在比較 InnoDB 與 MyRocks 時意外發現了 binlog 會影響不少效能穩定性,再加上 MySQL 8.0 有改變 binlog 相關的預設值,所以他後續花了不少時間測試,寫了兩篇關於 binlog 對於 MySQL 效能的影響:「How Binary Logs (and Filesystems) Affect MySQL Performance」與「How Binary Logs Affect MySQL 8.0 Performance」。

第一篇是想要知道在 Percona Server 5.7 上開 binlog 的影響,做出來後可以看到明顯的效能波動 (因為 binlog 導致 flush 時效能暴跌):

而其中的 workaround 就是調整 flush 參數,讓他比較頻繁的小量寫入,而不是突然要寫很多資料。這樣一來對平均效能也許比較差,但對前端應用衝擊會比較小:

在測試可以看到 sync_binlog=1000 是個妥協點。各單位要自己去找出適合的數字:

The strict setting also comes with noted performance penalties. I will also test sync_binlog=1000 and sync_binlog=10000, which means perform synchronous writes of binary logs every 1000 and 10000 transactions, respectively.

另外有測試 ext4 與 XFS 是否有影響,就測試的結果看起來 ext4 比 XFS 好一些,但差距有限:

第二篇則是拿 MySQL 8.0 與 Percona Server 5.7 比較,可以發現在 MySQL 8.0 開啟 binlog 時有時會有不少的效能損失:

It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.

雖是推銷一下自家產品在這塊還不錯 XD

MySQL 與 GraalVM 的結合...

Twitter 上看到 Oracle 計畫在 MySQL 內包入 GraalVM

這能不能解決 MySQL 的 stored procedure 一直以來都很殘的問題就要多花些時間看看了... 另外 GraalVM 用 GPLv2,但沒有明確的專利授權條款也是大家很在意的問題 (參考 Hacker News 上「GraalVM: Run Programs Faster Anywhere | Hacker News」這邊的討論),因為大家都很清楚,這家公司只要是沒有授權的東西就不要碰...

話說 Percona 都把 PostgreSQL 包進來吃了,來考慮多用用 PostgreSQL 好了... (把 blog 換掉?)

Percona 宣佈提供 PostgreSQL Support...

有點意外的,Percona 宣佈提供 PostgreSQL Support:「Percona Expands Services Offerings with PostgreSQL Support」。看起來是建出熟 PostgreSQL 的團隊來做生意了...

之後應該會在他們站上開始看到與 PostgreSQL 相關的文章了;另外一方面,對於付錢買 Percona 服務的人來說,可以跟同一個廠商通包所有的服務 (從 MySQLMariaDBPercona Server 這三個 MySQL 系列的資料庫,到 MongoDB,然後是昨天推出的 PostgreSQL):

As a result, organizations can, for the first time, work with a single trusted vendor to meet their support needs for MySQL, MongoDB, MariaDB, PostgreSQL, or any hybrid combination of these database technologies, whether deployed on-premises, in the cloud, or in a Database as a Service (DBaaS) environment.

然後也許有機會看到 Percona 客製的 PostgreSQL?