使用 pt-stalk 找出 MySQL 效能問題

pt-stalkPercona Toolkit for MySQL 裡面的其中一項工具。它會連到 MySQL Server,監控指定的數值,當超過指定的 Threshold 時,收集當時資料庫執行的資訊(包含正在進行的 transaction、vmstat、lsof,甚至 gdb stack trace),方便分析解決問題。

pt-stalk 需要以 root 權限執行。執行的方法如下:

pt-stalk --daemonize --variable Threads_connected --threshold 400 -- --defaults-file=/etc/mysql/my.cnf

當同時有 400 以上的 Threads 時,便會收集資料,存到 /var/lib/pt-stalk 內。收集的資料範例:

2014_01_13_00_25_09-df              2014_01_13_00_25_09-lock-waits      2014_01_13_00_25_09-netstat         2014_01_13_00_25_09-ps
2014_01_13_00_25_09-disk-space      2014_01_13_00_25_09-log_error       2014_01_13_00_25_09-netstat_s       2014_01_13_00_25_09-slabinfo
2014_01_13_00_25_09-diskstats       2014_01_13_00_25_09-lsof            2014_01_13_00_25_09-opentables1     2014_01_13_00_25_09-sysctl
2014_01_13_00_25_09-hostname        2014_01_13_00_25_09-meminfo         2014_01_13_00_25_09-opentables2     2014_01_13_00_25_09-top
2014_01_13_00_25_09-innodbstatus1   2014_01_13_00_25_09-mpstat          2014_01_13_00_25_09-output          2014_01_13_00_25_09-transactions
2014_01_13_00_25_09-innodbstatus2   2014_01_13_00_25_09-mpstat-overall  2014_01_13_00_25_09-pmap            2014_01_13_00_25_09-trigger
2014_01_13_00_25_09-interrupts      2014_01_13_00_25_09-mutex-status1   2014_01_13_00_25_09-processlist     2014_01_13_00_25_09-variables
2014_01_13_00_25_09-iostat          2014_01_13_00_25_09-mutex-status2   2014_01_13_00_25_09-procstat        2014_01_13_00_25_09-vmstat
2014_01_13_00_25_09-iostat-overall  2014_01_13_00_25_09-mysqladmin      2014_01_13_00_25_09-procvmstat      2014_01_13_00_25_09-vmstat-overall

然後看 InnoDB status,可以看到很多 transaction 正在等 query cache lock:

MySQL thread id 688253701, OS thread handle 0x7f6a591c9700, query id
19004545452 10.1.1.94 pixblog Waiting for query cache lock
SELECT * FROM `blogarticle` WHERE (`blogarticle_blogid` = 3835626) AND
(`blogarticle_date` < 1388605724) AND (`blogarticle_status` IN (2,3,5,7))
ORDER BY `blogarticle_date` desc, `blogarticle_id` desc LIMIT 1
---TRANSACTION 144B7B32FC, not started
MySQL thread id 688253702, OS thread handle 0x7f6a787bc700, query id
19004544621 10.1.1.191 pixblog Waiting for query cache lock
SELECT * FROM `blog` WHERE `blog_id` = 3126963
---TRANSACTION 144B7B32FD, not started
MySQL thread id 688253706, OS thread handle 0x7f6a887e2700, query id
19004544620 10.1.1.166 pixblog Waiting for query cache lock
SELECT * FROM `bloglayout` WHERE `bloglayout_id` = 3063007
---TRANSACTION 144B7B33C7, not started starting index read
mysql tables in use 1, locked 0

發生問題的當時確實有一個跑統計報表的 Slow Query 正在執行,於是要求該 Query 不使用 Query Cache1 來解決問題。

Galera 3.x 的 Replication Relaying

Galera 3.x 為了多機房間的 Replication,設計了 gmcast.segment 這個參數。前陣子 Percona 的人出來介紹了這個參數背後的機制:Automatic replication relaying in Galera 3.x (available with PXC 5.6)。大致摘錄如下:

  1. 同一個機房內資料庫的 gmcast.segment 參數要設為相同。
  2. 機房與機房之間的 Replication 會自動找一個 node 進行 Relay,以降低 Replication 需要的頻寬。

    Image from: Automatic replication relaying in Galera 3.x (available with PXC 5.6)

如果沒有設定 gmcast.segment 參數的話,同樣是三個 Node,會耗用兩倍的頻寬:

Image from: Automatic replication relaying in Galera 3.x (available with PXC 5.6)

原文中另外有對作了 segment 與不作 segment 的 commit latency 進行比較,結果作了 segment 的 commit latency 並沒有比較高。如果有跨機房需求,應該要設定 gmcast.segment。

MySQL 5.6 的 Index Condition Pushdown

MySQL 5.6 以前的 Multi-column Index,當位於 index 中間的 column(如下例的 j)需要進行 range query 的時候,只能利用到部分的 index,需要另外讀取資料列的內容來進行判斷。舉例來說,如果有一個 Table 結構是這樣:

CREATE TABLE mytable (
id int not null auto_increment primary key,
i int(11) NOT NULL,
j int(11) NOT NULL,
k int(11) NOT NULL,
val char(10) NOT NULL,
KEY ijk (i,j,k)
) ENGINE=InnoDB;

在 MySQL 5.6 之前,SQL Query 「SELECT sum(length(val)) FROM T WHERE i=1 AND j<100 AND k=100」 會把所有 i=1 的資料列拉出來,逐一比較 j 與 k 的值。MySQL 5.6 的 Index Condition Pushdown (ICP) 功能,把這個動作改為比較 Index tuple 而非資料列內容,可避免拉出整個資料列,降低磁碟 IO(因為資料列通常比 Index 大)。

