容器中的共享库 [英] Shared library in containers

查看:123
本文介绍了容器中的共享库的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对于两个进程A和B,两者都使用库libc.so,而libc.so仅被加载到内存一次。当A和B都在同一主机和同一rootfs上运行时,这是正常情况。

For two processes A and B, the both use the library libc.so, libc.so is loaded into memory only once. This is a normal situation when A and B both run on the same host and the same rootfs.

对于容器,如果A和B在不同的容器中运行,A和B是否共享相同的内存区域?

When it comes to container, if A and B are running in different containers, are A and B sharing same memory area?

例如

imageA

-libc.so

-programA

imageB

-libc.so

-programB

我们使用 chroot 在不同的rootfs中运行A和B。这两个libc.so是相同的。将libc.so加载到内存两次吗?

we use chroot to run A and B in different rootfs. The two libc.so are same. Will libc.so be loaded into memory twice?

推荐答案

实际上,处理A&使用共享库libc.so 的B可以共享相同的内存。有点不直观,这取决于您使用的Docker存储驱动程序。如果使用的存储驱动程序可以将共享库文件驻留在相同的docker层中时公开为源自相同的设备/ inode,则它们将共享相同的虚拟内存缓存页面。当使用aufs,overlay或overlay2存储驱动程序时,共享库将共享内存,但是当使用任何其他存储驱动程序时,它们将不会共享内存。

Actually, processes A & B that use a shared library libc.so can share the same memory. Somewhat un-intuitively it depends on which docker storage driver you're using. If you use a storage driver that can expose the shared library files as originating from the same device/inode when they reside in the same docker layer then they will share the same virtual memory cache pages. When using the aufs, overlay or overlay2 storage drivers then your shared libraries will share memory but when using any of the other storage drivers they will not.

我不确定为什么在Docker文档中没有更清楚地表明这一细节。也许是这样,但我只是想念它。如果您要运行密集容器,这似乎是一个关键的区别。

I'm not sure why this detail isn't made more explicitly obvious in the Docker documentation. Or maybe it is but I've just missed it. It seems like a key differentiater if you're trying to run dense containers.

这篇关于容器中的共享库的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