Estou investigando o impacto da memória ao conteinerizar dois processos que dependem do mesmo objeto compartilhado. Minha principal dúvida é se o objeto compartilhado será carregado na memória duas vezes ou não.
Essa pergunta já foi feita antes, mas as respostas não eram completas e contradiziam meus experimentos. Vou citar o que já encontrei:
Carregamento de bibliotecas compartilhadas e uso de RAM --> Use -fPIC para seu .so
Os contêineres docker compartilham RAM para arquivos mapeados na memória da mesma camada, mas de uma imagem diferente? --> Sim, mas depende da sua configuração. Você pode provar isso verificando o dispositivo e o id do inode do objeto compartilhado carregado. Nenhuma indicação de qual configuração usar.
https://stackoverflow.com/questions/35863608/shared-library-in-containers --> Sim, depende do seu driver de armazenamento. Os drivers de armazenamento aufs, overlay ou overlay2 oferecem suporte a isso.
https://stackoverflow.com/questions/63145223/about-loading-dynamic-library-in-container --> Cada contêiner é sua própria unidade de execução. Nenhum compartilhamento ocorre. Contradizendo com o anterior.
Usei a seguinte configuração:
- camada base --> Contém o SO e dois objetos compartilhados (G e S - Pré-compilados usando -fPIC)
- camada dependsOnG --> Começa da base, contém o executável que depende apenas de G (pré-compilado)
- camada dependsOnGandS --> Começa da base, contém o executável que depende de G e S (pré-compilado)
Driver de armazenamento: Sobreposição
Abaixo você pode ver as informações de grep glib /proc/PID/maps. Os PIDs são os processos dos executáveis dentro do contêiner.
| /proc/17/maps:7efd3b630000-7efd41980000 | r-xp | 00000000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41980000-7efd41b7f000 | ---p | 06350000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b7f000-7efd41b80000 | r--p | 0634f000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b80000-7efd41b81000 | rw-p | 06350000 | 00:a2 | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca97208000-7fca9d558000 | r-xp | 00000000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d558000-7fca9d757000 | ---p | 06350000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d757000-7fca9d758000 | r--p | 0634f000 | 00:bb | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d758000-7fca9d759000 | rw-p | 06350000 | 00:bb | 16802420 | /app/libglib.so |
Se eu interpretar o resultado corretamente, os dois processos visualizam arquivos completamente diferentes (o ID do dispositivo é diferente), portanto, o objeto compartilhado será carregado duas vezes na memória (parece consistente com o que vejo com o comando free).
De acordo com as informações que encontrei online, isso não deveria acontecer.
Tenho as seguintes perguntas:
- O objeto compartilhado deve ser carregado apenas uma vez?
- O driver de armazenamento de sobreposição suporta essa funcionalidade?
- Devo construir minhas imagens/contêineres de uma maneira diferente? (Fiz os mesmos experimentos usando volumes em vez de camadas comuns e, de fato, os arquivos eram idênticos, no entanto, não é bem isso que eu quero)
Desde já, obrigado!
Há dois motivos pelos quais você está vendo confusão neste tópico:
A resposta simples é que, por padrão , o docker compartilhará memória entre contêineres para o mesmo arquivo quando ele vier da mesma camada. Alterar o driver do Sorage pode fazer com que ele faça o contrário (conforme apontado aqui ).
Não, isso não é verdade. Dica: É bem improvável que dois arquivos idênticos acabem com o mesmo número de inode em dois sistemas de arquivos diferentes por acaso.
O comportamento que você está vendo agora está documentado na sobreposição:
https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html#inode-properties
Não sei como/quando isso mudou depois da resposta de Stephen Kitt . Sei que verifiquei os resultados na época.
Como as camadas da sua imagem do docker e a camada gravável estão todas no mesmo sistema de arquivos, então segue-se que você esperaria um dispositivo diferente (st_dev), mesmo que o mesmo objeto do sistema de arquivos subjacente tenha sido mapeado apenas uma vez. Isso ocorre porque cada contêiner tem sua própria camada gravável e, portanto, o Docker montará uma nova sobreposição para cada um.
Mas a sobreposição simplesmente passa para arquivos não modificados no sistema de arquivos subjacente.
Documentação
https://docs.docker.com/storage/storagedriver/overlayfs-driver/#the-image-layers
Não verifiquei os resultados, mas como a imagem é composta por meio de links físicos, você poderá investigar o conteúdo das camadas da imagem e confirmar que são os mesmos arquivos com um
stat <file>comando simples.Então, ao usar overlay, o conteúdo do arquivo será o mesmo arquivo armazenado no mesmo lugar no disco e não uma cópia. Dessa forma, o cache de disco só precisará carregá-lo uma vez.
O suporte para composefs está sendo adicionado ao Podman. A integração ainda não está pronta para produção, pois vejo que há bugs sendo corrigidos nas últimas semanas (julho de 2024).
Esperamos que o suporte ao composefs traga esses recursos ao executar o rootful podman:
(Os arquivos idênticos não precisam pertencer à mesma camada)
Para uma introdução ao composefs, veja esta apresentação (vídeo + slides) https://fosdem.org/2024/schedule/event/fosdem-2024-3250-composefs-and-containers/
Há um desenvolvimento em andamento para começar a usar composefs em sistemas operacionais baseados em imagem (por exemplo, Fedora Silverblue, Fedora CoreOS). No futuro, pode até ser possível obter compartilhamento de espaço em disco e cache de página para arquivos idênticos entre o host e os contêineres.