自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

記一次生產(chǎn)數(shù)據(jù)庫(kù)"意外"重啟的經(jīng)歷

作者：小柒2012
運(yùn)維 數(shù)據(jù)庫(kù)運(yùn)維
在一個(gè)陽(yáng)光明媚的下午，電腦右下角傳來(lái)一片片郵件提醒，同時(shí)伴隨著微信釘釘?shù)恼饎?dòng)，打開(kāi)一看，應(yīng)用各種出錯(cuò)，天兔告警，數(shù)據(jù)庫(kù)服務(wù)器內(nèi)存爆紅，MySql 數(shù)據(jù)庫(kù)實(shí)例掛掉了。

[[251734]]

 前言

在一個(gè)陽(yáng)光明媚的下午，電腦右下角傳來(lái)一片片郵件提醒，同時(shí)伴隨著微信釘釘?shù)恼饎?dòng)，打開(kāi)一看，應(yīng)用各種出錯(cuò)，天兔告警，數(shù)據(jù)庫(kù)服務(wù)器內(nèi)存爆紅，MySql 數(shù)據(jù)庫(kù)實(shí)例掛掉了。

排查

先交代一下數(shù)據(jù)庫(kù)版本：   

  1. mysql> status  
  2.     --------------  
  3.     mysql  Ver 14.14 Distrib 5.7.22-22, for Linux (x86_64) using  6.2  
  4.     Connection id:          59568  
  5.     Current database:  
  6.     Current user:           root@localhost  
  7.     SSL:                    Not in use  
  8.     Current pager:          stdout  
  9.     Using outfile:          ''  
  10.     Using delimiter:        ;  
  11.     Server version:         5.7.22-22-log Percona Server (GPL), Release 22, Revision f62d93c  
  12.     Protocol version:       10 

崩潰故障排除絕不是一項(xiàng)有趣的任務(wù)，特別是如果MySQL沒(méi)有報(bào)告崩潰的原因。例如，當(dāng)MySQL內(nèi)存不足時(shí)。

數(shù)據(jù)庫(kù)郵件告警提醒發(fā)來(lái)的消息：   

  1. Type: mysql  
  2.    Tags: 生產(chǎn)主庫(kù)  
  3.    Host: 172.16.1.66:3306  
  4.    Level: critical  
  5.    Item: connect  
  6.    Value: down  
  7.    Message: mysql server down 

登錄 Grafana 監(jiān)控面板，數(shù)據(jù)庫(kù)連接在哪個(gè)時(shí)間段曾有幅度的增長(zhǎng)。

順手檢查一下之前的服務(wù)器郵件監(jiān)控告警記錄，上一個(gè)時(shí)間點(diǎn)，內(nèi)存占用率99%，這說(shuō)明了數(shù)據(jù)庫(kù)連接的幅度增長(zhǎng)，可能是壓垮服務(wù)器的最后一根稻草。

其實(shí)導(dǎo)致OOM的直接原因并不復(fù)雜，就是因?yàn)榉?wù)器內(nèi)存不足，內(nèi)核需要回收內(nèi)存，回收內(nèi)存就是kill掉服務(wù)器上使用內(nèi)存最多的程序，而MySQL服務(wù)可能就是使用內(nèi)存最多，所以就OOM了。 

  1. Type: os  
  2.   Tags: 66數(shù)據(jù)庫(kù)  
  3.   Host: 172.16.1.66:  
  4.   Level: critical  
  5.   Item: memory  
  6.   Value: 99%  
  7.   Message: too more memory usage 

查看系統(tǒng)日志

我們帶著這個(gè)疑問(wèn)來(lái)排查一下日志： 

  1. # 查看日志  
  2.   tail -500f  /var/log/messages  
  3.   # 以下是 oom-killer  
  4.   Nov 27 14:55:48 itstyledb1 kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0  
  5.   Nov 27 14:55:48 itstyledb1 kernel: mysqld cpuset=/ mems_allowed=0-1  
  6.   Nov 27 14:55:48 itstyledb1 kernel: CPU: 2 PID: 895 Comm: mysqld Kdump: loaded Not tainted 3.10.0-862.3.2.el7.x86_64 #1  
  7.   Nov 27 14:55:48 itstyledb1 kernel: Hardware name: Huawei RH1288 V3/BC11HGSC0, BIOS 3.22 05/16/2016  
  8.   Nov 27 14:55:48 itstyledb1 kernel: Call Trace: 

