PostgreSQL 的 scale 建議

Hacker News Daily 上看到「Postgres scaling advice for 2021」這篇,講 PostgreSQL 要怎麼 scale,在 Hacker News 上也有對應的討論可以看:「Postgres scaling advice (cybertec-postgresql.com)」。

文章前面先提到分散式系統的複雜度會導致 RDBMS 上的一些假設失效,所以如果可以用單台機器暴力解,就儘量用單台機器來解 (scale up 的情境),裡面就提到了一些「暴力可以解決很多問題」的說明,差不多就是前幾天提到的「Let's Encrypt 升級資料庫伺服器 (AMD YES?)」。

後面提到如果真的要放進分散式的 RDBMS (scale out 的情境),怎麼設計資料結構會比較好。

這邊剛好也可以提一下,量夠大的時候要把 OLTPOLAP 的應用分開,現在有很多 OLAP 資料庫可以選擇,同步的工具也很成熟了,通常效能會比在 OLTP 上面硬跑來的好。

最後提一下,文章裡面對於 transaction per second 可以拉很高,有些假設沒有明寫出來。這需要盡可能把 transaction 拆小,避免常常有 giant transaction 卡住整個資料庫,這點對於一般的系統會需要做不少改寫...

不過最後比較疑惑的是,這種文章怎麼會上 Hacker News 的啊...

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.

細看 MySQL 的 Performance Schema 對效能的影響

Percona 的人對 MySQL 5.7 的 OLTP RW 測試中,Performance Schema 的各種不同的功能對效能帶來的影響:「Performance Schema Benchmarks: OLTP RW」。

原文章裡有定義這些分別是打開哪些功能,這邊就跳過去... 重點是 default 值對效能的影響其實不算高,所以除非是想要壓榨每一分效能,不然其實可以考慮打開 (針對 OLTP RW 類似的應用):

影響比較大的是 Stages 與 Waits 的部份。而 Mark Callaghan 在 comment 提到在 Performance Schema Event Timing 這邊有相關的資料... 看起來應該可以降低對 Stages 與 Waits 的效能衝擊。

用 sysbench 測試 MySQL 效能

很久前是用 tpcc-mysql 測試 MySQL 效能:「用 tpcc-mysql 測試 LSI 的 Nytro MegaRAID NMR 8100-4i」,最近剛好又有測試需求,想說拿來學個新玩具測試,就想到 sysbench 的 oltp 測試。

先用 Google 找了找測試的方式,appleboy 之前寫的「Sysbench 測試 Percona XtraDB Server 效能」算是還不錯的文件,就拿來當起點了。

我是拿 AWS 測試,主要是因為幾乎所有的效能都是固定的,這樣測出來才有意義。

Amazon EC2 用 c4.8xlarge,用 10Gbps 網路測試會比較準確一點。硬碟的部份是掛上 100GB 的 SSD 硬碟,如果是測 I/O bound 的人就選擇有固定 IOPS 的 Provisioned 版本,但我這次測的都是 CPU bound,就只選用 General 版本了。

跑起 Ubuntu 14.04 後直接用 apt-get install sysbench 就可以裝起來了。

Percona 的 apt repository 設定可以參考官方的「Installing Percona Server on Debian and Ubuntu」這篇文章。設好後要裝什麼版本測試就是自己的選擇了。

都裝好後,測試的方式是先用 prepare 塞資料,再用 run 測試。

這是 prepare 部份的指令:(粗體字的 x 需要帶入自己對應的參數)

sysbench --test=oltp --db-driver=mysql --mysql-engine-trx=yes --mysql-table-engine=innodb --mysql-host=x --mysql-user=x --mysql-password=x --oltp-auto-inc=off --test=/usr/share/doc/sysbench/tests/db/oltp.lua --oltp-table-size=10000000 prepare

這是 run 部份的指令,我這邊用了 --oltp-read-only=on 只測 read transaction 的速度:

sysbench --test=oltp --db-driver=mysql --mysql-engine-trx=yes --mysql-table-engine=innodb --mysql-host=x --mysql-user=x --mysql-password=x --oltp-auto-inc=off --test=/usr/share/doc/sysbench/tests/db/oltp.lua --oltp-table-size=10000000 --oltp-read-only=on --num-threads=256 --report-interval=5 --max-time=60 --max-requests=0 run

大致上就是這樣測,然後用 gnuplot 畫圖。