一桩VIM引发的血案

序言

vim国之利器，使用的多了就越来越顺手了。

for循环用多了，也是那么的顺手，但是总是有风险的。

vim风险

1 概述

在使用vim的时候，如果打开的小文件，没啥问题，如果打开的超大类型的文件，那么就会引发巨大的风险，轻则内存使用爆炸，重则引发操作系统oom。

在使用for循环的时候，循环的少，cpu的使用率不高，循环的多，那么会引起cpu飙高，轻则引发cpu load告警，重则应用的延迟增高。

查看oom的使用日志，请使用dmesg：

2 使用vim

场景中使用vi/vim打开一个文件，大小约900M，那么可以查看到如下现象：

在一个终端打开vim打开文件，另外一个终端查看messages文件：

当vim不断的加载内容到内存中时，发现内存不足，从而触发了操作系统的oom，从而杀掉了其他的进程。。。这是误杀

dashboard说，和我有什么关系，我就不过使用的内存多了点，评分高了点，比别人优秀了点，为什么要杀我。。。木秀于林风必摧之。。。辣手摧花

当使用vim进行打开大文件的时候，也会出现io告警，如下：

上图表示使用iostat -xd 3，-x表示输出扩展信息，-d表示输出所有的设备，3表示没3秒输出一次结果，也就可以看到磁盘的util飙升，会引发io告警。

在io进行告警的时候，一般是有大量的文件写入写出的结果。

3 使用python

在使用python的时候，有的时候需要读取文件，所以呢，会有各种各样的写法，经常会有个面试的题目，使用什么样的方法读取大文件。

使用read方法，会把文件的所有内容都加载进内存，最后发现内存不够，直接被杀了。。。

java的oom只是玩玩，而操作系统oom killer才是真正的毫无感情的杀手，只要触碰到了内存的底线，毫不犹豫的杀。。。

4 如何改进

被人误杀，还是可以补救的：

a 重量级的系统应该都有保活，也就是说，即使被人杀了，也能自动拉起，毕竟是重要的系统，这个时候就用到了supervisord程序；

b 运维规范：对于大文件，禁止使用vim/vi全部加载进内存的命令，应该使用more/less/tail/head/grep等命令，毕竟只有部分内存。

批量操作总是可怕的，量变到了一定程度也就变成了质变，从而会引发一系列的问题，在你平时看不到啥问题，但是一旦出现问题，那就麻烦了，当然。。。出现问题也是好的，要不然都不知道这种场景的存在。

为什么要少使用for循环，有个场景是对于docker的本地镜像太多，使用for循环来删除，从而导致出现告警：docker命令使用的时候hang住，docker进行健康检查hang住（使用的是docker exec id checkhealthy检查），在删除的时候，删除的时间越来越长，cpu load飙升，其实也就是io争抢，导致了所有cpu在等待不可中断睡眠。。。我睡了，谁也叫不醒我。。。

行车千万条，安全第一条。

很多人问我，做了之后感觉效果如何？是否存在效果，还是说是否有效果，其实我也不知道。。。别人问了，那说明我做错了，要么就是我考虑不清楚，要么就是我描述不清楚。。。

那么问题来了，做了那么多，解决了什么问题？达到了什么效果？起了什么作用？有什么价值？

还是说只是预防了一种极端情况下的错误。。。能力越大，破坏性越强。。。懂的越多，死的也快。。。反正我什么都不知道。