亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

MySQL?8.0新功能監(jiān)控統(tǒng)計(jì)限制連接不再擔(dān)心被垃圾SQL搞爆內(nèi)存

 更新時(shí)間:2023年05月18日 09:36:51   作者:GreatSQL社區(qū)  
這篇文章主要介紹了MySQL?8.0新功能監(jiān)控統(tǒng)計(jì)限制連接不再擔(dān)心被垃圾SQL搞爆內(nèi)存詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪

MySQL 8.0.28引入新功能

MySQL 8.0.28開(kāi)始,新增一個(gè)特性,支持監(jiān)控統(tǒng)計(jì)限制各個(gè)連接(會(huì)話)的內(nèi)存消耗,避免大量用戶連接因?yàn)閳?zhí)行垃圾SQL消耗過(guò)多內(nèi)存,造成可能被OOM kill的風(fēng)險(xiǎn)。

首先,需要先設(shè)置系統(tǒng)選項(xiàng)

 global_connection_memory_tracking = 1,之后可以通過(guò)系統(tǒng)狀態(tài)變量 Global_connection_memory 查看當(dāng)前所有連接消耗的內(nèi)存總量:

mysql> show global status like 'Global_connection_memory';
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| Global_connection_memory | 1122912 |
+--------------------------+---------+

系統(tǒng)選項(xiàng) global_connection_memory_tracking 可以全局開(kāi)啟,也可以在單個(gè)會(huì)話中獨(dú)立開(kāi)啟。如果是全局開(kāi)啟,則會(huì)針對(duì)所有連接統(tǒng)計(jì)內(nèi)存消耗情況,包括系統(tǒng)內(nèi)部線程,以及root用戶創(chuàng)建的連接;

如果是單個(gè)會(huì)話中獨(dú)立開(kāi)啟,則只會(huì)統(tǒng)計(jì)當(dāng)前會(huì)話連接的內(nèi)存消耗。此外,InnoDB buffer pool不在統(tǒng)計(jì)范圍內(nèi)。

控制內(nèi)存統(tǒng)計(jì)更新頻率

可以通過(guò)設(shè)置選項(xiàng) connection_memory_chunk_size 來(lái)控制內(nèi)存統(tǒng)計(jì)更新頻率,該選項(xiàng)默認(rèn)值為8KB,也就是當(dāng)內(nèi)存使用變化超過(guò)8KB時(shí),才會(huì)更新統(tǒng)計(jì)結(jié)果。

可以調(diào)整每個(gè)會(huì)話連接可使用內(nèi)存上限,由選項(xiàng) connection_memory_limit 定義其限制,默認(rèn)值及最大值都是 18446744073709551615,這個(gè)默認(rèn)值太大了,等同于沒(méi)有限制。如果線上經(jīng)常運(yùn)行垃圾SQL導(dǎo)致MySQL內(nèi)存消耗過(guò)大的話,可以適當(dāng)調(diào)低這個(gè)選項(xiàng)。

如何在評(píng)估一條SQL可能要消耗多少內(nèi)存呢?

可以先調(diào)整選項(xiàng)值 connection_memory_limit = 2097152,即調(diào)低到2MB。然后以普通用戶身份(沒(méi)有SUPER、SYSTEM_VARIABLES_ADMIN、SESSION_VARIABLES_ADMIN等權(quán)限)執(zhí)行相應(yīng)的SQL,如果預(yù)估需要消耗的內(nèi)存超過(guò)2MB,則會(huì)發(fā)出類似下面的報(bào)錯(cuò),并且這個(gè)連接會(huì)被殺掉斷開(kāi):

mysql> select @@global.connection_memory_limit;
+----------------------------------+
| @@global.connection_memory_limit |
+----------------------------------+
|                          2097152 |
+----------------------------------+
mysql> select count(c) from t group by c;
ERROR 4082 (HY000): Connection closed. Connection memory limit 2097152 bytes exceeded. Consumed 7079568 bytes.

