亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看

溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

MySQL案例-mysqld got signal 11(補充)

發布時間：2020-08-04 21:05:47 來源：ITPUB博客 閱讀：299 作者：wangwenan6 欄目：MySQL數據庫
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------

背景:
MySQL-5.7.12, debian 8核16G虛擬機, 業務方反饋在某一個時間點, 出現了大量的數據庫報錯, 之后恢復正常;

場景:
開發查看日志后, 發現在某個時間點, 應用斷開了所有與數據庫的連接, 幾秒鐘以后就恢復了;
同時監控系統的內存使用率出現了異常的驟降;
MySQL案例-mysqld got signal 11(補充)

3min之后收到了報警系統的信息, 內存使用率82%;

分析:
第一時間的判斷是網絡的問題造成了應用層的連接斷開了, 但是這種內存使用率驟降的現象不會是網絡造成的;
查看MySQL的日志, 發現MySQL實例發生了crash, 相關的報錯信息如下:

點擊(此處)折疊或打開

  1. 07:42:44 UTC - mysqld got signal 11 ;
  2. This could be because you hit a bug. It is also possible that this binary
  3. or one of the libraries it was linked against is corrupt, improperly built,
  4. or misconfigured. This error can also be caused by malfunctioning hardware.
  5. Attempting to collect some information that could help diagnose the problem.
  6. As this is a crash and something is definitely wrong, the information
  7. collection process might fail.
  9. key_buffer_size=8388608
  10. read_buffer_size=16777216
  11. max_used_connections=29
  12. max_threads=5000
  13. thread_count=32
  14. connection_count=22
  15. It is possible that mysqld could use up to
  16. key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 245834871 K bytes of memory
  17. Hope that is ok; if not, decrease some variables in the equation.
  19. Thread pointer: 0x7f607c0072c0
  20. Attempting backtrace. You can use the following information to find out
  21. where mysqld died. If you see no messages after this, something went
  22. terribly wrong...
  23. stack_bottom = 7f6141b36e80 thread_stack 0x40000
  24. /usr/sbin/mysqld(my_print_stacktrace+0x2c)[0xe77fec]
  25. /usr/sbin/mysqld(handle_fatal_signal+0x459)[0x7a7019]
  26. /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f643257a8d0]
  27. /usr/sbin/mysqld(_ZN16Partition_helper25handle_ordered_index_scanEPh+0x5c)[0xbbabec]
  28. /usr/sbin/mysqld(_ZN7handler13ha_index_lastEPh+0x1b0)[0x7f4410]
  29. /usr/sbin/mysqld(_Z14join_read_lastP7QEP_TAB+0x65)[0xc1f605]
  30. /usr/sbin/mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x11b)[0xc25e4b]
  31. /usr/sbin/mysqld(_ZN4JOIN4execEv+0x3b8)[0xc1ea78]
  32. /usr/sbin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x238)[0xc8e408]
  33. /usr/sbin/mysqld[0x770ccf]
  34. /usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x3403)[0xc51103]
  35. /usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3ad)[0xc531bd]
  36. /usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x817)[0xc53a47]
  37. /usr/sbin/mysqld(_Z10do_commandP3THD+0x18f)[0xc54faf]
  38. /usr/sbin/mysqld(handle_connection+0x278)[0xd108d8]
  39. /usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xe90784]
  40. /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f64325730a4]
  41. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6430e1b87d]
  43. Trying to get some variables.
  44. Some pointers may be invalid and cause the dump to abort.
  45. Query (7f607c015ad0): select * from test where time>='2016-07-29 00:00:00' and time<='2016-07-29 23:59:59' and tag in (2,3,6) order by id desc limit 2000
  46. Connection ID (thread ID): 138760
  47. Status: NOT_KILLED
  49. The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
  50. information that should help you find out what is causing the crash.
  51. 2016-07-29T07:42:45.661724Z mysqld_safe Number of processes running now: 0
  52. 2016-07-29T07:42:45.664516Z mysqld_safe mysqld restarted
  53. 2016-07-29T15:42:45.991109+08:00 0 [Note] /usr/sbin/mysqld (mysqld 5.7.12-log) starting as process 8367 ...

