k8s容器内存递增问题排查
公司内所有服务基本容器化结束，全都是Java，所以内存显得也尤为重要，有部分服务的内存交给了开发优化，优化之后，发现容器监控层面的wss会持续增长。这里说下内存的wss和rss，其实之前我也不懂，涉及以下几个概念。
VSS：Virtual Set Size 虚拟耗用的内存(包含与其他进程共享占用的虚拟内存），说实话我查到的资料，这个统计的内存没用，所以没看。
RSS：Resident Set Size 实际使用的物理内存（包含与其他进程共享占用的内存） ，多个进程加载同一个共享库使用的内存只计算一次，所以RSS不能精准的表示单个进程的内存使用。
PSS：Proportional Set Size 实际使用的物理内存（按比例包含与其他进程共享占用的内存） ，多个进程加载同一个共享库使用的内存，如：3个进程使用某个共享库，使用内存3G，将把加载共享库使用的内存平均分配给这3个进程，即每个进程1G。同理当其中一个进程停止时，这1G返回给其他两个进程分享，而本身占用的内存系统回收，所以PSS也无法表示可以将进程使用的内存完全返回给系统。
USS：Unique Set Size 进程独自占用的物理内存（不包含与其他进程共享占用的内存），这个就很明显了，不计算加载共享库所占用的内存，进程停止，USS表示的内存使用量都会被系统回收。进程是否存在内存泄露，这个指标很有用。容器RSS：container_memory_rss监控指标，和上面的rss一个意思
容器WSS：container_memory_working_set_bytes监控指标
WSS字段是cgroup(/sys/fs/cgroup/memory/memory.stat) memory.usage_in_bytes（RSS + Cache）与memory.stat total_inactive_file二者的差值
在排查过程中查到一个大佬的文章 https://ormissia.github.io/posts/problems/5002-k8s-memory/#%E6%95%B0%E6%8D%AE%E6%BA%90%E8%AE%A1%E7%AE%97%E6%96%B9%E5%BC%8F
有实验步骤，看完会很清晰，我也是看完这块才知道与日志有关系，其实服务在容器化的时候已经把日志都打到前台了，日志收集都拿走了，还落了个消费mq的日志，wss的增长也是mq一个日志的大小（因为日志有切割，所以可以看到每个日志的大小），其实关键就是大佬文章中提到的total_inactive_file这个值在增长。
结论就是系统为了提高磁盘IO效率，将读写过的文件缓存在了内存，我也不抄大佬的话了，点进链接去看吧，记录就是为了让我自己号召。
我只是记录一下这次的排查，如果原文大佬看到觉得不太妥，我会调整文章的！！！
后面我又查了下 total_inactive_file 和 total_active_file，
inactive表示非活动内存页，如果内存不足时，优先回收 inactive，这部分是已经读取完的文件占用过的内存。
active表示活动内存页，这部分是当前正在读取文件所占用的内存，这个可能理解会有偏差，望有大佬修正。
博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
