tuning

在 ZFS 上跑 PostgreSQL 的調校

在「Everything I've seen on optimizing Postgres on ZFS」這邊看到如果要在 ZFS 上面跑 PostgreSQL 時的調校方式，看起來作者有一直在更新這篇，所以需要的時候可以跑去看...

主要的族群是要搞 self-hosted PostgreSQL 的人，相較於 ext4 或是 XFS，底層如果使用 ZFS 可以做許多事情，像是 compression 與 snapshot，這對於很多 DBA 相關的操作會方便不少，但也因為 ZFS 的關係，兩邊 (& PostgreSQL) 需要一起調整以確保效能...

不過短期應該還是用 RDS 就是了...

從調校 HTTP Server 的文章中學各種奇技淫巧

在「Extreme HTTP Performance Tuning: 1.2M API req/s on a 4 vCPU EC2 Instance」這篇文章裡面，作者在示範各種奇技淫巧調教校 HTTP server。

在 Hacker News 上的討論也蠻有趣的：「Extreme HTTP Performance Tuning (talawah.io)」。

雖然是在講 HTTP server，但裡面有很多東西可以拿出來獨立用。

想特地拿出來聊的大項目是「Speculative Execution Mitigations」這段，作者有些說明，除非你真的知道你在做什麼，不然不應該關掉這些安全相關的修正：

You should probably leave the mitigations enabled for that system.

而作者是考慮到 AWS 有推出 AWS Nitro Enclaves 的前提下決定關掉，但我會建議在 *.metal 的機器上才這樣做，這樣可以避免這台機器上有其他 AWS 帳號的程式在跑。

測試中關了一卡車 mitigation，得到了 28% 的效能提昇：

Disabling these mitigations gives us a performance boost of around 28%.

這其實比預期中多了不少，這對於自己擁有實體機房跑 Intel 平台的使用者來說，很吸引人啊...

Percona 對於 PostgreSQL 使用 HugePages 的評論

開頭我先說一下我的想法，我對於 Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度，因為他先前在「Benchmark PostgreSQL With Linux HugePages」這篇做的 benchmark 就有奇怪的結果，但卻給不出合理的原因，甚至連 Percona 自家的 CEO 公開在 comment 問之後也沒有看到文章提出合理的解釋：

Hi,

A lot of interesting results here…

1) PgBench access distribution is very interesting. With database size growing by 20% from 80G to 96G we see performance drop of Several times which is very counter-intuitive

2) There is no difference between 2MB and 4K but huge difference between 1G and 2M even though I would expect at least some TLB miss reduction in the first transitioning. I would understand it in case transparent huge pages are Enabled… but not disabled

3) For 96GB why would throughput grow with number of clients for 1G but fall for 2M and 4KB.

這次看到「Settling the Myth of Transparent HugePages for Databases」這篇，也是在討論 Linux 的 HugePages 對 PostgreSQL 帶來的影響，同樣馬上又看到奇怪的東西...

首先是標示與圖片不合：

Figure 1.1 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload(48GB) < shared_buffer (64GB)

Figure 1.2 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload (48GB) > shared_buffer (64GB)

不過這邊可以推測 Figure 1.2 應該是 112GB (因為對應的圖片上面標的是 112GB)，當做是標錯就好。

但這樣又跑出一個奇怪的結果，48GB 的資料量比較小，TPS 大約是 35K/33K/41K，但 112GB 資料量比較大，卻可以達到 39K/43K/41K~42K，反而比較快？我暫時想不到什麼理由...

整體的測試有 pgbench 與 sysbench (這邊也打錯成 sysbecnch，先不管)，其中 pgbench 跑了 10 mins 與 60 mins 的版本，但是 sysbench 只跑了 10 mins 的版本？這是什麼原因...

另外還是有些情況是打開 HugePages 比較快的 (sysbench 的 64 clients)，如果以直覺來說的話，我反而還是會打開 HugePages (yeah 純粹是直覺)，我現在比較想知道他會在 Percona 裡面待多久...

單機 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 也會增加...

Netflix 在 EC2 上調整的參數

Brendan Gregg 把 Netflix 在 EC2 上調整的參數整理了出來：「AWS re:Invent 2017: How Netflix Tunes EC2」。

這些參數在 2017 的 AWS re:Invent 時有講到，他整理出來讓大家更方便參考：

My last talk for 2017 was at AWS re:Invent, on "How Netflix Tunes EC2 Instances for Performance," an updated version of my 2014 talk.

裡面有提到這是針對 Ubuntu 16.04 的調整 (而且是在 2017 年的版本，應該是 16.04.3？)，用之前請理解每個參數：

WARNING: These tunables were developed in late 2017, for Ubuntu Xenial instances on EC2.

用 Machine Learning 調校資料庫

AWS AI Blog 在月初上放出來的消息：「Tuning Your DBMS Automatically with Machine Learning」。

Carnegie Mellon Database Group 做的研究，除了預設值以外，另外跟四種不同的參數做比較，分別是 OtterTune (也就是這次的研究)、Tuning script (對於不熟資料庫的人，常用的 open source 工具)、DBA 手動調整，以及 RDS：

MySQL：

