業務場景
mysql
元件版本：
mysql：
5.7.25軟體架構：
兩主兩從
01問題描述
mysql是乙個關係型資料庫管理系統，屬於oracle旗下產品。mysql是最流行的關係型資料庫管理系統之一，在web應用方面，mysql是最好的rdbms(relational database management system，關聯式資料庫管理系統)應用軟體之一，mysql所使用的sql語言是用於訪問資料庫的最常用標準化語言。mysql軟體採用了雙授權政策，分為社群版和商業版，由於其體積小、速度快、總體擁有成本低，尤其是開放原始碼這一特點，一般中小型**的開發都選擇mysql作為**資料庫。
某業務系統採用mysql社群開源版本架構為兩主兩從，排除人為因素故障，mysql常出現的故障是記憶體溢位(oom全稱"outofmemory"，即記憶體溢位)，記憶體溢位已經是軟體開發歷史上存在了近40年的「老大難」問題。在作業系統上執行各種軟體時，軟體所需申請的記憶體遠遠超出了物理記憶體所承受的大小，就叫記憶體溢位。由於該業務系統採用了主從+vip架構，當主庫由於記憶體溢位掛掉後，另外乙個主庫負責業務，所以業務有短暫幾十秒時間的故障期，但對整體業務未產生影響。
02結構及詳細說明
mysql高可用大致架構圖：
兩個例項互為主從，另外兩個例項分別為這兩個主例項的從庫例項，兩個主庫例項之間通過keepalived監控例項以實現vip高可用。
03問題定位
主庫實列發生oom，例項程序由於占用記憶體達到linux系統的最大閾值，導致linux系統kill了mysql例項程序，可以通過如下方式檢視mysql使用了多少記憶體：
檢視每個執行緒占用多少記憶體，然後乘以正在執行的執行緒(也就是排查sleep的)。
select( ( @@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size+ @@join_buffer_size + @@binlog_cache_size + @@thread_stack +@@tmp_table_size + @@bulk_insert_buffer_size + @@max_allowed_packet +@@net_buffer_length ) ) / (1024*1024) as memory_mb;
showglobal status like '%threads%';
檢視mysql全域性占用多少記憶體
select(@@innodb_buffer_pool_size+@@innodb_log_buffer_size+@@key_buffer_size)/ 1024 /1024 as memory_mb;
檢視performance_schema占用多少記憶體
selectsubstring_index(event_name,'/',2) as code_area,sys.format_bytes(sum(current_alloc)) as current_alloc fromsys.x$memory_global_by_current_bytes group bysubstring_index(event_name,'/',2) order by sum(current_alloc) desc;
檢視memory儲存引擎占用多少記憶體
selectsum(max_data_length)/1024/1024 as memory_mb from tables whereengine='memory';
04解決過程
通過以上方式檢視當前mysql資料庫具體占用多少記憶體，從而找到占用記憶體較多的物件，在根據物件的具體作用來調節資料庫配置：
如執行緒數過多，可以調整業務連線為長連線，長連線固定占用記憶體，是業務連線重複使用記憶體。
如innodbbuffer占用過多而業務所跑tps不大，可以通過調小innodbbuffer，減少記憶體占用
如以上方式無法整改，可以通過新增物理記憶體方式
由於該業務採用了高可用架構，所以mysql發生故障時，業務未產生影響。
05總 結
1、mysql生產為了保證資料以及業務連續性，一定要使用高可用架構
2、oom記憶體溢位一定要仔細檢視mysql是哪部分占用記憶體較多，再根據不同部分調整業務生產庫的相關配置，包括硬體配置及軟體配置。
end
jvm 記憶體溢位，引發溢位原因排查
jvm 記憶體溢位，引發溢位原因排查 一 dump檔案分析 dump檔案獲取方式 1 設定jvm引數 xx heapdumponoutofmemoryerror xx heapdumppath tmp heapdump.hprof 記憶體溢位時產生dump檔案 2 使用jmap生成dump 檔案 d...
OOM 記憶體溢位排查手記
到目前為止，發生了幾次溢位。現將排查過程記錄如下，供大家交流。可以看到出現oom的執行緒是grpc,這個執行緒可以關注下，不過目前還不能確定是這個執行緒引起的問題，也可能是這個執行緒比較倒霉。可以看到，站記憶體最大的幾個物件都是hibernate和mysql有關的類。猜測，可能資料寫入異常，導致大量...
Linux下JVM記憶體溢位後排查分析
記錄下常用的方式，後期根據使用繼續完善。記憶體溢位後排查分析 1 通過命令檢視對應的程序號 比如 jps 或者 ps ef grep servicemix 2 輸入命令檢視gc情況 命令 jstat gcutil 程序號 重新整理的毫秒數 展示的記錄數 比如 jstat gcutil 14050 1...