作者回复: @莫名, 很赞!每次你都可以更深入的挖掘知识点!
作者回复: 是的,在系统申请物理内存的时候,如果不够,会因为释放page cache而增加延时。
对于在page cache中的dirty page, 有kernel thread会根据dirty_* 相关的参数在在后台不断的写入磁盘。不过如果发生断电,那么在内存中还没有写入的dirty page还是丢失的。
作者回复: @Alery,
可以看一下这些书,
“Advanced Programming in the UNIX Environment ”
“Linux Kernel Development ”
“Understanding the Linux Kernel”
作者回复: 即使page cache对应的文件被多个进程打开,在需要memory的时候还是可以释放page cache的。进程打开的只是文件,page cache只是cache。
free里的cache/buffer就是page cache, 早期Linux文件相关的cache内存分buffer cache和page cache, 现在统一成page cache了。 shared内存一般是tmpfs 内存文件系统的用到的内存。
作者回复: @Geek_295fee
> 1
OOM 判断还是根据 新申请的内存+ memory.usage_in_bytes - reclaim memory > memory.limit_in_bytes 来判断的。
> 2
working_set应该是cAdvsior里的一个概念,可以看一下下面的这段代码。它的定义是 memory.usage_in_bytes - inactive_file memory。不过在memory reclaim的时候,可以reclaim的memory是大于 inactive_file memory的。
https://github.com/google/cadvisor/blob/master/container/libcontainer/handler.go#L870
作者回复: @垂死挣扎的咸鱼
这个问题很有趣,inactive_file 一般是指page cache, 应该被计入cache部分, 是可以被reclaim的, 但是在你的这个例子是,这部分值被计入了rss。你可以简单说一下,你容器中的应用的工作特点吗?
编辑回复: 谢谢鼓励,咱们一起学习进步~
作者回复: 这个还要看之前page cache总共使用了多少。 如果新进程最后实际使用到的内存, 比如RSS, 和之前进程的RSS相加大于容器的内存限制,那么就会发生OOM.
作者回复: pss对共享内存的计算做了一下处理,比如100个页面是两个进程共享的,那么每个进程只记录50个页面在自己进程的pss里。
作者回复: 如果在内存很紧张的情况下,的确会出现反复reclaim cache的情况, 对磁盘读写肯定有影响。
作者回复: /proc/meminfo里只有一些统计信息,内容很少,不会占用大量的内存。
作者回复: 很开心对你有帮助!
作者回复: 我这里没有案例相关书籍。
不过学习kernel还是需要长期的坚持。
作者回复: @alpha,
你的意思是把程序迁移到容器中后,程序的内存被交换到swap空间,这时候应用会有延时?
你这里说的“当应用第一次去使用到swap的内存时”是怎么判断的?