小伙伴們繼續(xù)往下看： 

  1. 0 pages HighMem/MovableOnly  
  2.   Nov 27 14:55:48 itstyledb1 kernel: 291281 pages reserved  
  3.   Nov 27 14:55:48 itstyledb1 kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name  
  4.   Nov 27 14:55:48 itstyledb1 kernel: [  468]     0   468    28271     4326      62       55             0 systemd-journal  
  5.   Nov 27 14:55:48 itstyledb1 kernel: [  490]     0   490    11492        2      24      553         -1000 systemd-udevd  
  6.   Nov 27 14:55:48 itstyledb1 kernel: [  787]     0   787    13877       18      27       96         -1000 auditd  
  7.   Nov 27 14:55:48 itstyledb1 kernel: [  810]    81   810    14552       81      34       89          -900 dbus-daemon  
  8.   Nov 27 14:55:48 itstyledb1 kernel: [  815]     0   815    55956        1      60      466             0 abrtd  
  9.   Nov 27 14:55:48 itstyledb1 kernel: [  816]     0   816    55327        9      64      346             0 abrt-watch-log  
  10.   Nov 27 14:55:48 itstyledb1 kernel: [  818]     0   818   121607      220      90      495             0 NetworkManager  
  11.   Nov 27 14:55:48 itstyledb1 kernel: [  822]     0   822     5415       49      16       33             0 irqbalance  
  12.   Nov 27 14:55:48 itstyledb1 kernel: [  823]   997   823   134634       97      60     1306             0 polkitd  
  13.   Nov 27 14:55:48 itstyledb1 kernel: [  825]     0   825     6594       42      20       41             0 systemd-logind  
  14.   Nov 27 14:55:48 itstyledb1 kernel: [  830]     0   830    31578       28      21      139             0 crond  
  15.   Nov 27 14:55:48 itstyledb1 kernel: [  839]     0   839    27522        2      10       31             0 agetty  
  16.   Nov 27 14:55:48 itstyledb1 kernel: [ 1142]     0  1142   143454      114      97     2672             0 tuned  
  17.   Nov 27 14:55:48 itstyledb1 kernel: [ 1144]     0  1144    28203       11      59      246         -1000 sshd  
  18.   Nov 27 14:55:48 itstyledb1 kernel: [ 1145]     0  1145    97438      694     103      328             0 rsyslogd  
  19.   Nov 27 14:55:48 itstyledb1 kernel: [ 1369]     0  1369    22526       20      44      256             0 master  
  20.   Nov 27 14:55:48 itstyledb1 kernel: [ 1371]    89  1371    22596       32      46      251             0 qmgr  
  21.   Nov 27 14:55:48 itstyledb1 kernel: [ 5140]     0  5140     5102     1617      15      239             0 mysqld_exporter  
  22.   Nov 27 14:55:48 itstyledb1 kernel: [ 9430]     0  9430    55966      378      62      790             0 snmpd  
  23.   Nov 27 14:55:48 itstyledb1 kernel: [30320]    27 30320 22951376 13928375   43437  8163662             0 mysqld  
  24.   Nov 27 14:55:48 itstyledb1 kernel: [  688]    89   688    22552      271      46        0             0 pickup  
  25.   Nov 27 14:55:48 itstyledb1 kernel: Out of memory: Kill process 30320 (mysqld) score 984 or sacrifice child  
  26.   Nov 27 14:55:48 itstyledb1 kernel: Killed process 30320 (mysqld) total-vm:91805504kB, anon-rss:55713500kB, file-rss:0kB, shmem-rss:0kB  
  27.   Nov 27 14:56:00 itstyledb1 systemd: mysqld.service: main process exited, code=killed, status=9/KILL  
  28.   Nov 27 14:56:00 itstyledb1 systemd: Unit mysqld.service entered failed state.  
  29.   Nov 27 14:56:00 itstyledb1 systemd: mysqld.service failed.  
  30.   Nov 27 14:56:00 itstyledb1 systemd: mysqld.service holdoff time over, scheduling restart.  
  31.   Nov 27 14:56:01 itstyledb1 systemd: Starting MySQL Server... 

