[[414841]]

一

最近無意間打開了曾經做后端時的筆記，想起來許多往事，挑了一段有意思的，分享給大家。

故事發生的時候我還是一個萌新，啥都不知道，完全聽老板和師兄安排。發生的時候是一個周末，周末嘛，自然就開開心心過周末，出去玩耍、約會，吃點好吃的，或者找點好玩的。就在正開心的時候，突然收到一條報警短信，說某某服務器掛了。

我正擔心呢，就收到了師兄的消息，他說不要緊，我讓隔壁組的同事幫忙查了，應該很快就能好。

我聽到師兄這么講也就安心了，沒想到后來整個服務都宕機了，完全無法響應，因此還出了一個P1的故障。一般來說這種級別的故障都有一些很深奧的原因，沒想到后來開故障分析會的時候，才知道這次的事故起因非常非常不起眼，出在了大家日常都會使用的vim上。

二

原本第一臺機器的宕機并不稀奇，由于OOM。

當時的服務器后端是用Java寫的，Java和C++相比最大的區別就是Java有自動垃圾回收機制，而C++只能手動釋放內存。

但Java的自動垃圾回收機制也有很多問題，比如JVM的配置不合理，或者是代碼寫得不夠優雅，創建了許多極耗內存的對象，垃圾回收策略來不及處理或者是超過了能夠處理的極限，就會引起內存超界的錯誤。英文是OutOfMemory，簡稱為OOM。

這種現象在Java后端還挺常見的，可能我們當時的系統也的確不夠優雅。原本這個問題并不大，因為集群都有負載均衡策略，一個服務都對應多臺機器。哪怕是一臺機器掛了，上層的網關做流量分發的時候會自動避開宕機的機器，一樣能保證請求都能有響應。

所以一臺機器掛了其實沒啥問題，我們什么都不做等它自動重啟或者是找運維幫忙手動重啟都行。要命就要命在找了隔壁組的師兄來排查故障。

這哥們排查故障的時候，非常自然地連上了服務器，然后用vim打開了系統的日志。

就是這一行代碼：

vim xxxx.log 

三

我當時聽到報告的時候也很納悶，vim打開日志不是天經地義的事情嗎，這也會出問題嗎?

正常來說當然是不會，但這里有一個隱藏的前提條件，就是vim打開文件時會把文件加載在系統的內存里(顯然)。既然是加載在內存里，那么自然是會消耗內存的。這就導致了一個問題，如果這個文件太大，然后又用了vim強行打開，很有可能會導致系統內存耗盡于是崩潰。

這個哥們那天正是遇到了這樣的事情，他發現vim打開之后ssh連接斷了。他以為是自己的網絡出了問題，于是他換了一臺機器連接查看日志，于是同樣的劇本再次上演。這哥們一口氣把所有的服務器都查看了一遍，發現都沒反應，他以為是自己的ssh跪了，就匯報說暫時看不了問題，因為ssh跪了。

報告的人也沒當回事，因為之前的報警只是掛了一臺機器，不會影響服務，也就沒當回事。你可能會好奇，后面的機器掛了難道沒報警嗎?說來慚愧，關于這里的細節我有些記不清了。

我猜想了一下，無非兩種可能，一種是報警程序是運行在機器里檢測java進程的，java進程掛了能夠發現并報警，但如果是機器直接掛了，就沒法報警了。第二種可能是報警了，但是他們以為還是之前的問題，于是忽略了。

四

當時這個故事給我觸動很大，這也是我至今還能記住這個故事的原因。因為我沒有想到，只是使用vim打開一個文件居然還有這樣的風險。

那么問題來了，既然vim打開文件有這樣的隱患，我們應該怎么辦呢?

大概有兩種方法，第一種是事先檢查。在使用vim打開文件之前，先使用ls命令查看一下文件的大小，如果文件過大則不要直接打開。

檢查的命令很簡單：ls -lh，ls命令很簡單，大家都知道查看目錄下文件。這里傳入了兩個參數，l表示詳細信息，包括文件類型、權限、文件大小等。但是這里顯示的文件大小是字節數，很難直接看出來有多大，所以我們需要加上一個參數h，我沒記錯的話，這個參數表示將文件大小轉化成人類可識別的形式。

比如我們不加h，得到的結果是這樣的：

加上h之后，則是這樣的：

這里的文件大小就容易理解多了。

第二種方式是使用tail代替vim查看log，tail的意思是查看文件尾部的內容。它有兩個參數非常常用，一個是-n，也就是顯示最后n行。

tail -n10 xxx.log 

我這里寫的就是顯示xxx.log文件的最后10行，這里的n也可以省略，寫成tail -10也行。

第二個參數是-f，-f的意思是表示循環輸出。因為線上的日志往往是不斷變更的，因為會有系統一直往當中寫入新的日志。我們使用-f，就可以保持同步，將源源不斷寫入的內容都打印在屏幕上。

并且-f可以和-n一起使用，表示從當前末尾n行開始一直循環輸出。

tail -30f xxx.log 

自從學會了這兩招，再也沒有因為使用vim打開巨大日志而導致系統崩潰過。

本文轉載自微信公眾號「Coder梁」，作者梁唐。轉載本文請聯系Coder梁公眾號。