公司内所有服务基本容器化结束,全都是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表示活动内存页,这部分是当前正在读取文件所占用的内存,这个可能理解会有偏差,望有大佬修正。