當(dāng)out of memory發(fā)生時(shí)，outofmemory函數(shù)會(huì)選擇一個(gè)內(nèi)核認(rèn)為犯有分配過(guò)多內(nèi)存 “罪行”的進(jìn)程，并殺死該進(jìn)程。顯然 Mysql 就是哪個(gè)“罪人”。

隨后 MySql 會(huì)自動(dòng)重啟。重啟以后，內(nèi)存是下來(lái)了，但是臨近下班的時(shí)候，差不多又又又占滿(mǎn)了。 

  1. [root@itstyledb1 ~]# free -m  
  2.                total        used        free      shared  buff/cache   available  
  3.  Mem:          55803       54976         241          10         585         349  
  4.  Swap:         32064       25036        7028 

找到MySql進(jìn)程，執(zhí)行以下top -p pid，內(nèi)存使用52.4g 

  1. PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND  
  2.   935 mysql     20   0   79.7g  52.4g   7336 S   0.3 96.1 255:44.76 mysqld 

計(jì)算內(nèi)存使用

1)查看MySQL全局占用多少內(nèi)存

 

  1. SELECT (@@innodb_buffer_pool_size  
  2. +@@innodb_log_buffer_size  
  3. +@@key_buffer_size) / 1024 /1024 AS MEMORY_MB; 

查詢(xún)結(jié)果為：   

  1. +----------------+  
  2.    | MEMORY_MB      |  
  3.    +----------------+  
  4.    | 20512.00000000 |  
  5.    +----------------+ 

2）查看performance_schema占用多少內(nèi)存 

  1. SELECT SUBSTRING_INDEX(event_name,'/',2) AS  
  2.          code_area, sys.format_bytes(SUM(current_alloc))  
  3.          AS current_alloc  
  4.          FROM sys.x$memory_global_by_current_bytes  
  5.          GROUP BY SUBSTRING_INDEX(event_name,'/',2)  
  6.          ORDER BY SUM(current_alloc) DESC; 

查詢(xún)結(jié)果為：   

  1. +---------------------------+---------------+  
  2.     | code_area                 | current_alloc |  
  3.     +---------------------------+---------------+  
  4.     | memory/performance_schema | 349.80 MiB    |  
  5.     +---------------------------+---------------+ 

3）查看每個(gè)線(xiàn)程占用多少內(nèi)存   

  1. SELECT ( ( @@read_buffer_size  
  2.    + @@read_rnd_buffer_size  
  3.    + @@sort_buffer_size  
  4.    + @@join_buffer_size  
  5.    + @@binlog_cache_size  
  6.    + @@thread_stack  
  7.    + @@max_allowed_packet  
  8.    + @@net_buffer_length )  
  9.    ) / (1024*1024) AS MEMORY_MB; 

查詢(xún)結(jié)果為： 

  1. +-----------+  
  2.   | MEMORY_MB |  
  3.   +-----------+  
  4.   |   87.5156 |  
  5.   +-----------+ 

查看當(dāng)前線(xiàn)程   

  1. show full processlist 

最終結(jié)果為：   

  1. +-----------+  
  2.     | MEMORY_MB |  
  3.     +-----------+  
  4.     | 87.5156*37|  
  5.     +-----------+ 

4）查看 memory 存儲(chǔ)引擎占用多少內(nèi)存   

  1. SELECT SUM(max_data_length)/1024/1024 AS MEMORY_MB FROM information_schema.tables WHERE ENGINE='memory'; 

查詢(xún)結(jié)果為：

 

  1. +---------------+  
  2. | MEMORY_MB     |  
  3. +---------------+  
  4. | 3857.37713909 |  
  5. +---------------+ 

以上四項(xiàng)加起來(lái)差不多也就27975MB，差不錯(cuò)28G的樣子，但是 MySql 進(jìn)程顯示占用了52.4G，那么剩下24.4G去哪了？

線(xiàn)程池

