一 引言
某日早上收到邮件告警信息，上报pg stale以及recovery信息，于是登录系统运维。
二 排查&解决
登录系统后发现系统已恢复正常，按照正常来讲并无影响，但系统既已出现recovery信息意味着一定有osd down发生。于是排查osd日志，发现某osd上报心跳问题。
登录到所在osd 查看osd日志，并无对应错误，但osd进程莫名其妙重启了。
查阅进程验证
意外发现大量osd进程出现重启的问题，怀疑是触发了操作系统某种机制导致进程被kill。查看osd日志，发现在进程退出时，基本上都是leveldb的日志，因为leveldb是一个内存磁盘数据库，怀疑是不是在做某种动作时出现内存不足的情况，于是验证dmesg信息，发现果然如此。
此时查看内存使用情况，发现free -g中已有swap分区被使用，另外buff+cache使用量很大。从Linux内存管理机制来讲，当有程序申请内存时，操作系统应该会逐步释放内存空间，不应会出现内存不足情况。（疑惑）
查阅部分资料，有这样一段话
Linux下允许程序申请比系统可用内存更多的内存，这个特性叫Overcommit。这样做是出于优化系统考虑，因为不是所有的程序申请了内存就立刻使用的，当你使用的时候说不定系统已经回收了一些资源了。不幸的是，当你用到这个Overcommit给你的内存的时候，系统还没有资源的话，OOM killer就跳出来了。
怀疑是否是出现了buff/cache未及时释放导致OOM机制触发，为了避免这个问题，在对系统IO进行评估后，采用手动清缓存的办法释放资源，避免出现内存不足的情况。另外，因所配内存足够，调整了swap分区参数，尽量避免使用swap分区导致性能下降。
