场景8：那么接着导入30g的dump,是否依旧成功呢，遗憾的是这次还是失败了， 因为发生了oom-killer，对应的线程被终止了，swap彻底释放,swap使用量一下子重置为5M了。
场景9： 这个时候再次尝试导入30g的dump,就没有问题了，不过因为在线导入，会有一些锁等待，而且对于资源的消耗着实够高，swap使用率到了10G左右
场景10: dump已经导入成功，为什么swap没有释放呢，一种方式就是重新挂载swap分区，但是让人郁闷的是还是因为内存不足。报出了下面的错误。
#swapoff -a
swapoff: /home/swapfile: swapoff failed: Cannot allocate memory
那么这种情况改怎么办，目前来看重启是一个唯一奏效的方案了。联系应用重启，但是一直没协调下来，所以就这样耽误了几天。
场景11：过了几天之后我再次查看，发现swap已经自动重置了，而重置的原因还是oom-killer，看来应该是有个连接被强制终止之后，触发了oom-killer,然后swap彻底释放。
那么这么多看起来琐碎的场景，有个问题就是为什么内存总是不足呢，除了swap还应该有些原因吧，最后发现还有一个原因就在于buffer_pool_size设置过大，本来16g的内存，结果buffer_pool_size竟然设置了24G，为什么会出现这种低级错误呢，追根溯源发现原来使用的模板只校验RedHat,没有校验CentOS，而这台服务器上安装的恰恰是centos，所以在初始化参数的时候给直接设置了成了24G,所以这个模板也存在一些问题，本身的校验逻辑还是不够严谨。
对比了一圈，发现对比有时候可以帮助我们分析问题，有的时候也会误导我们，凡事有度，当然如果做一件事情，没有任何的输出和结论，也是没有实际意义的。