PostgreSQL：

比較明顯的結論是：

Default 值在所有的 case 下都是最差的 (無論是 MySQL 與 PostgreSQL 平台，以及包括 99% 的 Latency 與 QPS，這樣二乘二的四個結果)。而且 Default 跑出來的數字與其他的差距都很明顯。
OtterTune 在所有 case 下跑出來都比 Tuning script 的好。這也是合理的結果，本來就是想要取代其他機器跑出來的結果。

至於有些討論 DBA 會失業的事情，我是樂見其成啦... 這些繁瑣的事情可以自動化就想交給自動化吧 XD

減少「註解長度」增加 Node.js 效率...

在「#NodeJS : A quick optimization advice」這邊看到這樣的效能改善方法... 兩段程式碼，只差在註解：

效能差了 50%：

只是因為註解的長度有差，只要用 --max-inlined-source-size 調整就可以避開了：

超苦超無奈：

So when you have a function or callback that’ll be called repeatedly, try to make it under 600 characters (or your tweaked value), you’ll have a quick win !

用 MySQL 5.6 的 Performance Schema 觀察系統效能

Percona 寫的「MySQL query digest with Performance Schema」這篇提到了 MySQL 5.6 的 Performance Schema 裡的 events_statements_summary_by_digest 相當好用，實際在系統上翻了翻發現算是非常實用的資料。

首先先看這個表格實際的內容，由於文字塞不動，就改用圖片了：

可以試著用 SELECT * FROM performance_schema.events_statements_summary_by_digest LIMIT 1 G 之類的指令看到裡面的值，像是這樣：(裡面有些欄位名稱我換掉了，換掉的部份用刪節號標示)

                SCHEMA_NAME: kkbox
                     DIGEST: 490a2e363ba7840843733e219175e2a7
                DIGEST_TEXT: SELECT * FROM `table1` WHERE TYPE = ? AND `column1` IN (?) AND STATUS IN (...) ORDER BY STATUS DESC , `created_at` DESC , `id` DESC 
                 COUNT_STAR: 299179761
             SUM_TIMER_WAIT: 215069693134746000
             MIN_TIMER_WAIT: 130241000
             AVG_TIMER_WAIT: 718864000
             MAX_TIMER_WAIT: 54442047235000
              SUM_LOCK_TIME: 21915487179000000
                 SUM_ERRORS: 0
               SUM_WARNINGS: 0
          SUM_ROWS_AFFECTED: 0
              SUM_ROWS_SENT: 1240784631
          SUM_ROWS_EXAMINED: 2499118409
SUM_CREATED_TMP_DISK_TABLES: 0
     SUM_CREATED_TMP_TABLES: 0
       SUM_SELECT_FULL_JOIN: 0
 SUM_SELECT_FULL_RANGE_JOIN: 0
           SUM_SELECT_RANGE: 0
     SUM_SELECT_RANGE_CHECK: 0
            SUM_SELECT_SCAN: 0
      SUM_SORT_MERGE_PASSES: 2630
             SUM_SORT_RANGE: 299196698
              SUM_SORT_ROWS: 1240808755
              SUM_SORT_SCAN: 0
          SUM_NO_INDEX_USED: 0
     SUM_NO_GOOD_INDEX_USED: 0
                 FIRST_SEEN: 2015-09-17 20:41:15
                  LAST_SEEN: 2015-10-15 01:06:10

其中 DIGEST_TEXT 是 SQL query，可以看到 IN 裡面的東西會被整合起來，而 COUNT_STAR 是次數，後面的 AVG_TIMER_WAIT 單位是 10^-12 秒，除以 10⁹ 後才會變成 ms。

裡面的資訊對於 DBA 在 tune 效能時應該是很有用...

Amazon Redshift 的 Query 效能調教

Amazon Redshift 在 Web Console 上推出的新功能：「Custom ODBC/JDBC Drivers and Query Visualization for Amazon Redshift」：

會把 query 的步驟拆成多個步驟，針對比較吃資源的步驟標出來，讓設計的人可以思考要怎麼改。

用 perf 追蹤系統狀態

在「Make Your Program Slower With Threads」這邊看到的工具：「Linux kernel profiling with perf」。

Ubuntu 上的安裝方式是安裝 linux-tools，不過我的機器上是安裝 linux-tools-lts-raring。

先從比較簡單的 stat，基本的用法很簡單，後面接指令就可以了：

perf stat ls -al

這樣會出現基本的執行狀況，像是這樣：

 Performance counter stats for 'ls -al':

         11.236723 task-clock                #    0.703 CPUs utilized          
               341 context-switches          #    0.030 M/sec                  
                 0 cpu-migrations            #    0.000 K/sec                  
               453 page-faults               #    0.040 M/sec                  
         8,186,524 cycles                    #    0.729 GHz                    
    stalled-cycles-frontend 
    stalled-cycles-backend  
        10,366,309 instructions              #    1.27  insns per cycle        
         2,122,560 branches                  #  188.895 M/sec                  
            36,979 branch-misses             #    1.74% of all branches        

       0.015977493 seconds time elapsed

更複雜的用法在 Tutorial 那篇文章裡面有說明。