web-dev-qa-db-fra.com

Suppression de mémoire partagée avec ipcrm sous Linux

Je travaille avec une application de mémoire partagée et pour supprimer les segments, j'utilise la commande suivante:

 ipcrm -M 0x0000162e (this is the key)

Mais je ne sais pas si je fais les bonnes choses, car lorsque je lance ipcs je vois le même segment mais avec la clé 0x0000000. Le segment de mémoire est-il vraiment supprimé? Lorsque j'exécute mon application plusieurs fois, je vois différents segments de mémoire avec la clé 0x000000, comme ceci:

 key        shmid      owner      perms      bytes      nattch     status
 0x00000000 65538      me         666        27         2          dest 
 0x00000000 98307      me         666        5          2          dest 
 0x00000000 131076     me         666        5          1          dest
 0x00000000 163845     me         666        5          0

Que se passe-t-il réellement? Le segment de mémoire est-il vraiment supprimé?

Edit: Le problème était - comme indiqué ci-dessous dans la réponse acceptée - qu'il y avait deux processus utilisant la mémoire partagée, jusqu'à ce que tout le processus soit fermé, le segment de mémoire ne va pas disparaître.

shared-memoryipcs
21
Eduardo

Je me souviens vaguement de mes jours UNIX (AIX et HPUX, j'admets que je n'ai jamais utilisé de mémoire partagée sous Linux) que la suppression marque simplement le bloc comme n'étant plus attachable par les nouveaux clients.

Il ne sera physiquement supprimé qu'à un moment donné après qu'il n'y aura plus de processus attachés.

C'est la même chose qu'avec les fichiers normaux qui sont supprimés, leurs informations de répertoire sont supprimées mais le contenu du fichier disparaît uniquement après la fermeture du dernier processus. Cela conduit parfois à des fichiers journaux qui occupent de plus en plus d'espace sur le système de fichiers même après leur suppression car les processus y écrivent toujours, une conséquence du "détachement" entre un pointeur de fichier (zéro ou plusieurs entrées de répertoire pointant vers un inode) et le contenu du fichier (l'inode lui-même).

Vous pouvez voir à partir de votre sortie ipcs que 3 des 4 ont toujours des processus attachés, de sorte qu'ils n'iront nulle part jusqu'à ce que ces processus se détachent des blocs de mémoire partagée. L'autre attend probablement une fonction de "balayage" pour le nettoyer, mais cela dépendra bien sûr de l'implémentation de la mémoire partagée.

Un client bien écrit de mémoire partagée (ou de fichiers journaux d'ailleurs) devrait périodiquement se reconnecter (ou survoler) pour s'assurer que cette situation est transitoire et n'affecte pas le fonctionnement du logiciel.

22
paxdiablo

Vous avez dit que vous avez utilisé la commande suivante

ipcrm -M 0x0000162e (this is the key)

À partir de la page de manuel pour ipcrm

 -M shmkey
         Mark the shared memory segment associated with key shmkey for
         removal.  This marked segment will be destroyed after the
         last detach.

Ainsi, le comportement des options -M fait exactement ce que vous avez observé, c'est-à-dire que le segment ne doit être détruit qu'après le dernier détachement.

12
hhafez