欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

分享MySQL生產(chǎn)庫內(nèi)存異常增高的排查過程

 更新時間：2022年04月10日 20:10:35   作者：那海藍藍  
這篇文章主要介紹了分享MySQL生產(chǎn)庫內(nèi)存異常增高的排查過程，基于MySQL實例的內(nèi)存使用率高的報警的問題展開對主題的問題，具有一定的參考價值，需要的小伙伴可以參考一下

    近期頻繁收到一個MySQL實例的內(nèi)存使用率高的報警，今天我們花時間排查一下問題出在哪里。

修改performance_schema

因為公司生產(chǎn)環(huán)境使用的阿里云RDS，修改參數(shù)相對方便，performance_schema默認為0，此次修改為1。修改之后提交參數(shù)，數(shù)據(jù)庫會進行重啟，建議在業(yè)務(wù)低峰進行。

打開內(nèi)存監(jiān)控

登錄MySQL數(shù)據(jù)庫，執(zhí)行如下SQL，打開內(nèi)存監(jiān)控。

update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';

打開之后驗證一下。

select * from performance_schema.setup_instruments where name like 'memory%innodb%' limit 5;

**注意：**該命令是在線打開內(nèi)存統(tǒng)計，所以只會統(tǒng)計打開后新增的內(nèi)存對象，打開前的內(nèi)存對象不會統(tǒng)計，建議您打開后等待一段時間再執(zhí)行后續(xù)步驟，便于找出內(nèi)存使用高的線程。

查找內(nèi)存消耗

統(tǒng)計事件消耗內(nèi)存

select event_name,
       SUM_NUMBER_OF_BYTES_ALLOC
from performance_schema.memory_summary_global_by_event_name
order by SUM_NUMBER_OF_BYTES_ALLOC desc
LIMIT 10;
+---------------------------------------+-------------------------------------+
| event_name                            | SUM_NUMBER_OF_BYTES_ALLOC           |
+---------------------------------------+-------------------------------------+
| memory/sql/Filesort_buffer::sort_keys | 763523904056                        |
| memory/memory/HP_PTRS                 | 118017336096                        |
| memory/sql/thd::main_mem_root         | 114026214600                        |
| memory/mysys/IO_CACHE                 | 59723548888                         |
| memory/sql/QUICK_RANGE_SELECT::alloc  | 14381459680                         |
| memory/sql/test_quick_select          | 12859304736                         |
| memory/innodb/mem0mem                 | 7607681148                          |
| memory/sql/String::value              | 1405409537                          |
| memory/sql/TABLE                      | 1117918354                          |
| memory/innodb/btr0sea                 | 984013872                           |
+---------------------------------------+-------------------------------------+

可以看到內(nèi)存消耗最高的event是Filesort_buffer，根據(jù)經(jīng)驗，這個應(yīng)該是排序有關(guān)。

統(tǒng)計線程消耗內(nèi)存

select thread_id,
       event_name,
       SUM_NUMBER_OF_BYTES_ALLOC
from performance_schema.memory_summary_by_thread_by_event_name
order by SUM_NUMBER_OF_BYTES_ALLOC desc
limit 10;
+---------------------+---------------------------------------+-------------------------------------+
| thread_id           | event_name                            | SUM_NUMBER_OF_BYTES_ALLOC           |
+---------------------+---------------------------------------+-------------------------------------+
| 105                 | memory/memory/HP_PTRS                 | 69680198792                         |
| 183                 | memory/sql/Filesort_buffer::sort_keys | 49210098808                         |
| 154                 | memory/sql/Filesort_buffer::sort_keys | 43304339072                         |
| 217                 | memory/sql/Filesort_buffer::sort_keys | 37752275360                         |
| 2773                | memory/sql/Filesort_buffer::sort_keys | 31460644712                         |
| 218                 | memory/sql/Filesort_buffer::sort_keys | 31128994280                         |
| 2331                | memory/sql/Filesort_buffer::sort_keys | 28763981248                         |
| 106                 | memory/memory/HP_PTRS                 | 27938197584                         |
| 191                 | memory/sql/Filesort_buffer::sort_keys | 27701610224                         |
| 179                 | memory/sql/Filesort_buffer::sort_keys | 25624723968                         |
+---------------------+---------------------------------------+-------------------------------------+

