On Thu, Jan 3, 2019 at 8:45 PM Fam Zheng <zhengfeiran@xxxxxxxxxxxxx> wrote:
Fixing the mm list address. Sorry for the noise.
Fam
On Jan 4, 2019, at 12:43, Fam Zheng <zhengfeiran@xxxxxxxxxxxxx> wrote:
Hi,
In our server which frequently spawns containers, we find that if a process used pagecache in memory cgroup, after the process exits and memory cgroup is offlined, because the pagecache is still charged in this memory cgroup, this memory cgroup will not be destroyed until the pagecaches are dropped. This brings huge memory stress over time. We find that over one hundred thounsand such offlined memory cgroup in system hold too much memory (~100G). This memory can not be released immediately even after all associated pagecahes are released, because those memory cgroups are destroy asynchronously by a kworker. In some cases this can cause oom, since the synchronous memory allocation failed.
Does force_empty help out your usecase? You can write tomemory.force_empty to reclaim as much as possible memory beforermdir'ing memcg. This would prevent from page cache accumulating.
Hmm, this might be an option. FWIW we have been using drop_caches to workaround. BTW, this is cgroup v1 only, I'm working on a patch to bring this backinto v2 as discussed in https://lkml.org/lkml/2019/1/3/484.We think a fix is to create a kworker that scans all pagecaches and dentry caches etc. in the background, if a referenced memory cgroup is offline, try to drop the cache or move it to the parent cgroup. This kworker can wake up periodically, or upon memory cgroup offline event (or both).
Reparenting has been deprecated for a long time. I don't think we wantto bring it back. Actually, css offline is handled by kworker now. Iproposed a patch to do force_empty in kworker, please seehttps://lkml.org/lkml/2019/1/2/377.
Could you elaborate a bit about why reparenting is not a good idea?
There is a similar problem in inode. After digging in ext4 code, we find that when creating inode cache, SLAB_ACCOUNT is used. In this case, inode will alloc in slab which belongs to the current memory cgroup. After this memory cgroup goes offline, this inode may be held by a dentry cache. If another process uses the same file. this inode will be held by that process, preventing the previous memory cgroup from being destroyed until this other process closes the file and drops the dentry cache.
I'm not sure if you really need kmem charge. If not, you may trycgroup.memory=nokmem.
A very good hint, we’ll investigate, thanks!
Fam Regards,Yang
We still don't have a reasonable way to fix this.
Ideas?
|