此線(xiàn)程池非彼連接池，其實(shí)兩者是有很大區(qū)別的，連接池一般在客戶(hù)端設(shè)置，而線(xiàn)程池是在DB服務(wù)器上配置；另外連接池可以取到避免了連接頻繁創(chuàng)建和銷(xiāo)毀，但是無(wú)法取到控制MySQL活動(dòng)線(xiàn)程數(shù)的目標(biāo)，在高并發(fā)場(chǎng)景下，無(wú)法取到保護(hù)DB的作用。比較好的方式是將連接池和線(xiàn)程池結(jié)合起來(lái)使用。

關(guān)于線(xiàn)程池的一些參數(shù)：   

  1. mysql> show variables like 'thread%';  
  2.    +-------------------------------+---------------------------+  
  3.    | Variable_name                 | Value                     |  
  4.    +-------------------------------+---------------------------+  
  5.    | thread_handling               | one-thread-per-connection |  
  6.    | thread_pool_high_prio_mode    | transactions              |  
  7.    | thread_pool_high_prio_tickets | 4294967295                |  
  8.    | thread_pool_idle_timeout      | 60                        |  
  9.    | thread_pool_max_threads       | 100000                    |  
  10.    | thread_pool_oversubscribe     | 3                         |  
  11.    | thread_pool_size              | 12                        |  
  12.    | thread_pool_stall_limit       | 500                       |  
  13.    +-------------------------------+---------------------------+ 

thread_handling：

該參數(shù)是配置線(xiàn)程模型，默認(rèn)情況是one-thread-per-connection，也就是不啟用線(xiàn)程池。將該參數(shù)設(shè)置為pool-of-threads即啟用了線(xiàn)程池。

threadpoolsize：

該參數(shù)是設(shè)置線(xiàn)程池的Group的數(shù)量，默認(rèn)為系統(tǒng)CPU的個(gè)數(shù)，充分利用CPU資源。

threadpooloversubscribe：

該參數(shù)設(shè)置group中的最大線(xiàn)程數(shù)，每個(gè)group的最大線(xiàn)程數(shù)為threadpooloversubscribe+1，注意listener線(xiàn)程不包含在內(nèi)。

threadpoolhighpriomode：

高優(yōu)先級(jí)隊(duì)列的控制參數(shù)，有三個(gè)值（transactions/statements/none），默認(rèn)是transactions，三個(gè)值的含義如下：

  •  transactions：對(duì)于已經(jīng)啟動(dòng)事務(wù)的語(yǔ)句放到高優(yōu)先級(jí)隊(duì)列中，不過(guò)還取決于后面的threadpoolhighpriotickets參數(shù)
  •  statements：這個(gè)模式所有的語(yǔ)句都會(huì)放到高優(yōu)先級(jí)隊(duì)列中，不會(huì)使用到低優(yōu)先級(jí)隊(duì)列
  •  none：這個(gè)模式不使用高優(yōu)先級(jí)隊(duì)列

threadpoolhighpriotickets：

該參數(shù)控制每個(gè)連接最多語(yǔ)序多少次被放入高優(yōu)先級(jí)隊(duì)列中，默認(rèn)為4294967295，注意這個(gè)參數(shù)只有在threadpoolhighpriomode為transactions的時(shí)候才有效果。

threadpoolidle_timeout：

worker線(xiàn)程最大空閑時(shí)間，默認(rèn)為60秒，超過(guò)限制后會(huì)退出。

threadpoolmax_threads：

該參數(shù)用來(lái)限制線(xiàn)程池最大的線(xiàn)程數(shù)，超過(guò)該限制后將無(wú)法再創(chuàng)建更多的線(xiàn)程，默認(rèn)為100000。

threadpoolstall_limit：

該參數(shù)設(shè)置timer線(xiàn)程的檢測(cè)group是否異常的時(shí)間間隔，默認(rèn)為500ms。

最終配置如下：   

  1. #thread pool  
  2.    thread_handling=pool-of-threads  
  3.    #Group的數(shù)量，默認(rèn)為系統(tǒng)CPU的個(gè)數(shù)，充分利用CPU資源  
  4.    thread_pool_size=24  
  5.    #每個(gè)group的最大線(xiàn)程數(shù)為thread_pool_oversubscribe+1  
  6.    thread_pool_oversubscribe=3  
  7.    performance_schema=off  
  8.    #extra connection，防止線(xiàn)程池滿(mǎn)的情況下無(wú)法登錄MySQL  
  9.    extra_max_connections = 8  
  10.    extra_port = 33333 

