詭異bug的解決過(guò)程是什么樣的

今天就跟大家聊聊有關(guān)詭異bug的解決過(guò)程是什么樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

本文記錄一次很詭異的bug （進(jìn)程莫名被終止）的發(fā)現(xiàn)過(guò)程，并且詳細(xì)記錄了問(wèn)題背后的原因，以及解決方案。

背景

此項(xiàng)目是一個(gè)接口的自動(dòng)化測(cè)試平臺(tái)，需要接入自動(dòng)化工程（每個(gè)自動(dòng)化工程對(duì)應(yīng)一個(gè)被測(cè)應(yīng)用工程），每個(gè)自動(dòng)化工程都是獨(dú)立運(yùn)行的進(jìn)程。 自動(dòng)化工程用的是springboot, 利用maven插件運(yùn)行，mvn spring-boot:run 。 該平臺(tái)接入了很多自動(dòng)化工程，在一臺(tái)linux機(jī)器上運(yùn)行著很多個(gè)自動(dòng)化工程的進(jìn)程。

現(xiàn)象

偶爾會(huì)莫名的出現(xiàn)自動(dòng)化工程的進(jìn)行被殺掉的情況，需要在平臺(tái)上重新操作，啟動(dòng)該自動(dòng)化工程之后，才能繼續(xù)運(yùn)行任務(wù)。 直到系統(tǒng)規(guī)模擴(kuò)大，自動(dòng)化工程數(shù)目變多，自動(dòng)化用例變多，運(yùn)行任務(wù)時(shí)間變長(zhǎng)，自動(dòng)化工程被莫名終止的概率加大。

分析

1. 查看log， 發(fā)現(xiàn)自動(dòng)化工程被終止的log信息如下：

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 09:32 min
[INFO] Finished at: 2019-08-15T17:39:55+08:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.2.0.M5:run (default-cli) on project coupon_batch-Test: Application finished with exit code: 137 -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

2. 分析log產(chǎn)生的原因，google : ERROR: Maven JVM terminated unexpectedly with exit code 137

For reference the status code 137 (128 + 9) typically means (can differ between flavours of unix). That the process was terminated by receipt of a signal. In this case signal 9 which is SIGKILL and unblockable kill. If this is the case the underlying machine/OS needs more virtual memory. This can be added by either adding physical memory or swap space as appropriate. You should try to increase the virtual memory of your machine. Note:This also explains why a Jenkins restart (temporarily) fixes the issue. Jenkins Maven Build 137 Error

3. 至此找到問(wèn)題原因：linux swap 分區(qū)不足，導(dǎo)致該進(jìn)程被linux OOM Killer殺掉。

解決問(wèn)題需要的背景知識(shí)

1. 什么是swap?

swap space是磁盤(pán)上的一塊區(qū)域，可以是一個(gè)分區(qū)，也可以是一個(gè)文件，或者是他們的組合。 簡(jiǎn)單點(diǎn)說(shuō)，當(dāng)系統(tǒng)物理內(nèi)存吃緊時(shí)，Linux會(huì)將內(nèi)存中不常訪(fǎng)問(wèn)的數(shù)據(jù)保存到swap上， 這樣系統(tǒng)就有更多的物理內(nèi)存為各個(gè)進(jìn)程服務(wù)，而當(dāng)系統(tǒng)需要訪(fǎng)問(wèn)swap上存儲(chǔ)的內(nèi)容時(shí)， 再將swap上的數(shù)據(jù)加載到內(nèi)存中，這就是我們常說(shuō)的swap out和swap in。

2. 為什么需要swap ？

1. 對(duì)于一些大型的應(yīng)用程序(如LibreOffice、video editor等)，在啟動(dòng)的過(guò)程中會(huì)使用大量的內(nèi)存， 但這些內(nèi)存很多時(shí)候只是在啟動(dòng)的時(shí)候用一下，后面的運(yùn)行過(guò)程中很少再用到這些內(nèi)存。有了swap后， 系統(tǒng)就可以將這部分不這么使用的內(nèi)存數(shù)據(jù)保存到swap上去，從而釋放出更多的物理內(nèi)存供系統(tǒng)使用。

2. 很多發(fā)行版(如ubuntu)的休眠功能依賴(lài)于swap分區(qū)，當(dāng)系統(tǒng)休眠的時(shí)候， 會(huì)將內(nèi)存中的數(shù)據(jù)保存到swap分區(qū)上，等下次系統(tǒng)啟動(dòng)的時(shí)候，再將數(shù)據(jù)加載到內(nèi)存中，這樣可以加快系統(tǒng)的啟動(dòng)速度， 所以如果要使用休眠的功能，必須要配置swap分區(qū)，并且大小一定要大于等于物理內(nèi)存

3. 在某些情況下，物理內(nèi)存有限，但又想運(yùn)行耗內(nèi)存的程序怎么辦？ 這時(shí)可以通過(guò)配置足夠的swap空間來(lái)達(dá)到目標(biāo)，雖然慢一點(diǎn)，但至少可以運(yùn)行。

