使用 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 來解決問題。

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

連結:AWS 推出 AutoScaling 管理介面

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

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

MySQL 5.5 的 InnoDB Memcached Plugin

之前曾經提過 HandlerSocket – A NoSQL Plugin for MySQL,可以透過類似 NoSQL 的方式存取 InnoDB,效能會比普通 SQL 更好。後來 Oracle 在 MySQL 5.5 推出的時候,直接使用 Memcached Protocol,理論上應該是更方便(因為 Memcached Adapter 到處都有…)。

於是最近仔細的研究了一下,發現要使用 MySQL 5.5 的 InnoDB Memcached Plugin,要注意以下的地方:

  1. 如果要使用自行指定的 Table,需要參考 Internals of the InnoDB memcached Plugin,在 innodb_memcache.containers 設定 key 與 column 的對應表。
  2. 預設是使用 containers Table 裡面 name 為 default 的 Table。
  3. 如果要指定 Table,要在 GET 或 SET 指令前,下 GET @@nameSET @@name 將之後的 Request 都切換到 name 這個 Table。
  4. 如果需要 Replication,記得要設定 innodb_api_enable_binlog 這個值。

大概重點就這些了,如果還有玩到別的再來補充。

徵才:PIXNET 徵網路系統工程師一名

我現在服務的公司 PIXNET 要徵求一名 System Administrator:

工作內容:

  • 伺服器 (主要為 FreeBSD 與 Debian、Ubuntu 系統) 系統維護,包括套件 (ports 與 apt/deb) 維護
  • 機房與辦公室網路設備 (Cisco/Juniper Router、Switch、VPN) 維護。

工作時間:9:30 ~ 18:30 (一~五),特殊狀況時 (例如晚上處理緊急事件,或是凌晨停機等) 另外補休。
就職日:可馬上就職,或 2012 年二月到職即可。
地點:台北市中山區 (捷運行天宮站旁),機房於台北市內湖區。
需求:熟悉 UNIX-like 系統,Script (Perl, Python 或 shell script 之一) 撰寫。熟 Cisco 網路設備操作者佳。
薪資:約 40k/month,其他技能面議另談。

有意者請聯絡 techjob@pixnet.tw

Google Chrome 全球市佔率超過 Mozilla Firefox,位居第二

根據 statcounter 的統計:

台灣則是在今年七月份就超過了:

於是有人在討論Google Chrome會不會是下一個IE6。配合之前 ppk 的擔憂:Mobile Safari 會不會是行動裝置上的 IE6?

我倒是覺得 Web Developer 的堅持比以上的所有討論都重要的多。畢竟,寫出 IE only 網站的,並不是 Microsoft,而是不夠專業的開發者。

AWS 提供 Email 服務 (SES)

根據 AWS Blog,AWS 開始提供使用者發送大量 Email 的服務 (Simple Email Service, SES)。價錢是每一萬封信 USD$1,流量費用另計。

要使用 SES 的服務是需要 Amazon 審核通過的,在未通過之前,收件者必須先使用 SES 的 API 認證過才能收到信,並且有一天最多寄出 200 封信的限制。審核通過後,任何收件者都能收到信,但是一開始一天最多只有 1000封信的Quota,隨著使用量與使用情形(例如Amazon有沒有收到 complain)而增加,最大一天可以寄出100萬封信。

另外寄信的速度也有限制。一開始是每秒鐘一封信,隨著使用狀況調整,最大可以到每秒鐘 90 封信。如果有一天寄出超過100萬封信的需求,可以向AWS提出調整要求。

另外,SES也可以整合進現有的Email Server裡面。(Postfix 範例