在 Linux 中使用 ipcrm 删除共享内存 [英] Deleting shared memory with ipcrm in Linux

问题描述

我正在使用共享内存应用程序，并使用以下命令删除段:

I am working with a shared memory application, and to delete the segments I use the following command:

 ipcrm -M 0x0000162e (this is the key)

但我不知道我是否在做正确的事情，因为当我运行 ipcs 时，我看到了相同的段，但键是 0x0000000.那么内存段真的被删除了吗?当我多次运行我的应用程序时，我看到了不同的内存段，键为 0x000000，如下所示:

But I do not know if I'm doing the right things, because when I run ipcs I see the same segment but with the key 0x0000000. So is the memory segment really deleted? When I run my application several times I see different memory segments with the key 0x000000, like this:

 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

实际发生了什么?内存段真的删除了吗?

What is actually happening? Is the memory segment really deleted?

问题是 - 如下面接受的答案所述 - 有两个进程使用共享内存，直到所有进程都关闭，内存段不会消失.

The problem was - as said below in the accepted answer - that there were two processes using the shared memory, until all the process were closed, the memory segment is not going to disappear.

推荐答案

我依稀记得在我的 UNIX(AIX 和 HPUX，我承认我从未在 Linux 中使用过共享内存)的日子里，删除只是将块标记为新客户不再附加.

I vaguely remember from my UNIX (AIX and HPUX, I'll admit I've never used shared memory in Linux) days that deletion simply marks the block as no longer attachable by new clients.

它只会在没有更多进程附加到它之后的某个时刻被物理删除.

It will only be physically deleted at some point after there are no more processes attached to it.

这与删除的常规文件相同，它们的目录信息被删除，但文件的内容只有在最后一个进程关闭它后才会消失.这有时会导致日志文件在文件系统上占用越来越多的空间，即使它们被删除，因为进程仍在写入它们，这是文件指针(指向零个或多个目录条目)之间分离"的结果到一个 inode)和文件内容(inode 本身).

This is the same as with regular files that are deleted, their directory information is removed but the contents of the file only disappear after the last process closes it. This sometimes leads to log files that take up more and more space on the file system even after they're deleted as processes are still writing to them, a consequence of the "detachment" between a file pointer (the zero or more directory entries pointing to an inode) and the file content (the inode itself).

您可以从 ipcs 输出中看到，4 个中的 3 个仍然附加了进程，因此在这些进程与共享内存块分离之前它们不会去任何地方.另一个可能正在等待一些扫描"函数来清理它，但这当然取决于共享内存的实现.

You can see from your ipcs output that 3 of the 4 still have attached processes so they won't be going anywhere until those processes detach from the shared memory blocks. The other's probably waiting for some 'sweep' function to clean it up but that would, of course, depend on the shared memory implementation.

编写良好的共享内存客户端(或与此相关的日志文件)应定期重新附加(或翻转)，以确保这种情况是暂时的，不会影响软件的运行.

A well-written client of shared memory (or log files for that matter) should periodically re-attach (or roll over) to ensure this situation is transient and doesn't affect the operation of the software.

这篇关于在 Linux 中使用 ipcrm 删除共享内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！