詳細的說明可以看 MySQL 的官方文件:Index Condition Pushdown Optimization 與 Percona 的測試:Multiple column index vs multiple indexes with MySQL 5.6

Gmail 預設顯示 Email 內的圖片

上週的新聞,Gmail 會將 Email 內嵌的圖片,透過 Proxy 處理之後顯示出來。除了改進使用者體驗外,也可以避免惡意圖片攻擊使用者的電腦。

ThreatPost 上有人測試了這個功能,發現 Gmail 會在使用者開啟信件的時候,才會去抓取圖片並且進行處理,所以目前使用的開信追蹤技術,只要指定獨一無二的追蹤網址給每個用戶,還是可以正常運作。不確定 Google 是否有打算處理隱私問題?另外這篇文章也提到有可能可以利用 Google 的 Image Proxy 來作 DDoS…

也是一個值得繼續觀察的項目 XD

Amazon Web Services 進入中國

AWS 週三在官方部落格發表了與中國公司合作,伺服器位於中國境內的 Cloud Service。這個服務的帳號與其他地區的 AWS 服務帳號不同,需要另外申請,現有的 AWS 用戶也不能夠使用同一個帳號直接開通中國的 AWS 服務,看起來是直接把客戶資料的部份隔離開來…

等到 Public Beta 的時候再來看看狀況…

AWS AutoScaling 終於有 Web 管理介面了…

連結:AWS 推出 AutoScaling 管理介面

使用 IaaS 這類的服務,最方便的地方就是:當有緊急需求需要增加伺服器的時候,可以直接在網頁上點一點就完成增加的動作。但是,如果收到簡訊告警的時候,剛好在沒有網路的地方,就只好遠端電話遙控同事到網頁上操作,總覺得不是那麼方便。AWS 提供的 AutoScaling 服務,可以預先設定一些條件(例如 CPU 使用率超過多少,或是 Elastic Load Balance 的 Requests/sec 數量超過多少),當滿足這些條件時,自動增加(或減少)伺服器。原本這個功能只能透過 API 設定,今天終於有網頁版了…

使用 AutoScaling 網頁介面,除了可以開一般的 Instance 以外,還可以開 Spot Instance。對於需要大量運算資源,但是即時性要求不那麼高的服務來說,可以省下不少費用。

Amazon Web Service re:Invent 2013 發表的新產品

隨時更新。

新的 Instance Type

  • C3 Instance: 提供更高運算能力的 Instance。使用 Intel E5-2680 CPU,最高提供 32 核心,一小時收費 USD$2.40。
  • I2 Instance: 提供高 IO 效能的 Instance。使用 SSD 當作 Instance Storage。(預計於近期提供服務)

資料庫

Big Data

  • Kinesis: 處理即時 Stream 資料(如 Web Server Access Log,使用者行為 Log 等)的工具,目前需要申請才能試用。

其他

  • AppStream: 在 AWS 平台上跑應用程式,將結果(影像與聲音)輸出到使用者的設備上,並從設備上取得使用者輸入傳回應用程式裡。
  • Workspace: 在 EC2 上跑遠端桌面,提供給企業用戶方便複製、管理的工作環境。最便宜的方案是一個月每個人 USD$35。
  • CloudTrail: 紀錄 AWS 上使用 API 的狀況,可以丟到各種第三方服務或軟體(例如 Loggly 或 Splunk)進行分析。

Galera Cluster 的 gcache.size 設定

gcache.size 的大小會影響 Node 加入 Cluster 時,需不需要完整複製資料。如果資料更動程度過大,在 gcache 裡面已經找不到更動部份的話,就需要完整複製資料;反之則可以直接 apply gcache 裡面的變更。Understanding gcache in Galera 很詳細的說明了 gcache 的用途。

gcache.size 的預設值是 128MB。查了一下資料,是使用 MMAP 的方式來應用1,所以可以盡量設定大一些。雖然 mysqld 看起來會很肥,但實際上是吃不到那麼多記憶體的。我們是設定成 8G。

  1. http://www.percona.com/files/presentations/percona-live/nyc-2012/PLNY12-galera-cluster-best-practices.pdf []

Google 贊助的 uProxy

uProxy/1是一個 Firefox 和 Chrome 的擴充套件,安裝之後,可以讓透過同樣安裝了 uProxy 的朋友電腦瀏覽網站。自己與朋友中間的連線是加密的。只要你信任朋友不會偷聽你的資料,就可以避免在公共場所使用 WiFi 的安全性問題。

不過在我看來,uProxy 會大大的降低 Proxy 架設與使用門檻。以後只需要在家中的電腦安裝 uProxy,在外面就能夠使用加密的連線,透過家中網路上網。就算不信任朋友不會惡搞你,自己在家裡放電腦(或是到 AWS 上開一台 Windows 跑瀏覽器 XD)就可以增強使用公共場所 WiFi 的安全性,避免被竊聽。

另外,如果在中國需要翻牆,或是某些日本限定的網站,也可以很簡單的透過這個套件來規避限制了。

最後我覺得這個專案的挑戰是,怎麼讓 uProxy 在行動裝置(智慧型手機、平板之類的)上面可以簡單的安裝與使用。我不確定 Firefox 的情形,但是 Chrome 與 Safari 都沒有擴充套件的機制…… 另外蘋果的 Walled Garden 也增加了很多不確定性,說不定連上架都會被拒絕。

目前這個專案還在 Closed Beta 階段,就等之後的發展了。

  1. 由 University of Washington 與 Brave New Software 開發,Google 贊助。 []