可以看到上述報(bào)錯(cuò)信息中提示這條SQL需要消耗約 7079568字節(jié) 的內(nèi)存。當(dāng)然了,實(shí)際上這條SQL需要消耗的內(nèi)存不止 7079568字節(jié),隨著我們細(xì)粒度逐步上調(diào) connection_memory_limit 選項(xiàng)值,最后會(huì)發(fā)現(xiàn)這條SQL需要消耗的內(nèi)存約為 13087952字節(jié)。

當(dāng)執(zhí)行完這條SQL后,我們?cè)俅尾樵儬顟B(tài)變量 Global_connection_memory,會(huì)發(fā)現(xiàn)它的值并沒(méi)這么大,說(shuō)明這條SQL執(zhí)行完畢后,相應(yīng)的內(nèi)存也立即釋放,只保留維持會(huì)話連接所需的基本內(nèi)存:

mysql> select count(c) from t group by c; show global status like 'Global_connection_memory'; show session status like 'Global_connection_memory';
+----------+
| count(c) |
+----------+
|        2 |
+----------+
1 row in set (0.04 sec)
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| Global_connection_memory | 2193153 |
+--------------------------+---------+
1 row in set (0.00 sec)

前面提到一點(diǎn),只有普通用戶執(zhí)行SQL才會(huì)受到內(nèi)存使用上限約束,如果是用root用戶執(zhí)行同一條SQL,則不受限制:

mysql> select user();
+----------------+
| user()         |
+----------------+
| root@localhost |
+----------------+
1 row in set (0.00 sec)
mysql> select @@global.connection_memory_limit;
+----------------------------------+
| @@global.connection_memory_limit |
+----------------------------------+
|                          2097152 |
+----------------------------------+
1 row in set (0.00 sec)
mysql> select count(c) from t group by c;
+----------+
| count(c) |
+----------+
|        2 |
+----------+
1 row in set (0.05 sec)

避免被OOM kill

所以不能頻繁用root等具備SUPER權(quán)限的用戶執(zhí)行需要大內(nèi)存的SQL,避免被OOM kill。

另外,選項(xiàng) connection_memory_chunk_size 如果設(shè)置太小,則會(huì)頻繁更新內(nèi)存統(tǒng)計(jì),對(duì)系統(tǒng)性能也會(huì)有影響;但也不建議設(shè)置太大,否則可能因?yàn)楦虏患皶r(shí)而引發(fā)OOM問(wèn)題,大部分情況下采用默認(rèn)值即可。

綜上,假設(shè)有個(gè)服務(wù)器物理內(nèi)存是96GB,建議考慮做如下分配:

選項(xiàng)設(shè)置值
innodb_buffer_pool_size64G
global_connection_memory_limit12G
connection_memory_chunk_size8192
connection_memory_limit96M
global_connection_memory_trackingON

在上述規(guī)劃中,設(shè)置了每個(gè)會(huì)話中,普通用戶執(zhí)行的SQL消耗內(nèi)存不能超過(guò)96MB,所有會(huì)話消耗的內(nèi)存總量不超過(guò)12GB,約可最高支撐128個(gè)并發(fā)連接;此外,innodb buffer pool + 各會(huì)話內(nèi)存的和是 76G,約為物理內(nèi)存的80%,已給系統(tǒng)預(yù)留出基本充足的剩余內(nèi)存,降低發(fā)生SWAP的風(fēng)險(xiǎn)。

延伸閱讀

GreatSQL是由萬(wàn)里數(shù)據(jù)庫(kù)維護(hù)的MySQL分支,專注于提升MGR可靠性及性能,支持InnoDB并行查詢特性,是適用于金融級(jí)應(yīng)用的MySQL分支版本。

相關(guān)鏈接:

 GreatSQL社區(qū) 

 Gitee

 GitHub

