Home » Posts tagged "tuning"

Netflix 在 EC2 上調整的參數

Brendan GreggNetflixEC2 上調整的參數整理了出來:「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 秒,除以 109 後才會變成 ms。

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

用 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 那篇文章裡面有說明。

Percona 提供 Linux 平台上 MySQL server 調整的參數...

Percona 的人針對 Linux 平台跑 MySQL 的建議:「Linux performance tuning tips for MySQL」。

檔案系統方面建議用 ext4 或是 xfs,記得要用 noatime。(我建議再加上 nodiratime)

然後 i/o schedular 建議用 deadline 或是 noop,這點可以參考之前寫的「關於 Linux 的 Disk I/O 調整...」。

記憶體的部份要處理 swap 與 NUMA 的控制,然後 CPU 的部份要把自動調整速度的功能關掉 (可以省電,不過對忙碌的資料庫應該用不到)。

看起來是比較一般性的方向,不過應該是蠻好用的建議 :p

十個改善 MySQL 效能的方式

Zite 上看到這篇介紹 MySQL 效能調教的方式:「Ten ways to improve the performance of large tables in MySQL」。

這邊就順著作者的建議一路寫下去。

作者也是大力推薦用 InnoDB 解決問題。

InnoDB 有個特別的功能 (相較於 MyISAM 而言。這個功能在 MySQL 5.5 預設就是開啟的) 是 change buffering,會延遲寫入 non-unique secondary index,讓多筆 secondary index 合併起來一起寫,這會改善寫入的效能。

Partition 對於 index 的大小也會有幫助。InnoDB 的壓縮功能也是必備項目 (除非你的 Use case 很極端),減少資料量就直接減少 i/o 並且拉高 hitrate。

再大量寫入資料時依照順序寫入會讓 InnoDB 寫入的順序僅可能連續。由於 InnoDB 的特性 (clustered index),這樣可以讓寫入速度變快很多。

避免使用 UNIQUE key,因為 UNIQUE 的特性會犧牲很多效能...

因為 secondary index 是指到 PRIMARY KEY 的值,所以 PRIMARY KEY 的值僅可能單純,以 INT 或是 BIGINT 為佳。

第一次大量倒資料進系統時,可以先倒 data 以及 PRIMARY KEY 就好 (如上所說的,要依照 PRIMARY KEY 的順序倒進去),等倒完後再建立 secondary index,這樣速度會快很多。

最後兩項就是,記憶體愈大愈好,硬碟愈快愈好,如果用 SSD 是可行的方案就用 :p

Archives