13518219792
捕獲診斷數據（ ）
創新互聯是專業的南京網站建設公司，南京接單;提供做網站、成都網站制作,網頁設計,網站設計,建網站,PHP網站建設等專業做網站服務;采用PHP框架,可快速的進行南京網站開發網頁制作和功能擴展;專業做搜索引擎喜愛的網站,專業的做網站團隊,希望更多企業前來合作!
堆棧需要自下而上來看 也就是說 線程當前正在執行的是pthread_cond_wait 函數 這是由os_event_wait_low 調用的 繼續往下 看起來是線程試圖進入到InnoDB 內核（srv_conc_enter_innodb） 但被放入了一個內部隊列中（os_event_wait_low） 原因應該是內核中的線程數已經超過innodb_thread_concurrency 的限制 當然 要真正地發揮堆棧跟蹤的價值需要將很多的信息聚合在一起來看 這種技術是由Domas Mituzas推廣的 他以前是MySQL 的支持工程師 開發了著名的窮人剖析器 poor man sprofiler 他目前在Facebook 工作 和其他人一起開發了更多的收集和分析堆棧跟蹤的工具 可以從他的這個網站發現更多的信息 // poormansprofiler
在Percona Toolkit 中我們也開發了一個類似的窮人剖析器 叫做pt pmp 這是一個用shell 和awk 腳本編寫的工具 可以將類似的堆棧跟蹤輸出合并到一起 然后通過sort|uniq|sort 將最常見的條目在最前面輸出 下面是一個堆棧跟蹤的完整例子 通過此工具將重要的信息展示了出來 使用了 l 選項指定了堆棧跟蹤不超過 層 以免因太多前面部分相同而后面部分不同的跟蹤信息而導致無法聚合到一起的情況 這樣才能更好地顯示到底在哪里產生了等待
$ pt pmp l stacktraces txt
pthread_cond_wait one_thread_per_connection_end handle_one_connection
start_thread clone
pthread_cond_wait os_event_wait_low srv_conc_enter_innodb
innodb_srv_conc_enter_innodb ha_innodb::index_read
pthread_cond_wait os_event_wait_low sync_array_wait_event mutex_spin_wait
mutex_enter_func
pthread_cond_wait os_event_wait_low os_aio_simulated_handle fil_aio_wait
io_handler_thread
pthread_cond_wait os_event_wait_low srv_conc_enter_innodb
innodb_srv_conc_enter_innodb ha_innodb::general_fetch
pthread_cond_wait os_event_wait_low sync_array_wait_event rw_lock_s_lock_spin
rw_lock_s_lock_func
sigwait signal_hand start_thread clone ??
select os_thread_sleep srv_lock_timeout_and_monitor_thread start_thread clone
select os_thread_sleep srv_error_monitor_thread start_thread clone
select handle_connections_sockets main
read vio_read_buff ::?? my_net_read cli_safe_read
pthread_cond_wait os_event_wait_low sync_array_wait_event rw_lock_x_lock_low
rw_lock_x_lock_func
pthread_cond_wait MYSQL_BIN_LOG::wait_for_update mysql_binlog_send
dispatch_mand do_mand
fsync os_file_fsync os_file_flush fil_flush log_write_up_to
第一行是MySQL 中非常典型的空閑線程的一種特征 所以可以忽略 第二行才是最有意思的地方 看起來大量的線程正在準備進入到InnoDB 內核中 但都被阻塞了 從第三行則可以看到許多線程都在等待某些互斥鎖 但具體的是什么鎖不清楚 因為堆棧跟蹤更深的層次被截斷了 如果需要確切地知道是什么互斥鎖 則需要使用更大的 l 選項重跑一次 一般來說 這個堆棧跟蹤顯示很多線程都在等待進入到InnoDB 這是為什么呢？這個工具并不清楚 需要從其他的地方來入手
從前面的堆棧跟蹤和oprofile 報表來看 如果不是MySQL 和InnoDB 源碼方面的專家 這種類型的分析很難進行 如果用戶在進行此類分析時碰到問題 通常需要求助于這樣的專家才行
在下面的例子中 通過剖析和等待分析都無法發現服務器的問題 需要使用另外一種不同的診斷技術
返回目錄 高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
lishixinzhi/Article/program/MySQL/201311/29698
一個診斷案例（ ）
我們看到了兩種可能性 要么是數據庫導致了I/O（如果能找到源頭的話 那么可能就找到了問題的原因） 要么不是數據庫導致了所有的I/O 而是其他什么導致的 而系統因為缺少I/O 資源影響了數據庫性能 我們也很小心地盡力避免引入另外一個隱式的假設 磁盤很忙并不一定意味著MySQL 會有問題 要記住 這個服務器主要的壓力是內存讀取 所以也很可能出現磁盤長時間無法響應但沒有造成嚴重問題的現象
如果你一直跟隨我們的推理邏輯 就可以發現還需要回頭檢查一下另外一個假設 我們已經知道磁盤設備很忙 因為其等待時間很高 對于固態硬盤來說 其I/O 平均等待時間一般不會超過 / 秒 實際上 從iostat 的輸出結果也可以發現磁盤本身的響應還是很快的 但請求在塊設備隊列中等待很長的時間才能進入到磁盤設備 但要記住 這只是iostat 的輸出結果 也可能是錯誤的信息
究竟是什么導致了性能低下？
當一個資源變得效率低下時 應該了解一下為什么會這樣 有如下可能的原因
資源被過度使用 余量已經不足以正常工作
資源沒有被正確配置
資源已經損壞或者失靈
回到上面的例子中 iostat 的輸出顯示可能是磁盤的工作負載太大 也可能是配置不正確（在磁盤響應很快的情況下 為什么I/O 請求需要排隊這么長時間才能進入到磁盤？） 然而 比較系統的需求和現有容量對于確定問題在哪里是很重要的一部分 大量的基準測試證明這個客戶使用的這種SSD 是無法支撐幾百MB/s 的寫操作的 所以 盡管iostat 的結果表明磁盤的響應是正常的 也不一定是完全正確的 在這個案例中 我們沒有辦法證明磁盤的響應比iostat 的結果中所說的要慢 但這種情況還是有可能的 所以這不能改變我們的看法 可能是磁盤被濫用注 或者是錯誤的配置 或者兩者兼而有之 是性能低下的罪魁禍首
在檢查過所有診斷數據之后 接下來的任務就很明顯了 測量出什么導致了I/O 消耗 不幸的是 客戶當前使用的GNU/Linux 版本對此的支持不力 通過一些工作我們可以做一些相對準確的猜測 但首先還是需要探索一下其他的可能性 我們可以測量有多少I/O來自MySQL 但客戶使用的MySQL 版本較低以致缺乏一些診斷功能 所以也無法提供確切有利的支持
作為替代 基于我們已經知道MySQL 如何使用磁盤 我們來觀察MySQL 的I/O 情況 通常來說 MySQL 只會寫數據 日志 排序文件和臨時表到磁盤 從前面的狀態計數器和其他信息來看 首先可以排除數據和日志的寫入問題 那么 只能假設MySQL 突然寫入大量數據到臨時表或者排序文件 如何來觀察這種情況呢？有兩個簡單的方法 一是觀察磁盤的可用空間 二是通過lsof 命令觀察服務器打開的文件句柄 這兩個方法我們都采用了 結果也足以滿足我們的需求 下面是問題期間每秒運行df–h 的結果
下面則是lsof 的數據 因為某些原因我們每五秒才收集一次 我們簡單地將mysqld 在/tmp 中打開的文件大小做了加總 并且把總大小和采樣時的時間戳一起輸出到結果文件中
$ awk
/mysqld *tmp/ {
total += $ ;
}
/^Sun Mar / total {
printf %s % f MB\n $ total/ / ;
total = ;
} lsof txt
: : MB
: : MB
: : MB
: : MB
: : MB
從這個數據可以看出 在問題之初MySQL 大約寫了 GB 的數據到臨時表 這和之前在SHOW PROCESSLIST 中有大量的 Copying to tmp table 相吻合 這個證據表明可能是某些效率低下的查詢風暴耗盡了磁盤資源 根據我們的工作直覺 出現這種情況比較普遍的一個原因是緩存失效 當memcached 中所有緩存的條目同時失效 而又有很多應用需要同時訪問的時候 就會出現這種情況 我們給開發人員出示了部分采樣到的查詢 并討論這些查詢的作用 實際情況是 緩存同時失效就是罪魁禍首（這驗證了我們的直覺） 一方面開發人員在應用層面解決緩存失效的問題 另一方面我們也修改了查詢 避免使用磁盤臨時表 這兩個方法的任何一個都可以解決問題 當然最好是兩個都實施
返回目錄 高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
lishixinzhi/Article/program/MySQL/201311/29695
測試何種指標
在開始執行甚至是在設計基準測試之前 需要先明確測試的目標 測試目標決定了選擇什么樣的測試工具和技術 以獲得精確而有意義的測試結果 可以將測試目標細化為一系列的問題 比如 這種CPU 是否比另外一種要快？ 或 新索引是否比當前索引性能更好？
有時候需要用不同的方法測試不同的指標 比如 針對延遲（latency）和吞吐量（throughput）就需要采用不同的測試方法
請考慮以下指標 看看如何滿足測試的需求
吞吐量
吞吐量指的是單位時間內的事務處理數 這一直是經典的數據庫應用測試指標 一些標準的基準測試被廣泛地引用 如TPC C（參考// tpc ） 而且很多數據庫廠商都努力爭取在這些測試中取得好成績 這類基準測試主要針對在線事務處理（OLTP）的吞吐量 非常適用于多用戶的交互式應用 常用的測試單位是每秒事務數（TPS） 有些也采用每分鐘事務數（TPM）
響應時間或者延遲
這個指標用于測試任務所需的整體時間 根據具體的應用 測試的時間單位可能是微秒 毫秒 秒或者分鐘 根據不同的時間單位可以計算出平均響應時間 最小響應時間 最大響應時間和所占百分比 最大響應時間通常意義不大 因為測試時間越長 最大響應時間也可能越大 而且其結果通常不可重復 每次測試都可能得到不同的最大響應時間 因此 通常可以使用百分比響應時間（percentile responsetime）來替代最大響應時間 例如 如果 % 的響應時間都是 毫秒 則表示任務在 % 的時間段內都可以在 毫秒之內完成
使用圖表有助于理解測試結果 可以將測試結果繪制成折線圖（比如平均值折線或者 % 百分比折線）或者散點圖 直觀地表現數據結果集的分布情況 通過這些圖可以發現長時間測試的趨勢 本章后面將更詳細地討論這一點
并發性
并發性是一個非常重要又經常被誤解和誤用的指標 例如 它經常被表示成多少用戶在同一時間瀏覽一個Web 站點 經常使用的指標是有多少個會話注 然而 HTTP協議是無狀態的 大多數用戶只是簡單地讀取瀏覽器上顯示的信息 這并不等同于Web 服務器的并發性 而且 Web 服務器的并發性也不等同于數據庫的并發性 而僅僅只表示會話存儲機制可以處理多少數據的能力 Web 服務器的并發性更準確的度量指標 應該是在任意時間有多少同時發生的并發請求
在應用的不同環節都可以測量相應的并發性 Web 服務器的高并發 一般也會導致數據庫的高并發 但服務器采用的語言和工具集對此都會有影響 注意不要將創建數據庫連接和并發性搞混淆 一個設計良好的應用 同時可以打開成百上千個MySQL 數據庫服務器連接 但可能同時只有少數連接在執行查詢 所以說 一個Web 站點 同時有 個用戶 訪問 卻可能只有 ～ 個并發請求到MySQL 數據庫
換句話說 并發性基準測試需要關注的是正在工作中的并發操作 或者是同時工作中的線程數或者連接數 當并發性增加時 需要測量吞吐量是否下降 響應時間是否變長 如果是這樣 應用可能就無法處理峰值壓力
并發性的測量完全不同于響應時間和吞吐量 它不像是一個結果 而更像是設置基準測試的一種屬性 并發性測試通常不是為了測試應用能達到的并發度 而是為了測試應用在不同并發下的性能 當然 數據庫的并發性還是需要測量的 可以通過sy *** ench 指定 或者 個線程的測試 然后在測試期間記錄MySQL 數據庫的Threads_running 狀態值 在第 章將討論這個指標對容量規劃的影響
可擴展性
在系統的業務壓力可能發生變化的情況下 測試可擴展性就非常必要了 第 章將更進一步討論可擴展性的話題 簡單地說 可擴展性指的是 給系統增加一倍的工作 在理想情況下就能獲得兩倍的結果（即吞吐量增加一倍） 或者說 給系統增加一倍的資源（比如兩倍的CPU 數） 就可以獲得兩倍的吞吐量 當然 同時性能（響應時間）也必須在可以接受的范圍內 大多數系統是無法做到如此理想的線性擴展的 隨著壓力的變化 吞吐量和性能都可能越來越差
可擴展性指標對于容量規范非常有用 它可以提供其他測試無法提供的信息 來幫助發現應用的瓶頸 比如 如果系統是基于單個用戶的響應時間測試（這是一個很糟糕的測試策略）設計的 雖然測試的結果很好 但當并發度增加時 系統的性能有可能變得非常糟糕 而一個基于不斷增加用戶連接的情況下的響應時間測試則可以發現這個問題
一些任務 比如從細粒度數據創建匯總表的批量工作 需要的是周期性的快速響應時間 當然也可以測試這些任務純粹的響應時間 但要注意考慮這些任務之間的相互影響 批量工作可能導致相互之間有影響的查詢性能變差 反之亦然
歸根結底 應該測試那些對用戶來說最重要的指標 因此應該盡可能地去收集一些需求 比如 什么樣的響應時間是可以接受的 期待多少的并發性 等等 然后基于這些需求來設計基準測試 避免目光短淺地只關注部分指標 而忽略其他指標
返回目錄 高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
lishixinzhi/Article/program/MySQL/201311/29741
字符串類型（ ）
MySQL 支持多種字符串類型 每種類型還有很多變種 這些數據類型在 和 版本發生了很大的變化 使得情況更加復雜 從MySQL 開始 每個字符串列可以定義自己的字符集和排序規則 或者說校對規則（collation）（更多關于這個主題的信息請參考第 章） 這些東西會很大程度上影響性能
VARCHAR 和CHAR 類型
VARCHAR 和CHAR 是兩種最主要的字符串類型 不幸的是 很難精確地解釋這些值是怎么存儲在磁盤和內存中的 因為這跟存儲引擎的具體實現有關 下面的描述假設使用的存儲引擎是InnoDB 和/ 或者MyISAM 如果使用的不是這兩種存儲引擎 請參考所使用的存儲引擎的文檔
先看看VARCHAR 和CHAR 值通常在磁盤上怎么存儲 請注意 存儲引擎存儲CHAR 或者VARCHAR 值的方式在內存中和在磁盤上可能不一樣 所以MySQL 服務器從存儲引擎讀出的值可能需要轉換為另一種存儲格式 下面是關于兩種類型的一些比較
VARCHAR
VARCHAR 類型用于存儲可變長字符串 是最常見的字符串數據類型 它比定長類型更節省空間 因為它僅使用必要的空間（例如 越短的字符串使用越少的空間） 有一種情況例外 如果MySQL 表使用ROW_FORMAT=FIXED 創建的話 每一行都會使用定長存儲 這會很浪費空間
VARCHAR 需要使用 或 個額外字節記錄字符串的長度 如果列的最大長度小于或等于 字節 則只使用 個字節表示 否則使用 個字節 假設采用latin 字符集 一個VARCHAR（ ） 的列需要 個字節的存儲空間 VARCHAR（ ） 的列則需要 個字節 因為需要 個字節存儲長度信息
VARCHAR 節省了存儲空間 所以對性能也有幫助 但是 由于行是變長的 在UPDATE 時可能使行變得比原來更長 這就導致需要做額外的工作 如果一個行占用的空間增長 并且在頁內沒有更多的空間可以存儲 在這種情況下 不同的存儲引擎的處理方式是不一樣的 例如 MyISAM 會將行拆成不同的片段存儲 InnoDB則需要分裂頁來使行可以放進頁內 其他一些存儲引擎也許從不在原數據位置更新數據
下面這些情況下使用VARCHAR 是合適的 字符串列的最大長度比平均長度大很多 列的更新很少 所以碎片不是問題 使用了像UTF 這樣復雜的字符集 每個字符都使用不同的字節數進行存儲
在 或者更高版本 MySQL 在存儲和檢索時會保留末尾空格 但在 或更老的版本 MySQL 會剔除末尾空格
InnoDB 則更靈活 它可以把過長的VARCHAR 存儲為BLOB 我們稍后討論這個問題
CHAR
CHAR 類型是定長的 MySQL 總是根據定義的字符串長度分配足夠的空間 當存儲CHAR 值時 MySQL 會刪除所有的末尾空格（在MySQL 和更老版本中VARCHAR也是這樣實現的 也就是說這些版本中CHAR 和VARCHAR 在邏輯上是一樣的 區別只是在存儲格式上） CHAR 值會根據需要采用空格進行填充以方便比較
CHAR 適合存儲很短的字符串 或者所有值都接近同一個長度 例如 CHAR 非常適合存儲密碼的MD 值 因為這是一個定長的值 對于經常變更的數據 CHAR 也比VARCHAR 更好 因為定長的CHAR 類型不容易產生碎片 對于非常短的列 CHAR 比VARCHAR 在存儲空間上也更有效率 例如用CHAR（ ） 來存儲只有Y 和N 的值 如果采用單字節字符集注 只需要一個字節 但是VARCHAR（ ） 卻需要兩個字節 因為還有一個記錄長度的額外字節
CHAR 類型的這些行為可能有一點難以理解 下面通過一個具體的例子來說明 首先 我們創建一張只有一個CHAR（ ） 字段的表并且往里面插入一些值
當檢索這些值的時候 會發現string 末尾的空格被截斷了
如果用VARCHAR（ ） 字段存儲相同的值 可以得到如下結果
數據如何存儲取決于存儲引擎 并非所有的存儲引擎都會按照相同的方式處理定長和變長的字符串 Memory 引擎只支持定長的行 即使有變長字段也會根據最大長度分配最大空間 不過 填充和截取空格的行為在不同存儲引擎都是一樣的 因為這是在MySQL 服務器層進行處理的
返回目錄 高性能MySQL
編輯推薦
ASP NET MVC 框架揭秘
Oracle索引技術
ASP NET開發培訓視頻教程
lishixinzhi/Article/program/MySQL/201311/29687
