最近有一个人在后台工作的时候不小心打开了笔记。想起了很多往事，挑了一件有意思的，分享给大家。事情发生的时候，我还是个新手，什么都不会，完全听老大和前辈的安排。事情发生的时候，是周末。嗯，周末，自然是开心的度过了周末，出去玩，约会，吃点好吃的，或者找点好玩的。正当我高兴的时候，突然收到一条报警短信，说某台服务器宕机了。我很担心，所以我收到了师兄的消息。他说没事，我让隔壁组的同事检查了一下，应该很快就好了。听大哥这么一说我才松了口气，没想到整个服务宕机了，根本响应不了，就出现了P1故障。一般来说，这个级别的故障都有一些深刻的原因。没想到后来开故障分析会的时候，发现这个事故的原因非常非常不起眼，而且是在大家每天都用的vim中发生的。2、原来第一台机器因为OOM而宕机的情况并不少见。当时，服务器后端是用Java编写的。Java和C++最大的区别就是Java有自动垃圾回收机制，而C++只能手动释放内存。但是，Java的自动垃圾回收机制也存在很多问题。比如JVM的配置不合理，或者代码写的不优雅，造成了很多耗内存的对象。会导致内存越界错误。英文是OutOfMemory，简称OOM。这种现象在Java后端比较普遍，可能我们当时的系统确实不够优雅。本来这个问题不大，因为集群有负载均衡策略，一个服务对应多台机器。即使有一台机器宕机，上层网关在分流时也会自动避开宕机的机器，保证所有的请求都能得到响应。所以一台机器挂了也没关系，我们什么都不做等它自动重启或者请运维帮忙手动重启。迫不及待的想找隔壁群里的兄弟排查。这哥们在排错的时候，很自然的连上了服务器，然后用vim打开了系统日志。这是一行代码：vimxxxx.log3.听到报告的时候我也在纳闷。vim打开日志不是理所当然的事吗？这会导致问题吗？通常情况下，当然不是，但是这里有一个隐藏的前提是当vim打开文件时，它会加载系统内存中的文件（很明显）。既然加载到内存中，自然会消耗内存。这导致了一个问题。如果文件过大再用vim强行打开，很可能会导致系统内存不足而崩溃。这哥们那天就遇到这样的事情。他发现打开vim后ssh连接断了。他以为自己的网络有问题，于是换了一台机器连接查看日志，同样的剧本又上演了。这哥们一口气检查了所有的服务器，发现没有任何反应。他以为自己的ssh跪了，就反馈说暂时看不出问题，因为ssh跪了。举报的人没当回事，因为之前的报警只是机器挂了，不会影响服务，所以没当真。你可能会好奇，后面的机器挂了，不是报警了吗？很惭愧，我记不清这里的细节了。我猜想，只有两种可能，一种是机器中运行报警程序检测java进程，挂掉java进程可以发现java进程并报警，但是如果直接挂机起来，也没办法报警。第二种可能是他们报了警，但是他们认为是之前的问题，所以没有理会。4.这个故事当时对我触动很大，所以我至今还记得这个故事。因为没想到??光是用vim打开一个文件就有这么大的风险。那么问题来了，既然vim打开文件存在这样的隐患，那我们该怎么办呢？大概有两种方法，第一种是提前检查。在使用vim打开文件前，先用ls命令查看文件大小。如果文件太大，不要直接打开。查看的命令很简单：ls-lh，ls命令很简单，大家都知道查看目录下的文件。这里传入两个参数，l代表详细信息，包括文件类型、权限、文件大小等。但是这里显示的文件大小是字节数，很难直接看出有多大，所以我们需要添加一个参数h。如果我没记错的话，这个参数的意思是将文件大小转换成人类可识别的形式。比如我们不加h，结果是这样的：加了h之后，是这样的：这里的文件大小就容易理解多了。第二种方式是使用tail代替vim查看日志。tail表示查看文件末尾的内容。它有两个很常用的参数，一个是-n，就是显示最后n行。tail-n10xxx.log我这里写的是显示xxx.log文件的最后10行。这里的n也可以省略，也可以写成tail-10。第二个参数是-f，-f表示循环输出。因为线上的日志往往是不断变化的，因为会有一个系统不停的往里面写新的日志。如果我们使用-f，我们可以保持同步并打印不断写入屏幕的内容。而-f可以和-n一起使用，表示将从当前结束n行开始循环输出。tail-30fxxx.log自从学会这两个技巧以来，系统再也没有因为用vim打开一个巨大的日志而崩溃过。本文转载自微信公众号“码农”，作者梁堂。转载本文请联系编码员梁公众号。
