Python 3.8 新增 multiprocessing.SharedMemory 支持共享内存

Thu 28 February 2019

Python 在 2019-02-25 释出了 3.8 早期预览版 3.8.0a2,其中新增了 multiprocessing.SharedMemory 用以支持共享内存,大大提高多进程之间通信效率。简单看了一下实现代码主要涉及如下 Python 模块

在 POSIX 平台下共享内存创建过程如下:

  1. 基于 tmpfs 打开或创建具名(文件名)的共享内存,得到文件描述符
  2. 通过 mmap 将文件描述符映射进程的内存地址空间
  3. 通过 memoryview 直接访问经过 mmap 映射后的的内存地址空间

锁的问题

memoryview 通过如下方式使用:

s = bytearray(b'aaa')
m = memoryview(s)
m[0] = 98
print(s)  # outputs: bytearray(b'baa')

当上面代码执行 m[0] = 98 时实际上调用的是 C 代码 memory_ass_sub,然后调用 PACK_SINGLE 通过 memcpy 覆盖指针原有的值。

所以直接操作 multiprocessing.SharedMemory 会产生数据竞争,不应该直接使用,应该使用 multiprocessing.Valuemultiprocessing.Array 这种更高层的抽象,锁在这一层级实现。

参见

更多关于共享内存参见:


Category: Python Tagged: Python 3.8 multiprocessing 共享 内存 shared memory

comments


Python 内存泄露实战分析

Mon 30 March 2015

引子

之前一直盲目的认为 Python 不会存在内存泄露, 但是眼看着上线的项目随着运行时间的增长 而越来越大的内存占用, 我意识到我写的程序在发生内存泄露, 之前 debug 过 logging 模块导致的内存泄露.

目前看来, 还有别的地方引起的内存泄露. 经过一天的奋战, 终于找到了内存泄露的地方, 目前项目 跑了很长时间, 在业务量较小的时候内存还是能回到刚启动的时候的内存占用.

什么情况下不用这么麻烦

如果你的程序只是跑一下就退出大可不必大费周章的去查找是否有内存泄露, 因为 Python 在退出时 会释放它所分配的所有内存, 如果你的程序需要连续跑很长时间那么就要仔细的查找是否 产生了内存泄露.

场景

如何产生的内存泄露呢, 项目是一个 TCP server, 每当有连接过来时都会创建一个连接实例来进行 管理, 每次断开时连接实例还被占用并没有释放. 没有被释放的原因肯定是因为有某个地方对连接 实例的引用没有释放, 所以随着时间的推移, 连接创建分配内存, 连接断开并没有释放掉内存, 所以 就会产生内存泄露.

调试方法

由于不知道具体是哪里引起的内存泄露, 所以要耐心的一点点调试.

由于知道了断开连接时没有释放, 所以我就不停的模拟创建连接然后发送一些包后断开连接, 然后通过下面一行 shell 来观察内存占用情况 …

Category: Python Tagged: Python 内存 泄露 引用 回收 交叉

comments

Read More
Page 1 of 1

Fork me on GitHub