sysbench壓測mysql性能調(diào)優(yōu)案例分享

      網(wǎng)友投稿 1735 2022-05-29

      1 問題背景

      使用sysbench對mysql5.7.21進行256并發(fā)壓測時,調(diào)優(yōu)前在Kunpeng920壓測TPS為4197,與理想數(shù)據(jù)有較大差距。

      2 原因分析

      2.1 Top命令查看cpu資源使用情況

      執(zhí)行命令進行壓測時發(fā)現(xiàn),top命令下mysql進程cpu使用率6000%左右,其中系統(tǒng)調(diào)用占用較高,為進一步明確mysql進程在執(zhí)行哪些過程,進行perf 熱點函數(shù)和火焰圖分析。

      2.2 perf命令查看熱點函數(shù)

      通過在壓測過程中執(zhí)行perf top命令,查看到相關(guān)函數(shù)調(diào)用較高:

      進一步明確分析函數(shù)調(diào)用棧關(guān)系,使用perf record命令抓取一段時間perf 數(shù)據(jù),進行解析后生成相應火焰圖(火焰圖生成過程可參考https://github.com/brendangregg/FlameGraph ):

      sysbench壓測mysql性能調(diào)優(yōu)案例分享

      分析發(fā)現(xiàn)mysql中調(diào)用的熱點函數(shù)MVCC::view_open和PolycyMutex_在底層調(diào)用的是spin_lock相關(guān)函數(shù),疑是大量線程都在進行自旋空轉(zhuǎn),消耗cpu資源。

      3 解決方案

      3.1 修改Mysql源碼中CacheLine(可選優(yōu)化項)

      通過github上mysql-5.7.21相關(guān)issue發(fā)現(xiàn),在mysql中存在對cacheLine的硬編碼現(xiàn)象,mysql中cachline大小是適配X86平臺的為64字節(jié),Kunpeng 920下cacheLine為128字節(jié)。可參考以下issue鏈接https://github.com/mysql/mysql-server/pull/66/files對mysql源碼進行修改,此措施可獲得相應的性能提升。

      Cacheline機制理解:

      CPU標識Cache中的數(shù)據(jù)是否為有效數(shù)據(jù)不是以內(nèi)存位寬為單位,而是以Cacheline為單位。這個機制可能會導致偽共享(false sharing)現(xiàn)象,從而使得CPU的Cache命中率變低。出現(xiàn)偽共享的常見原因是高頻訪問的數(shù)據(jù)未按照Cacheline大小對齊,而在高并發(fā)壓測mysql時,其中加鎖的全局變量或數(shù)據(jù)一般是在高頻的訪問,這就可能導致性能的下降。(對于高頻訪問的鎖變量,實際是對鎖變量進行高頻的讀寫操作,容易發(fā)生偽共享問題)

      3.2 修改mysql數(shù)據(jù)庫配置參數(shù)

      Mysql中影響spin_lock相關(guān)性能參數(shù)的主要有:innodb_thread_concurrency、innodb_spin_wait_delay、innodb_sync_spin_loops。其中nnodb_thread_concurrency控制并發(fā)的線程數(shù),推薦設置為cpu的核心數(shù)。通過上調(diào)innodb_spin_wait_delay和innodb_sync_spin_loops參數(shù),同時使用perf top命令觀測MVCC::view_open和PolycyMutex_熱點函數(shù)使用率,當使用率下降到合理范圍內(nèi)時,即達到預期效果。

      由于原子操作在x86和kunpeng 920平臺上的實現(xiàn)存在差異,加上kunpeng920的核心數(shù)較多,導致在mysql高并發(fā)壓測時出現(xiàn)了spin_lock相關(guān)系統(tǒng)調(diào)用較高,通過相應的mysql參數(shù)優(yōu)化即可實現(xiàn)性能提升,結(jié)合Mysql下相關(guān)自旋鎖的代碼實現(xiàn),可更好的理解這幾個參數(shù)的作用,參考鏈接如下:

      https://blog.csdn.net/sun_ashe/article/details/81291347

      通過對mysql的相關(guān)優(yōu)化,最終在256并發(fā)下,kunpeng 920上TPS達到了11700,達到并超過了預期的TPS值。

      4 總結(jié)

      遇到性能問題時,首先需要對比查看各項系統(tǒng)參數(shù)是否異常。對于cpu占用較高時,需要善于應用perf工具進行熱點函數(shù)分析,逐一進行排查。

      MySQL 應用性能調(diào)優(yōu) SQL 數(shù)據(jù)庫

      版權(quán)聲明:本文內(nèi)容由網(wǎng)絡用戶投稿,版權(quán)歸原作者所有,本站不擁有其著作權(quán),亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容,請聯(lián)系我們jiasou666@gmail.com 處理,核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

      上一篇:VPC助力快速搭建云上網(wǎng)絡
      下一篇:高并發(fā)編程-happens-before
      相關(guān)文章
      国产亚洲A∨片在线观看| 亚洲精品精华液一区二区| 九月婷婷亚洲综合在线| 亚洲国产欧美日韩精品一区二区三区 | 久久精品亚洲综合专区| 国产精品亚洲视频| 亚洲男人第一无码aⅴ网站| 亚洲精品亚洲人成在线观看下载| 亚洲高清最新av网站| 亚洲片一区二区三区| 亚洲国产精品自产在线播放| 亚洲成av人无码亚洲成av人| 亚洲欧好州第一的日产suv| 国产亚洲精品AAAA片APP | 亚洲日韩中文字幕无码一区| 一本天堂ⅴ无码亚洲道久久| 亚洲午夜成人精品无码色欲| 亚洲国产精品无码中文lv| 九九精品国产亚洲AV日韩| 亚洲国产精品专区在线观看| 国产精品V亚洲精品V日韩精品 | 亚洲乱亚洲乱妇无码麻豆| 亚洲精品蜜桃久久久久久| 亚洲AV无码欧洲AV无码网站| 亚洲视频2020| 亚洲国产成人精品无码区在线秒播| 亚洲天堂中文字幕在线观看| 亚洲gv白嫩小受在线观看| 亚洲黄色在线观看| 亚洲乱码卡三乱码新区| 亚洲欧洲无卡二区视頻| 国产亚洲视频在线| 狠狠亚洲狠狠欧洲2019| 亚洲av无码一区二区三区网站| 亚洲综合自拍成人| 亚洲乱码一二三四区乱码| 亚洲av无码兔费综合| 亚洲人成网站在线观看青青| 亚洲VA中文字幕无码一二三区 | 亚洲国产成人资源在线软件| 中文字幕精品三区无码亚洲|