原文:
mysql sys cpu高的案例分析（二）
後面又做了補充測試，增加了每秒context switch的監控，以及sql執行時各步驟消耗時間的監控。
【測試現象一】
啟用1000個併發執行緒的壓測程式，保持壓測程式持續執行，保持innodb_spin_wait_delay預設值不變
在10:17:14秒將innodb_spin_wait_delay值從預設值6調整為18，看到sys從40%降到20%
tps從1.7w增加到2w
context switch從82w降到78w
【測試現象二】
開啟sql執行時各步驟消耗時間的監控，重點關注stage/sql/update步驟的時間消耗(timer_wait的單位是picoseconds)，下面是擷取了每個場景下執行接近平均時間的sql過程取樣。
1、下圖是單句insert執行時情況，stage/sql/update時間約0.077豪秒
2、下圖是innodb_spin_wait_delay=6時，tps約在1.7w時insert執行時情況，stage/sql/update時間約32毫秒
3、下圖是innodb_spin_wait_delay=18時，tps約在2w時insert執行時情況，stage/sql/update時間約1.5毫秒
【測試結論】
1 、關於加大spin_wait_delay的理解，增大spin_wait_delay會讓執行緒在進入os wait之前再多spin一段時間，增加時間會增加獲取到rw-lock的概率，減少cpu空轉的次數，當spin wait的迴圈次數在1-30之間獲取到rw-lock時，則不會進入os wait，這種情況下減少了context switch的次數。從而減少了sys cpu的消耗，表現出來的現象是sql執行時間變短，tps處理能力上公升。
2、innodb_spin_wait_delay的單位，是100mhz的奔騰處理器處理1毫秒的時間，預設innodb_spin_wait_delay配置成6，表示最多在100mhz的奔騰處理器上自旋6毫秒。
現在cpu是按照ghz來計算的(測試是基於intel(r) xeon(r) cpu e5-2630 v4 @ 2.20ghz 40核的cpu處理器)，預設值相對變的很短，建議可以將這個配置值適當調大。
3、mysql高併發寫入出現瓶頸，確實不像sql server的latch等待型別那麼明顯。我們需要結合tps、cpu、io、執行程序等情況來綜合定位。
mysql cpu使用高案例處理
今天得監控總是在報警，cpu使用高，登入到伺服器上看了下使用者cpu確實挺高，登入到mysql中看了下，沒什麼高的併發使用者，也沒有什麼慢的sql，拿到一條頻繁執行的sql看了下，40多萬的記錄，全表掃，雖然執行的挺快，但是這種還是挺耗費資源的，就在字段上加了索引，但是這個欄位是longtext，只...
mysql cpu飆高的處理案例2
被告知乙個現場的mysql伺服器cpu 100 了需要處理下，然後就接手了。說下處理過程。是一台windows機器，作業系統server 2008，cpu 4個物理核心，偏少。國際慣例，先檢查各項指標，show engine innodb status 檢視一下庫總體狀態，發現log sequenc...
php redis解決高併發案例
本指令碼依賴 php redis擴充套件，請自行安裝 商品 class good public function get string name throw new exception method not exists name todo implement get method.增加庫存 par...