以上就是MySQL 8.0新功能監(jiān)控統(tǒng)計(jì)限制連接不再擔(dān)心被垃圾SQL搞爆內(nèi)存的詳細(xì)內(nèi)容,更多關(guān)于MySQL監(jiān)控統(tǒng)計(jì)限制連接的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • MySQL 數(shù)據(jù)類型選擇原則

    MySQL 數(shù)據(jù)類型選擇原則

    MySQL支持大量的數(shù)據(jù)類型,選擇正確的類型對(duì)性能十分關(guān)鍵。本篇介紹了MySQL 的數(shù)據(jù)類型選擇原則,可以根據(jù)這些基本的原則確定數(shù)據(jù)表字段的具體數(shù)據(jù)類型。
    2021-05-05
  • MySQL不停地自動(dòng)重啟的解決方法

    MySQL不停地自動(dòng)重啟的解決方法

    這篇文章主要給大家介紹了關(guān)于MySQL不停地自動(dòng)重啟的解決方法,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家學(xué)習(xí)或者使用MySQL具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2019-07-07
  • MySQL與PHP的基礎(chǔ)與應(yīng)用專題之?dāng)?shù)據(jù)控制

    MySQL與PHP的基礎(chǔ)與應(yīng)用專題之?dāng)?shù)據(jù)控制

    MySQL是一個(gè)關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng),由瑞典MySQL?AB?公司開(kāi)發(fā),屬于?Oracle?旗下產(chǎn)品。MySQL?是最流行的關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)之一,本系列將帶你掌握php與mysql的基礎(chǔ)應(yīng)用,本篇帶你了解數(shù)據(jù)控制
    2022-02-02
  • Mysql表連接的誤區(qū)與原理詳析

    Mysql表連接的誤區(qū)與原理詳析

    在使用MySQL數(shù)據(jù)庫(kù)過(guò)程中,left?join?基本是必用的語(yǔ)法,下面這篇文章主要給大家介紹了關(guān)于Mysql表連接的誤區(qū)與原理的相關(guān)資料,需要的朋友可以參考下
    2022-09-09
  • MySQL數(shù)據(jù)庫(kù)聚合函數(shù)與分組查詢舉例詳解

    MySQL數(shù)據(jù)庫(kù)聚合函數(shù)與分組查詢舉例詳解

    在MySQL中聚合函數(shù)和分組查詢經(jīng)常一起使用,下面這篇文章主要給大家介紹了關(guān)于MySQL數(shù)據(jù)庫(kù)聚合函數(shù)與分組查詢的相關(guān)資料,文中通過(guò)代碼介紹的非常詳細(xì),需要的朋友可以參考下
    2024-01-01
  • MySQL連接器提升應(yīng)用功能與數(shù)據(jù)存儲(chǔ)能力

    MySQL連接器提升應(yīng)用功能與數(shù)據(jù)存儲(chǔ)能力

    這篇文章主要為大家介紹了MySQL連接器提升應(yīng)用功能與數(shù)據(jù)存儲(chǔ)能力,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪
    2023-10-10
  • MySQL IS NULL空值查詢的實(shí)現(xiàn)

    MySQL IS NULL空值查詢的實(shí)現(xiàn)

    MySQL 提供了?IS NULL?關(guān)鍵字,用來(lái)判斷字段的值是否為空值,本文主要介紹了MySQL IS NULL空值查詢的實(shí)現(xiàn),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2024-08-08
  • MySQL limit性能分析與優(yōu)化

    MySQL limit性能分析與優(yōu)化

    今天小編就為大家分享一篇關(guān)于MySQL limit性能分析與優(yōu)化,小編覺(jué)得內(nèi)容挺不錯(cuò)的,現(xiàn)在分享給大家,具有很好的參考價(jià)值,需要的朋友一起跟隨小編來(lái)看看吧
    2019-02-02
  • 關(guān)于MySQL分區(qū)表的一個(gè)性能BUG

    關(guān)于MySQL分區(qū)表的一個(gè)性能BUG

    這篇文章主要給大家講訴MySQL分區(qū)表的一個(gè)性能BUG,也就是使用分區(qū)表進(jìn)行數(shù)據(jù)查詢/加載的時(shí)候比普通表的性能下降了約50%,下面就來(lái)講將對(duì)此的解決辦法,需要的朋友可以參考以下內(nèi)容
    2021-09-09
  • mysql 遞歸查找菜單節(jié)點(diǎn)的所有子節(jié)點(diǎn)的方法

    mysql 遞歸查找菜單節(jié)點(diǎn)的所有子節(jié)點(diǎn)的方法

    這篇文章主要介紹了mysql 遞歸查找菜單節(jié)點(diǎn)的所有子節(jié)點(diǎn),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2020-11-11

最新評(píng)論