一.環境說明：
作業系統：centos 6.5 x86_64
資料庫：mysql 5.6.22
伺服器：阿里雲vps，32g mem，0 swap
二.問題情況：
1.某日發現公司線上系統的mysql某個例項的從庫長時間記憶體占用達到60%如下圖
2.於是開始按照以下步驟排查：
(1).檢視mysql裡的執行緒，觀察是否有長期執行或阻塞的sql：
show full processlist
經檢視，沒有發現相關執行緒，可排除該原因
(2).疑似mysql連線使用完成後沒有真正釋放記憶體，檢視mysql記憶體，快取的相關配置，使用如
show global variables like 『%sort_buffer_size%』;
檢視相關的配置項，結果列表彙總如下
( 注：上圖為mysql使用記憶體計算器，具體位址為 )
其中左列為mysql預設配置，右列為當前資料庫的配置，可見預期記憶體使用最大值足足達到了1t，不符合當前系統負載量，說明當前配置不合理，需要進行調整
(3).其中
key_buffer_size = 32m //key_buffer_size指定索引緩衝區的大小，它決定索引處理的速度，尤其是索引讀的速度。只對myisam表起作用。即使你不使用myisam表，但是內部的臨時磁碟表是myisam表，也要使用該值。由於我的資料庫引擎為innodb，大部分表均為innodb，此處取預設值一半32m。
query_cache_size = 64m //查詢快取大小，當開啟時候，執行查詢語句會進行快取，讀寫都會帶來額外的記憶體消耗，下次再次查詢若命中該快取會立刻返回結果。預設改選項為關閉，開啟則需要調整引數項query_cache_type=on。此處採用預設值64m。
tmp_table_size = 64m //範圍設定為64-256m最佳，當需要做類似group by操作生成的臨時表大小，提高聯接查詢速度的效果，調整該值直到created_tmp_disk_tables / created_tmp_tables * 100% <= 25%，處於這樣乙個狀態之下，效果較好，如果**大部分為靜態內容，可設定為64m，如果為動態頁面，則設定為100m以上，不宜過大，導致記憶體不足i/o堵塞。此處我們設定為64m。
innodb_buffer_pool_size = 8196m //這個引數主要作用是快取innodb表的索引，資料，插入資料時的緩衝。專用mysql伺服器設定的大小： 作業系統記憶體的70%-80%最佳。由於我們的伺服器還部署有其他應用，估此處設定為8g。此外，這個引數是非動態的，要修改這個值，需要重啟mysqld服務。設定的過大，會導致system的swap空間被占用，導致作業系統變慢，從而減低sql查詢的效率。
innodb_additional_mem_pool_size = 16m //用來存放innodb的內部目錄，這個值不用分配太大，系統可以自動調。不用設定太高。通常比較大資料設定16ｍ夠用了，如果表比較多，可以適當的增大。如果這個值自動增加，會在error log有中顯示的。此處我們設定為16m。
innodb_log_buffer_size = 8m //innodb的寫操作，將資料寫入到記憶體中的日誌快取中，由於innodb在事務提交前，並不將改變的日誌寫入到磁碟中，因此在大事務中，可以減輕磁碟i/o的壓力。通常情況下，如果不是寫入大量的超大二進位制資料（a lot of huge blobs），4mb-8mb已經足夠了。此處我們設定為8m。
sort_buffer_size = 2m //是乙個connection級引數，在每個connection第一次需要使用這個buffer的時候，一次性分配設定的記憶體。並不是越大越好，由於是connection級的引數，過大的設定+高併發可能會耗盡系統記憶體資源。官方文件推薦範圍為256kb~2mb，這裡我們設定為2m。
read_buffer_size = 2m //（資料檔案儲存順序）是mysql讀入緩衝區的大小，將對錶進行順序掃瞄的請求將分配乙個讀入緩衝區，mysql會為它分配一段記憶體緩衝區，read_buffer_size變數控制這一緩衝區的大小，如果對錶的順序掃瞄非常頻繁，並你認為頻繁掃瞄進行的太慢，可以通過增加該變數值以及記憶體緩衝區大小提高其效能，read_buffer_size變數控制這一提高表的順序掃瞄的效率 資料檔案順序。此處我們設定得比預設值大一點，為2m。
read_rnd_buffer_size = 250k //是mysql的隨機讀緩衝區大小，當按任意順序讀取行時（列如按照排序順序）將分配乙個隨機讀取緩衝區，進行排序查詢時，mysql會首先掃瞄一遍該緩衝，以避免磁碟搜尋，提高查詢速度，如果需要大量資料可適當的調整該值，但mysql會為每個客戶連線分配該緩衝區所以盡量適當設定該值，以免記憶體開銷過大。表的隨機的順序緩衝 提高讀取的效率。此處設定為跟預設值相似，250kb。
join_buffer_size = 250k //多表參與join操作時的分配快取，適當分配，降低記憶體消耗，此處我們設定為250kb。
thread_stack = 256k //每個連線線程被建立時，mysql給它分配的記憶體大小。當mysql建立乙個新的連線線程時，需要給它分配一定大小的記憶體堆疊空間，以便存放客戶端的請求的query及自身的各種狀態和處理資訊。thread cache 命中率：thread_cache_hit = (connections - threads_created) / connections * 100%;命中率處於90%才算正常配置，當出現「mysql-debug: thread stack overrun」的錯誤提示的時候需要增加該值。此處我們配置為256k。
binlog_cache_size = 250k // 為每個session 分配的記憶體，在事務過程中用來儲存二進位制日誌的快取。作用是提高記錄bin-log的效率。沒有什麼大事務，dml也不是很頻繁的情況下可以設定小一點，如果事務大而且多，dml操作也頻繁，則可以適當的調大一點。前者建議是1048576 –1m；後者建議是： 2097152 – 4194304 即 2–4m。此處我們根據系統實際，配置為250kb。
調整後各項效能引數如下圖，且經過圖表計算，例項使用的記憶體將穩定在12g左右，符合當前系統負載情況
之後重啟mysql例項，發現記憶體佔用量回落，並且長時間內沒有再次發生占用過高情況，優化成功。
記一次mongo資料庫CPU佔用率過高的問題
早上收到了一封預警郵件 檢視監控，cpu使用率過高，這種情況百分之95都是 問題。例項規格公升級是不用公升級的。db.currentop 查詢正在執行的命令 查詢secs running 執行時間長的語句。發現有乙個skip limit 10 的語句在執行。問詢得知是新上的跑批功能，在資料量比較大的...
記一次排查記憶體占用逐漸增長問題
最近改了好多 做優化，然後線下測試發現很不符合預期，表現如下 跑一段時間，記憶體占用越來越大 一種懷疑記憶體洩漏，查詢了一下午，終於定位，其實是效能回退問題，特別寫下mark下 任務 記憶體是通過非同步執行緒池 基於監控項，發現非同步執行緒池堆積任務持續增加，因此導致記憶體增大，不能及時釋放 基於現...
一次java系統執行緒占用CPU過高問題的解決
開啟doc命令列，執行命令 jstack l 9520 d jstack.txt 開啟d盤下的jstack.txt檔案，搜尋16進製制的執行緒編號4c90，找到後就可定位到有問題的 1，使用top 命令動態的展示占用前幾的程序pid，cpu消耗，time，res 等資訊，然後找到cpu占用最高的pi...