首先是第一部分的信息:

點擊(此處)折疊或打開

  1. mysqld got signal 11 ;
通過perror命令(感謝@楊奇龍的場外援助..._(:з」∠)_...)看到ErrorCode的信息:

點擊(此處)折疊或打開

  1. Resource temporarily unavailable
代表MySQL發現某一項資源臨時不可用, 應該是資源耗盡 or 申請失敗等情況;

然后是第二部分信息:

點擊(此處)折疊或打開

  1. It is possible that mysqld could use up to
  2. key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 245834871 K bytes of memory
這一段計算了當前配置下, 需要的最大內存數, 大概換算了一下, 是234G;

這么高, 明顯是有問題的, 聯想到82%內存使用率的報警信息, 推測是內存耗盡造成的;

用max_used_connections來算一下使用的內存的話,有約1.5G;

加上BP的9.6G, 有11G了, 算上MySQL本身占用的一部分內存, 確實達到了比較高的程度;

但是看了一下kernel和message, 都沒有發現系統出現OOM的日志, 應該不是系統kill的;


再看看堆棧相關的信息, 在里面記錄了MySQL crash時的狀態;

點擊(此處)折疊或打開

  1. stack_bottom = 7f6141b36e80 thread_stack 0x40000
  2. /usr/sbin/mysqld(my_print_stacktrace+0x2c)[0xe77fec]
  3. /usr/sbin/mysqld(handle_fatal_signal+0x459)[0x7a7019]
  4. /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f643257a8d0]
  5. /usr/sbin/mysqld(_ZN16Partition_helper25handle_ordered_index_scanEPh+0x5c)[0xbbabec]
  6. /usr/sbin/mysqld(_ZN7handler13ha_index_lastEPh+0x1b0)[0x7f4410]
  7. /usr/sbin/mysqld(_Z14join_read_lastP7QEP_TAB+0x65)[0xc1f605]
  8. /usr/sbin/mysqld(_Z10sub_selectP4JOINP7QEP_TABb+0x11b)[0xc25e4b]
  9. /usr/sbin/mysqld(_ZN4JOIN4execEv+0x3b8)[0xc1ea78]
  10. /usr/sbin/mysqld(_Z12handle_queryP3THDP3LEXP12Query_resultyy+0x238)[0xc8e408]
  11. /usr/sbin/mysqld[0x770ccf]
  12. /usr/sbin/mysqld(_Z21mysql_execute_commandP3THDb+0x3403)[0xc51103]
  13. /usr/sbin/mysqld(_Z11mysql_parseP3THDP12Parser_state+0x3ad)[0xc531bd]
  14. /usr/sbin/mysqld(_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x817)[0xc53a47]
  15. /usr/sbin/mysqld(_Z10do_commandP3THD+0x18f)[0xc54faf]
  16. /usr/sbin/mysqld(handle_connection+0x278)[0xd108d8]
  17. /usr/sbin/mysqld(pfs_spawn_thread+0x1b4)[0xe90784]
  18. /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x7f64325730a4]
  19. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6430e1b87d]
從紅字等地方的信息, 可以推斷出當時MySQL是正在執行查詢, 這些查詢中有join, 也有subquery, 且查詢的表包含了分區表;

可以預料到在crash的時候, MySQL執行這些語句時肯定需要申請一部分join用的buffer, 同時子查詢也會建立臨時表, 都需要占用內存空間;

同時還有分區表的使用, 看了一下當時候分區表的大小:
MySQL案例-mysqld got signal 11(補充)MySQL案例-mysqld got signal 11(補充)

發現當天的數據超過了BP的大小, 且用到分區表的查詢走的全表掃描, 并且還有order by, 會用到sort的buffer, 且由于全表掃描的數據很多, 這個buffer有可能是需要申請滿的;