備注：線(xiàn)程池在Percona,MariaDB,Oracle MySQL企業(yè)版中提供，Oracle MySQL社區(qū)版并不提供。

線(xiàn)程池貌似并不會(huì)直接導(dǎo)致內(nèi)存不回收，網(wǎng)上有說(shuō)同時(shí)開(kāi)啟Thread pool和PS會(huì)出現(xiàn)內(nèi)存泄露，但是 目前Percona server 5.7.21-20+版本已經(jīng)修復(fù)了這個(gè)問(wèn)題，顯然是不存在的。

慢查詢(xún)

由于是生產(chǎn)環(huán)境，這個(gè)問(wèn)題拖得時(shí)間有點(diǎn)長(zhǎng)，那么慢查詢(xún)會(huì)不會(huì)影響內(nèi)存使用問(wèn)題呢？帶著這個(gè)問(wèn)題，查看了慢查詢(xún)后臺(tái)列表，在數(shù)據(jù)庫(kù)奔潰的前一個(gè)時(shí)間段，的確有不少慢查詢(xún)語(yǔ)句。但是這并不能在一定程度上說(shuō)明問(wèn)題，由于服務(wù)器的 MySql 服務(wù)在殺死之前，內(nèi)存已經(jīng)見(jiàn)底，此時(shí)連接數(shù)并不多，也就三四十來(lái)個(gè)左右，大多處于休眠狀態(tài)，并且此時(shí)已經(jīng)占用了大部分的Swap空間。也就是說(shuō)，在資源有限的情況下必定會(huì)出現(xiàn)不少慢查詢(xún)語(yǔ)句。

小結(jié)

其實(shí)這個(gè)"意外"一點(diǎn)也不意外，其實(shí)已經(jīng)發(fā)生了多次了。但是還是做個(gè)小結(jié)吧，因?yàn)樽罱K沒(méi)有確認(rèn)問(wèn)題出現(xiàn)在哪里，所以還是發(fā)布了吧，萬(wàn)一有專(zhuān)業(yè)的DBA遇到類(lèi)似的問(wèn)題還可以小小的解惑一下。

 

責(zé)任編輯：龐桂玉 來(lái)源： ITPUB
數(shù)據(jù)庫(kù)服務(wù)器線(xiàn)程池
相關(guān)推薦

2019-08-19 01:34:38

數(shù)據(jù)庫(kù)SQL數(shù)據(jù)庫(kù)優(yōu)化

2019-11-18 13:42:55

MySQL數(shù)據(jù)庫(kù)遷移

2019-11-22 08:05:01

數(shù)據(jù)庫(kù)mysql分區(qū)

2019-12-12 10:38:10

mysql數(shù)據(jù)庫(kù)nnodb

2019-07-25 08:30:58

數(shù)據(jù)庫(kù)服務(wù)器故障

2019-12-16 07:18:42

數(shù)據(jù)庫(kù)SQL代碼

2019-09-27 17:24:26

數(shù)據(jù)庫(kù)優(yōu)化sql

2019-09-05 09:17:37

MySQL數(shù)據(jù)庫(kù)線(xiàn)程

2018-07-18 15:37:24

數(shù)據(jù)庫(kù)DB2故障處理

2019-09-08 17:52:10

數(shù)據(jù)庫(kù)log file sy等待事件

2019-12-02 08:09:57

境數(shù)據(jù)庫(kù)連接超時(shí)自動(dòng)回收

2021-03-01 06:14:50

環(huán)境高并發(fā)延遲

2020-11-03 07:34:12

Kafka后端工程師

2022-06-01 06:17:42

微服務(wù)Kafka

2017-10-27 09:01:26

Oracle存儲(chǔ)管理

2020-09-25 07:57:42

生產(chǎn)事故系統(tǒng)

2021-01-12 07:57:36

MySQLBinlog故障處理

2019-12-27 10:43:48

磁盤(pán)數(shù)據(jù)庫(kù)死鎖

2013-01-17 10:31:13

JavaScriptWeb開(kāi)發(fā)firebug

2013-04-01 10:27:37

程序員失業(yè)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)