4. 雖然大部分情況下，物理內(nèi)存都是夠用的，但是總有一些意想不到的狀況，比如某個(gè)進(jìn)程需要的內(nèi)存超過(guò)了預(yù)期， 或者有進(jìn)程存在內(nèi)存泄漏等，當(dāng)內(nèi)存不夠的時(shí)候，就會(huì)觸發(fā)內(nèi)核的OOM killer， 根據(jù)OOM killer的配置，某些進(jìn)程會(huì)被kill掉或者系統(tǒng)直接重啟（默認(rèn)情況是優(yōu)先kill耗內(nèi)存最多的那個(gè)進(jìn)程）， 不過(guò)有了swap后，可以拿swap當(dāng)內(nèi)存用，雖然速度慢了點(diǎn)，但至少給了我們一個(gè)去debug、kill進(jìn)程或者保存當(dāng)前工作進(jìn)度的機(jī)會(huì)。

5. 如果看過(guò)Linux內(nèi)存管理，就會(huì)知道系統(tǒng)會(huì)盡可能多的將空閑內(nèi)存用于cache，以加快系統(tǒng)的I/O速度， 所以如果能將不怎么常用的內(nèi)存數(shù)據(jù)移動(dòng)到swap上，就會(huì)有更多的物理內(nèi)存用于cache，從而提高系統(tǒng)整體性能。

3. swap的缺點(diǎn)

1. 上面介紹了swap的優(yōu)點(diǎn)，那swap的缺點(diǎn)呢？swap是存放在磁盤(pán)上的，磁盤(pán)的速度和內(nèi)存比較起來(lái)慢了好幾個(gè)數(shù)量級(jí)， 如果不停的讀寫(xiě)swap，那么對(duì)系統(tǒng)的性能肯定有影響，尤其是當(dāng)系統(tǒng)內(nèi)存很吃緊的時(shí)候，讀寫(xiě)swap空間發(fā)生的頻率會(huì)很高， 導(dǎo)致系統(tǒng)運(yùn)行很慢，像死了一樣，這個(gè)時(shí)候添加物理內(nèi)存是唯一的解決辦法。

2. 由于系統(tǒng)會(huì)自動(dòng)將不常用的內(nèi)存數(shù)據(jù)移到swap上，對(duì)桌面程序來(lái)說(shuō)，有可能會(huì)導(dǎo)致最小化一個(gè)程序后， 再打開(kāi)時(shí)小卡一下，因?yàn)樾枰獙wap上的數(shù)據(jù)重新加載到內(nèi)存中來(lái)。

Linux交換空間（swap space）

采用的解決方案: 增加swap文件

#先創(chuàng)建一個(gè)新的512M的文件，用來(lái)作為swap文件，文件路徑可以隨便
#fallocate這個(gè)命令依賴(lài)于文件系統(tǒng)，有些老的文件系統(tǒng)不支持這個(gè)命令，比如ext2，
#這種情況下可以用dd來(lái)實(shí)現(xiàn)同樣的效果：
#sudo dd if=/dev/zero of=/mnt/512MiB.swap bs=1024 count=524288
#fallocate和dd的區(qū)別在于：
#fallocate是先聲明這么多，然后在具體用到的時(shí)候文件系統(tǒng)才分配真正的物理磁盤(pán)空間，就是用一點(diǎn)分配一點(diǎn)，
#而dd是一開(kāi)始就實(shí)實(shí)在在的寫(xiě)了512m的數(shù)據(jù)到物理磁盤(pán)空間。
#所以作為測(cè)試來(lái)說(shuō)fallocate方便些，因?yàn)閯傞_(kāi)始不用寫(xiě)任何數(shù)據(jù)，要快
dev@dev:~$ sudo fallocate -l 512m /mnt/512MiB.swap

#修改文件的權(quán)限，避免其他用戶(hù)對(duì)這個(gè)文件進(jìn)行誤操作
dev@dev:~$ sudo chmod 600 /mnt/512MiB.swap

#格式化為swap文件
dev@dev:~$ sudo mkswap /mnt/512MiB.swap

#將新的文件加入到系統(tǒng)中
dev@dev:~$ sudo swapon /mnt/512MiB.swap

#這時(shí)候可以看到新的swap文件已經(jīng)被加入到系統(tǒng)中了，類(lèi)型為file
#這里可以看到由于優(yōu)先級(jí)最高，第一個(gè)swap分區(qū)/dev/dm-1已經(jīng)被使用了24K
dev@dev:~$ swapon -s
Filename                Type        Size    Used    Priority
/dev/dm-1               partition   524284  24      -1
/dev/sdb1               partition   2096124 0       -2
/mnt/512MiB.swap        file        524284  0       -3

#從free命令的輸出可以看到，經(jīng)過(guò)前面兩輪添加swap分區(qū)和文件，
#現(xiàn)在系統(tǒng)的交換空間已經(jīng)變成3G(3144692K)了
dev@dev:~$ free
              total        used        free      shared  buff/cache   available
Mem:         500192       39112        9564        1996      451516      430820
Swap:       3144692          24     3144668

#同樣為了保證系統(tǒng)重啟后會(huì)自動(dòng)加載我們新的swap文件，需要修改/etc/fstab文件
dev@dev:~$ sudo sh -c 'echo "/mnt/512MiB.swap none  swap    sw   0    0" >> /etc/fstab'

進(jìn)階： OOM Killer 配置

理解和配置 Linux 下的 OOM Killer

技術(shù)上的問(wèn)題總會(huì)有原因的，就看你找不找得到。 技術(shù)的問(wèn)題如果深究的話(huà)，有很多可以學(xué)習(xí)的地方，一個(gè)bug就是一個(gè)學(xué)習(xí)機(jī)會(huì)。

看完上述內(nèi)容，你們對(duì)詭異bug的解決過(guò)程是什么樣的有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。