我目前正在编写一个使用大量 RAM 的 python 程序。我知道我可以使用垃圾收集器来“释放”内存并避免这个问题。但是，我使用 Numba 来加速我的代码，这使得我需要释放 RAM 的部分与垃圾收集器不兼容。另外，它会减慢我的代码到它无论如何都完全没用的地步。现在我正在一台 32 GB RAM 的 MacBook Pro 上测试代码。我对软件开发略知一二，但对硬件一窍不通。我要将我的代码从 Mac 翻译到树莓派和 Nano Pi Fire 3 上。这是因为我使用的是多处理模块（Raspberry Pi 有 4 个内核，Nano Pi Fire 3 有 8 个）。我显然也在使用 MPI 模块来传递消息。我发现在简单搜索后添加更多 RAM 的一种解决方案是交换文件，在我使用的两种类型的板上设置这些文件相当容易。但是，我想知道这对于 python 代码是否真的是一个可行的选择？如果我允许 128 GB 的交换文件并使用 zRAM。这适用于其唯一目的是运行此代码的板，我会不再遇到 RAM 问题吗？
这就是为什么我认为这是 RAM 的问题：
第一个迹象是，如果我不使用 Numba 加速特定功能，那么程序运行完全正常，除了慢一点。但是，当我使用 Numba 的加速时，这是我收到的崩溃报告：
VM Region Summary:
ReadOnly portion of Libraries: Total=688.6M resident=0K(0%) swapped_out_or_unallocated=688.6M(100%)
Writable regions: Total=1.0G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=1.0G(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Dispatch continuations 32.0M 1
Kernel Alloc Once 8K 1
MALLOC 750.4M 1263
MALLOC guard page 16K 3
MALLOC_LARGE (reserved) 384K 2 reserved VM address space (unallocated)
STACK GUARD 32K 8
Stack 19.6M 8
VM_ALLOCATE 101.2M 723
VM_ALLOCATE (reserved) 160.0M 2 reserved VM address space (unallocated)
__DATA 28.3M 399
__DATA_CONST 20K 1
__FONT_DATA 4K 1
__LINKEDIT 407.9M 116
__OBJC_RO 32.2M 1
__OBJC_RW 1892K 2
__TEXT 280.7M 359
__UNICODE 564K 1
shared memory 12K 3
=========== ======= =======
TOTAL 1.8G 2894
TOTAL, minus reserved VM space 1.6G 2894
Model: MacBookPro16,1, 8 processors, 8-Core Intel Core i9, 2.3 GHz, 16 GB, SMC
因此，可以看出在我的程序中使用了很多 RAM 和交换空间。如果我找不到解决方案，或者在板上添加交换空间不起作用，那么显然我将不得不牺牲实际工作的速度。但是，如果在我可能浪费时间这样做之前知道我认为可行的解决方案实际上会起作用，那就太好了。