一，獲取mysql用戶下的進程總數(shù)
成都創(chuàng)新互聯(lián)公司長期為成百上千客戶提供的網站建設服務，團隊從業(yè)經驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網生態(tài)環(huán)境。為海林企業(yè)提供專業(yè)的成都做網站、成都網站設計、成都外貿網站建設，海林網站改版等技術服務。擁有十多年豐富建站經驗和眾多成功案例,為您定制開發(fā)。
ps -ef | awk '{print $1}' | grep "mysql" | grep -v "grep" | wc-1
二，主機性能狀態(tài)
# uptime
[root@ ~]# uptime
13:05:52 up 53 days, 52 min, 1 user, load average: 0.00, 0.00, 0.00
三，CPU使用率
# top
或
# vmstat
四，磁盤IO量
# vmstat 或 # iostat
五，swap進出量[內存]
# free
六，數(shù)據(jù)庫性能狀態(tài)
(1)QPS(每秒Query量)
QPS = Questions(or Queries) / seconds
mysql show /*50000 global */ status like 'Question';
(2)TPS(每秒事務量)
TPS = (Com_commit + Com_rollback) / seconds
mysql show status like 'Com_commit';
mysql show status like 'Com_rollback';
(3)key Buffer 命中率
key_buffer_read_hits = (1-key_reads / key_read_requests) * 100%
key_buffer_write_hits = (1-key_writes / key_write_requests) * 100%
mysql show status like 'Key%';
(4)InnoDB Buffer命中率
innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%
mysql show status like 'innodb_buffer_pool_read%';
(5)Query Cache命中率
Query_cache_hits = (Qcahce_hits / (Qcache_hits + Qcache_inserts )) * 100%;
mysql show status like 'Qcache%';
(6)Table Cache狀態(tài)量
mysql show status like 'open%';
(7)Thread Cache 命中率
Thread_cache_hits = (1 - Threads_created / connections ) * 100%
mysql show status like 'Thread%';
mysql show status like 'Connections';
(8)鎖定狀態(tài)
mysql show status like '%lock%';
(9)復制延時量
mysql show slave status
(10) Tmp Table 狀況(臨時表狀況)
mysql show status like 'Create_tmp%';
(11) Binlog Cache 使用狀況
mysql show status like 'Binlog_cache%';
(12) Innodb_log_waits 量
mysql show status like 'innodb_log_waits';
當然你也可以使用一下開源監(jiān)控軟件進行監(jiān)控
一，RRDTool
二，Nagios
三，MRTG
四，Cacti
首先介紹下 pt-stalk，它是 Percona-Toolkit 工具包中的一個工具，說起 PT 工具包大家都不陌生，平時常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于這個工具包，這里就不多介紹了。
pt-stalk 的主要功能是在出現(xiàn)問題時收集 OS 及 MySQL 的診斷信息，這其中包括：
1. OS 層面的 CPU、IO、內存、磁盤、網絡等信息；
2. MySQL 層面的行鎖等待、會話連接、主從復制，狀態(tài)參數(shù)等信息。
而且 pt-stalk 是一個 Shell腳本，對于我這種看不懂 perl 的人來說比較友好，腳本里面的監(jiān)控邏輯與監(jiān)控命令也可以拿來參考，用于構建自己的監(jiān)控體系。
三、使用
接著我們來看下如何使用這個工具。
pt-stalk 通常以后臺服務形式監(jiān)控 MySQL 并等待觸發(fā)條件，當觸發(fā)條件時收集相關診斷數(shù)據(jù)。
觸發(fā)條件相關的參數(shù)有以下幾個：
function：
°?默認為 status，代表監(jiān)控 SHOW GLOBAL STATUS 的輸出；
°?也可以設置為 processlist，代表監(jiān)控 show processlist 的輸出；
variable：
°?默認為 Threads_running，代表 監(jiān)控參數(shù)，根據(jù)上述監(jiān)控輸出指定具體的監(jiān)控項；
threshold：
°?默認為 25，代表 監(jiān)控閾值，監(jiān)控參數(shù)超過閾值，則滿足觸發(fā)條件；
°?監(jiān)控參數(shù)的值非數(shù)字時，需要配合 match 參數(shù)一起使用，如 processlist 的 state 列；
cycles：
°?默認為 5，表示連續(xù)觀察到五次滿足觸發(fā)條件時，才觸發(fā)收集；
連接參數(shù)：host、password、port、socket。
其他一些重要參數(shù)：
iterations：該參數(shù)指定 pt-stalk 在觸發(fā)收集幾次后退出，默認會一直運行。
run-time：觸發(fā)收集后，該參數(shù)指定收集多長時間的數(shù)據(jù)，默認 30 秒。
sleep：該參數(shù)指定在觸發(fā)收集后，sleep 多久后繼續(xù)監(jiān)控，默認 300 秒。
interval：指定狀態(tài)參數(shù)的檢查頻率，判斷是否需要觸發(fā)收集，默認 1 秒。
dest：監(jiān)控數(shù)據(jù)存放路徑，默認為 /var/lib/pt-stalk。
retention-time ：監(jiān)控數(shù)據(jù)保留時長，默認 30 天。
daemonize：以后臺服務運行，默認不開啟。
log：后臺運行日志，默認為 /var/log/pt-stalk.log。
collect：觸發(fā)發(fā)生時收集診斷數(shù)據(jù)，默認開啟。
°?collect-gdb：收集 GDB 堆棧跟蹤，需要 gdb 工具。
°?collect-strace：收集跟蹤數(shù)據(jù)，需要 strace 工具。
°?collect-tcpdump：收集 tcpdump 數(shù)據(jù)，需要 tcpdump 工具。
用 pt-table-checksum 時，會不會影響業(yè)務性能？
實驗
實驗開始前，給大家分享一個小經驗：任何性能評估，不要相信別人的評測結果，要在自己的環(huán)境上測試，并（大概）知曉原理。
我們先建一對主從：
然后用 mysqlslap跑一個持續(xù)的壓力：
開另外一個會話，將 master 上的 general log 打開：
然后通過 pt-table-checksum 進行一次比較：
查看 master 的 general log，由于 mysqlslap 的影響，general log 中有很多內容，我們找到與 pt-table-checksum 相關的線程：
將該線程的操作單獨列出來：
操作比較多，我們一點一點來說明：
這里工具調小了 innodb 鎖等待時間。使得之后的操作，只要在 innodb 上稍微有鎖等待，就會馬上放棄操作，對業(yè)務影響很小。
另外工具調小了 wait_timeout 時間，倒是沒有特別的作用。
工具將隔離級別調整為了 RR 級別，事務的維護代價會比 RC 要高，不過后面我們會看到工具使用的每個事務都很小，加上之前提到 innodb 鎖等待時間調到很小，對線上業(yè)務產生的成本比較小。
RR 級別是數(shù)據(jù)對比的基本要求。
工具通過一系列操作，了解表的概況。工具是一個數(shù)據(jù)塊一個數(shù)據(jù)塊進行校驗，這里獲取了第一個數(shù)據(jù)塊的下邊界。
接下來工具獲取了下一個數(shù)據(jù)塊的下邊界，每個 SQL前都會 EXPLAIN 一下，看一下執(zhí)行成本，非常小心翼翼。
之后工具獲取了一個數(shù)據(jù)塊的 checksum，這個數(shù)據(jù)塊不大，如果跟業(yè)務流量有沖突，會馬上出發(fā) innodb 的鎖超時，立刻退讓。
以上是 pt-table-checksum 的一些設計，可以看到這幾處都是精心維護了業(yè)務流量不受影響。
工具還設計了其他的一些機制保障業(yè)務流量，比如參數(shù) --max-load 和 --pause-file 等，還有精心設計的數(shù)據(jù)塊劃分方法，索引選擇方法等。大家根據(jù)自己的情況配合使用即可達到很好的效果。
總結
本期我們介紹了簡單分析 pt-table-checksum 是否會影響業(yè)務流量，坊間會流傳工具的各種參數(shù)建議或者不建議使用，算命的情況比較多，大家都可以用簡單的實驗來分析其中機制。
還是那個觀點，性能測試不能相信道聽途說，得通過實驗去分析。
本期我們用 MySQL 提供的 DBUG 工具來研究 MySQL 的 SQL 處理流程。
起手先造個實例
這里得稍微改一下實例的啟動文件 start，將 CUSTOM_MYSQLD 改為 mysqld-debug：
重啟一下實例，加上 debug 參數(shù)：
我們來做一兩個實驗，說明 DBUG 包的作用：
先設置一個簡單的調試規(guī)則，我們設置了兩個調試選項：
d：開啟各個調試點的輸出
O,/tmp/mysqld.trace：將調試結果輸出到指定文件
請點擊輸入圖片描述
然后我們創(chuàng)建了一張表，來看一下調試的輸出結果：
請點擊輸入圖片描述
可以看到 create table 的過程中，MySQL 的一些細節(jié)操作，比如分配內存 alloc_root 等
這樣看還不夠直觀，我們增加一些信息：
請點擊輸入圖片描述
來看看效果：
請點擊輸入圖片描述
可以看到輸出變成了調用樹的形式，現(xiàn)在就可以分辨出 alloc_root 分配的內存，是為了解析 SQL 時用的（mysql_parse）
我們再增加一些有用的信息：
請點擊輸入圖片描述
可以看到結果中增加了文件名和行號：
請點擊輸入圖片描述
現(xiàn)在我們可以在輸出中找一下統(tǒng)計表相關的信息：
請點擊輸入圖片描述
可以看到 MySQL 在這里非常機智，直接執(zhí)行了一個內置的存儲過程來更新統(tǒng)計表。
沿著 que_eval_sql，可以找到其他類似的統(tǒng)計表，比如下面這些：
請點擊輸入圖片描述
請點擊輸入圖片描述
本次實驗中，我們借助了 MySQL 的 DBUG 包，來讓 MySQL 將處理過程暴露出來。MySQL 中類似的技術還有不少，比如 performance_schema，OPTIMIZER_TRACE 等等。
這些技術將 MySQL 的不同方向的信息暴露出來，方便大家理解其中機制。
重慶分公司
重慶分公司