可以看到內(nèi)存消耗多的線程都跟Filesort_buffer相關(guān)。

定位具體SQL

根據(jù)前邊我們查到的thread_id去日志里查找對應(yīng)的SQL，阿里云RDS審計日志相對還是比較強大的。我們直接根據(jù)thread_id直接檢索。

記一次MySQL生產(chǎn)庫內(nèi)存異常增高的排查過程_MySQL

    我們在日志里看到大量這樣的SQL，掃描行數(shù)在幾千到幾萬不等。雖然每次查詢時間并不長，大概在幾十到幾百毫秒，但是并發(fā)量很大。
    跟開發(fā)同學(xué)核實之后，這個查詢沒有做分頁，取到的數(shù)據(jù)有很多行，而且最后要做排序，并且排序字段并沒有合適的索引。到此，這次內(nèi)存使用率出現(xiàn)異常的罪魁禍首已經(jīng)找到。

到此這篇關(guān)于分享MySQL生產(chǎn)庫內(nèi)存異常增高的排查過程的文章就介紹到這了,更多相關(guān)MySQL生產(chǎn)庫內(nèi)存異常增高內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

相關(guān)文章

  • MySQL在線開啟或禁用GTID模式

    MySQL在線開啟或禁用GTID模式

    本文詳細講解了MySQL在線開啟或禁用GTID模式的方法，文中通過示例代碼介紹的非常詳細。對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下
    2021-11-11
  • 教會你完全搞定MySQL數(shù)據(jù)庫 輕松八句話

    教會你完全搞定MySQL數(shù)據(jù)庫 輕松八句話

    只要掌握下面的方法，就基本上能搞定mysql數(shù)據(jù)庫。
    2010-09-09
  • MySQL中Decimal類型和Float Double的區(qū)別(詳解)

    MySQL中Decimal類型和Float Double的區(qū)別(詳解)

    下面小編就為大家?guī)硪黄狹ySQL中Decimal類型和Float Double的區(qū)別(詳解)。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧
    2017-03-03
  • SELECT?*?效率低原理解析

    SELECT?*?效率低原理解析

    這篇文章主要為大家介紹了SELECT?*?效率低原理解析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪
    2023-02-02
  • mysql存儲過程?返回?list結(jié)果集方式

    mysql存儲過程?返回?list結(jié)果集方式

    這篇文章主要介紹了mysql存儲過程?返回?list結(jié)果集方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教
    2022-09-09
  • mysql8.0.21下載安裝詳細教程

    mysql8.0.21下載安裝詳細教程

    這篇文章主要介紹了mysql8.0.21下載安裝詳細教程,本文通過圖文并茂的形式給大家介紹的非常詳細，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下
    2020-08-08
  • mysql id從1開始自增 快速解決id不連續(xù)的問題

    mysql id從1開始自增 快速解決id不連續(xù)的問題

    這篇文章主要介紹了mysql id從1開始自增 快速解決id不連續(xù)的問題，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教
    2021-07-07
  • 貌似很強的mysql備份策略分享

    貌似很強的mysql備份策略分享

    貌似很強的mysql備份策略，號稱天下無敵，哈哈，有需要的朋友參考下吧
    2013-02-02
  • Sql Server數(shù)據(jù)庫遠程連接訪問設(shè)置詳情

    Sql Server數(shù)據(jù)庫遠程連接訪問設(shè)置詳情

    這篇文章主要介紹了Sql Server數(shù)據(jù)庫遠程連接訪問設(shè)置詳情，文章圍繞主題展開詳細的內(nèi)容戒殺，具有一定的參考價值，需要的小伙伴可以參考一下
    2022-09-09
  • MySQL慢查詢優(yōu)化解決問題

    MySQL慢查詢優(yōu)化解決問題

    這篇文章主要介紹了MySQL慢查詢優(yōu)化解決問題，MySQL的慢查詢，全名是慢查詢?nèi)罩?，是MySQL提供的一種日志記錄，用來記錄在MySQL中響應(yīng)時間超過閥值的語句，下文詳細介紹慢查詢的調(diào)優(yōu)情況，需要的小伙伴可以參考一下
    2022-03-03

最新評論