綜合這些信息, 基本確認是內存耗盡造成了MySQL crash;

那么根據堆棧的信息嘗試還原crash時的場景:

在內存占用率很高的情況下, MySQL thread在執行較大表的查詢時, 無法再申請到足夠的內存(sort的buffer, join的buffer等), 因此發生了crash;

處理方式:
最終把BP從9.6G調整為9G, 并把sort, read等buffer的數值調整到了4M, 其他的buffer也調低了;

PS: 算是疏忽吧, 因為說在生產環境已經用這么一套配置很久了, 沒出過問題, 所以也沒有仔細的排查配置文件中的設置;
PSS: sort的buffer原來是多少? 32M...sort的buffer還是per thread的...失職了..._(:з」∠)_

-------------------------------------------------------------------------------------------------后續---------------------------------------------------------------------------------------------------------------

峰回路轉.....在調整了buffer的數量以后, 不可能再出現內存不夠的現象了, 然后crash的現象重現了;

而且是主庫和備庫在非常短的時間內都發生了crash;

報錯信息除了pointer不同以外, 堆棧的信息也是完全一致;

包括那個語句;
在之前出問題的時候, 記錄了一條語句:

點擊(此處)折疊或打開

  1. select * from test where time>='2016-07-29 00:00:00' and time<='2016-07-29 23:59:59' and tag in (2,3,6) order by id desc limit 2000
在后來重現的時候, 兩次crash的語句中, 記錄的是同樣的語句, (而且堆棧的輸出信息也是完全一樣) , 僅僅只是時間不一樣:

點擊(此處)折疊或打開

  1. select * from test where time>='2016-08-09 00:00:00' and time<='2016-08-09 23:59:59' and tag in (2,3,6) order by id desc limit 2000
如果是因為內存or系統資源的不可用導致了crash的話, 不可能有這么巧合的事情, 都是這個語句;

so, 在被拉起來的備庫上跑了一下這個語句, 結果MySQL馬上就crash了...
MySQL案例-mysqld got signal 11(補充)

那么明顯就是這個語句的問題了, order by desc + limit, 看上去并沒什么問題, 看看explain的結果
MySQL案例-mysqld got signal 11(補充)

雖然好久沒做開發了, 但是filtered在100%的情況下, rows只有1還是挺奇怪的, 一整張表只有一行數據, 但是還有這種查詢一整天的語句;

看看表的結構;
隱去生產庫上的一部分信息, 留下關鍵的部分;
MySQL案例-mysqld got signal 11(補充)

分區表的分區有問題....

問過業務以后, 原來是這個功能還沒做完, 所以表相關的操作并沒有一直執行;
但是這個功能的頁面沒有屏蔽, 所以對應的那條語句是有可能被觸發的;

考慮到用那條語句可以必現這個crash, 且輸出的堆棧信息和之前完全一致,
所以確定是這個分區表的分區缺失的前提下, 觸發那個查詢語句的時導致了MySQL的Crash;

處理方式:
雖然最后還是找到了問題所在, 但是最開始的時候還是被buffer和內存使用率的現象誤導了, too young......
PS:本來還是覺得分區表在5.7改進了一點以后, 應該還挺好用的.....恩, 現在持保留意見....._(:з」∠)_ 
PPS:應該不會再有后續了, 嗯嗯....
向AI問一下細節

免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。

AI
助
手
津南区| 上饶县| 栖霞市| 当阳市| 广汉市| 汉寿县| 肇庆市| 盖州市| 玉屏| 莒南县| 徐水县| 东源县| 开鲁县| 灵川县| 靖江市| 遵义县| 阿图什市| 花垣县| 石棉县| 东丽区| 北安市| 枣阳市| 江油市| 织金县| 延川县| 五峰| 阿拉尔市| 宿迁市| 景东| 贺兰县| 醴陵市| 余江县| 威宁| 高要市| 枣强县| 嵩明县| 芦溪县| 修文县| 武义县| 油尖旺区| 鄂州市|