MySQL伺服器發生OOM的案例分析
【問題】
有一臺MySQL5.6.21的伺服器發生OOM，分析下來與多種因素有關
【分析過程】
1、伺服器實體記憶體相對熱點資料檔案偏小，62G實體記憶體+8G的SWAP，資料檔案大小約550G
觸發OOM是binlog備份的cp程序
2、mysqld實際使用實體記憶體遠大於innodb_buffer_pool_size設定，與我們之前分析的記憶體分配管理模組有關，建議更換為jemalloc
<1>這個MySQL例項配置了45G的buffer pool，發生OOM時，mysqld程序實際使用到約61G
<2>另一臺相同配置的伺服器，配了32G的buffer pool，MySQL實體記憶體用到了57G，SWAP已使用5G
3、NUMA節點記憶體分配不均導致了SWAP空間大量使用，下圖是這臺伺服器mysqld程序在各NUMA節點的記憶體使用情況，建議開啟numa interleave訪問
【優化方案】
1、 升級記憶體更大的伺服器
2、 建議更換mysqld程序的記憶體分配管理模組為jemalloc
3、 建議開啟mysql程序的numa interleave訪問
開啟numa interleave的步驟，可以參考文章
相關推薦
MySQL伺服器發生OOM的案例分析
【問題】 有一臺MySQL5.6.21的伺服器發生OOM，分析下來與多種因素有關 【分析過程】 1、伺服器實體記憶體相對熱點資料檔案偏小，62G實體記憶體+8G的SWAP，資料檔案大小約550G 觸發OOM是binlog備份的cp程序 2、mysqld實際使用實體記憶體遠大於innodb_bu
MySQL各種加鎖案例分析
目錄 InnoDB 鎖型別 InnoDB MVCC簡要 事務隔離級別 SQL加鎖分析（主題） 死鎖舉例分析 InnoDB鎖型別 InnoDB Lock Types ❖Shared and Exclusive Locks ❖Intention Locks ❖Reco
MySQL伺服器SSD效能問題分析與測試
【問題】 我們有臺HP的伺服器，SSD在寫IOPS約5000時，%util達到80%以上，那麼這塊SSD的效能究竟有沒有問題，為解決這個問題做了下面測試。 【工具】 blktrace是linux下用來排查IO效能的工具。它可以記錄IO經歷的各個步驟，並計算出IO請求在各個階段的消耗，下面是關鍵的一些
MySQL例項crash的案例分析
【問題描述】 我們生產環境有一組叢集的多臺MySQL伺服器(MySQL 5.6.21)，不定期的會crash，但error log中只記錄了重啟資訊，未記錄crash時的堆疊。 mysqld_safe Number of processes running now: 0 mysqld_safe mysql
Oracle伺服器CPU 100%案例分析(轉)
今天收到開發人員的反應，公司一個非常重要的系統，資料庫伺服器CPU消耗100%，幾乎全是oracle.exe佔用的，但是系統的速度並沒有受到太大影響（或許並非高峰期），而且CPU消耗居高不下，導致系統變得很慢。系統環境：作業系統：Windows Server 2003 SP2Oracle：Or
MySQL伺服器 IO 100%的案例分析
【問題】 有臺MySQL 5.6.21的資料庫例項以寫入為主，IO %util接近100% 寫入IOPS很高 【分析過程】 1、通過iotop工具可以看到當前IO消耗最高的mysql執行緒 2、檢視執行緒49342的堆疊，可以看到正在進行redo lo
VC運行庫版本不同導致鏈接.LIB靜態庫時發生重復定義問題的一個案例分析和總結
修改 borde 並且 release 鏈接 部分 sdn 托管代碼 兩個 MSDN中對於在不同的配置下Link的LIB作了說明： C Runtime Library： 開關 對應的庫 版本 /MD
MySQL令人頭疼的Aborted告警案例分析
mysql error got an error reading communication packetsMySQL關於aborted告警日誌的分析實戰Part1:寫在最前在MySQL的error log中，我們會經常性看到一些各類的Aborted connection錯誤，本文中會針對這類錯誤進行一個初步
MYSQL Truncate 引發數據表損壞案例分析
Truncate innodb_file_per_ta 數據表損壞 最近發布到市場的版本頻繁出現數據庫表損壞的情況，具體的現象是select表提示表不存在，但是查看data文件，對應表的ibd和frm文件都在。 通過對多個故障的統計，找到幾個頻繁出現損壞的表，在分析過程中，發現這些數據表都使用了t
MySQL服務器 IO 100%的案例分析
mage cache bsp don 動作 iot mit tps 寫入 【問題】 有臺MySQL 5.6.21的數據庫實例以寫入為主，IO %util接近100% 寫入IOPS很高 【分析過程】 1、通過iotop工具可以看到當前IO消耗最高的mysq
MySQL大事務導致的Insert慢的案例分析
leader write 磁盤 刪除語句 mixed https ref query end 方案 原文:MySQL大事務導致的Insert慢的案例分析【問題】 有臺MySQL服務器不定時的會出現並發線程的告警，從記錄信息來看，有大量insert的慢查詢，執行幾十秒，等待
MySQL SYS CPU高的案例分析（二）
原文: MySQL SYS CPU高的案例分析（二） 後面又做了補充測試，增加了每秒context switch的監控，以及SQL執行時各步驟消耗時間的監控。 【測試現象一】 啟用1000個併發執行緒的壓測程式，保持壓測程式持續執行，保持innodb_spin_wait_delay預設值
MySQL複製slave伺服器死鎖案例
原文: MySQL複製slave伺服器死鎖案例 MySQL複製剛剛觸發了一個bug，該bug的觸發條件是slave上Xtrabackup備份的時候執行flushs tables with read lock和show slave status有可能和SQL Thread形成死鎖。 該bug在MySQL5.
MySQL SYS CPU高的案例分析（一）
原文: MySQL SYS CPU高的案例分析（一） 【現象】 最近關注MySQL CPU告警的問題時，發現有一種場景，有一些伺服器最近都較頻繁的出現CPU告警，其中的現象是 SYS CPU佔比較高。 下面的截圖來源於“MySQL CPU報警”採集的檔案 【問題分析】
MySQL CPU %sys 高的案例分析（三）
【現象】 最近有臺伺服器晚上CPU告警，系統抓取的故障期間的snapshot顯示CPU %sys較高，同時context switch在300K以上。 是否過高的context switch引起的%sys消耗呢，做了下面的測試，來驗證context switch與CPU %sys之間有沒有直接的關係。
【MySQL經典案例分析】 Waiting for table metadata lock
排查 同時 導致 大量 並發 技術幹貨 mysql模塊 lee exist 本文由雲+社區發表 一、 問題是這樣來的 ? 2018年某個周末，接到連續數據庫的告警，告警信息如下： 二、 苦逼的探索過程 1、總體的思路 看到too many connection的報錯信
MySQL批量更新死鎖案例分析
表結構如下： CREATE TABLE `user_item` ( `id` BIGINT(20) NOT NULL, `user_id` BIGINT(20) NOT NULL, `item_id` BIGINT(20) NOT NULL,
NUMA導致的MySQL伺服器SWAP問題分析與解決方案
【SWAP產生原理】 先從swap產生的原理來分析，由於linux記憶體管理比較複雜，下面以問答的方式列了一些重要的點，方便大家理解： 1、swap是如何產生的 swap指的是一個交換分割槽或檔案，主要是在記憶體使用存在壓力時，觸發記憶體回收，這時可能會將部分記憶體的資料交換到swap空間。 2、
node+express+grunt+mysql操作資料庫案例分析
簡單嘮兩句、 在以前的node操作資料庫，都是選擇mongodb這型別的非關係型資料庫，進行資料儲存操作。而這次業務涉及到mysql，所以來簡單瞭解下node環境下，是如何操作mesql資料庫增刪改查的？ 一、安裝 1. 開發依賴 yarn init ya
MySQL主從檢驗一致性工具pt-table-checksum報錯的案例分析
問題】 有同事反饋我們改造過的MySQL5.7.23版本，使用pt-table-checksum工具比較主從資料庫的一致性時報錯 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT