如何转储整个系统内存？

启动VirtualBox后，计算机变得缓慢，然后由于OOM而完全挂起。通常，OOM应该开始杀死进程以释放一些空间，但这没有发生（这是我第二次遇到这种情况）。

我在文本编辑器中进行了一些未保存的重要工作，因此我希望在使用SysRq+ 杀死当前控制台中的所有进程后，将其找到系统RAM中K。有问题的机器是一台笔记本电脑，带有8 GiB RAM，运行Linux x86_64 3.7.5，并以SSD作为目标磁盘。

我的第一次尝试是dd if=/dev/mem of=memory，但是在读取1MiB数据后失败了。接下来，我尝试了dd if=/dev/fmem of=memory bs=1M，但是在读取3010461696字节（恰好是2871 MiB）之后，此操作停止了。看完/proc/mtrr（如下所示）后，我决定尝试添加skip=4096。这最终放慢了速度，读取速度仅为3 MiB / sec，所以我中断了它（产生了5.8 GiB的文件）。（至少文件的最后100个MiB包含FF）

reg01: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg05: base=0x23c000000 ( 9152MB), size=   64MB, count=1: uncachable
reg06: base=0x0b4000000 ( 2880MB), size=   64MB, count=1: uncachable
reg07: base=0x0b8000000 ( 2944MB), size=  128MB, count=1: uncachable

我在文本编辑器中找不到几个小时以来打开的数据，因此我相信在执行转储时已跳过了一些内存。因此，鉴于我的目标（从用户空间程序中恢复数据），将系统内存转储到文件中最有效的方法是什么？进行此类转储时必须考虑哪些几点？

memory data-recovery ram

— 莱肯斯坦
source

您是否也尝试过/ proc / kmem？它并不值钱，因为在您复制它时它会更改。

— ott--

@ ott-- CONFIG_DEVKMEM已禁用，在源代码中查找似乎允许不受限制的访问，但是我仍然不相信这是执行此操作的最佳方法（IO mem访问？）

— Lekensteyn

也许您确实得到了编辑器的记忆，但是您不认识它。从内存转储中重建数据结构可能很困难。您需要做的第一件事是从内核数据结构中重建内存映射（可能已经存在用于此目的的取证工具），以便获取您感兴趣的进程的虚拟内存（可能是分散在物理内存中许多不相交的4kB页上）。然后，该文本可能不在一个连续的Blob中，并且可能使用UCS4或其他表示形式，并且可能在单独的块中存储行或其他块。

— 吉尔（Gilles）'所以

@Gilles +1，一旦进程被杀死，我希望内核释放任务描述符->忘记所有有关其地址空间的映射。至于数据表示，它很容易是一棵树（JVM分配了足够的运气：）。

— peterph

因此，您将要挖掘千兆字节的数据，寻找可能甚至不存在的几kb文本？针，见干草堆。在您花费在此上的时间中，您可能只需重新输入文本即可。如果首先有那么多内容，那么您应该确保将文本编辑器配置为定期保存备份，以免崩溃时不会丢失太多内容。

— psusi

Answers:

检查此项目：foriana

Foriana是（FOrensic Ram Image ANAlyzer）

输入：（物理）RAM转储输出：各种信息

1.0版可以列出i386 / x86_64 / arm linux / bsd内核的内存转储中的进程和模块，并提供用于从转储中读取线性内存的选项。

有一个内核模块fmem：

Fmem是内核驱动程序，用于创建/ dev / fmem设备。/ dev / fmem的行为与/ dev / mem（直接访问物理内存）相同，但没有/ dev / mem的限制。可以通过/ dev / fmem转储整个物理内存。

我已经用过了，编译起来很容易。

— 堆垛机
source

质问者确实尝试了/dev/fmem。

— 东武

您可能要使用ddrescue或跳过那些无法访问的数据的类似程序。dd conv=noerror可能也会有帮助。还要在超级用户上检查此问题。

但是，更重要的是，如果您陷入OOM状况，那么呆滞很可能是由内核从请求应用程序以外的其他任何内容中换出页面引起的。因此，如果您需要数据，请检查交换而不是/dev/mem-可能在那里。同样，如果没有启动OOM杀手，并且您手动杀掉进程，则例如，一旦您的编辑器被首先杀害，则可能是内存匮乏的进程仍然会花一些时间来获取这些页面。

正如Gilles在评论中提到的那样，数据可以很容易地采用某种特殊的结构，因此即使您设法重建被终止进程的地址空间映射并有足够的运气找到所有需要的数据，也无法轻松找到它们。页面仍然完好无损。

— 彼得
source

我以前看过SU的答案，那是我找到fmem的方式。ddrescue256页（1 MiB）是硬编码的限制，因此对我没有帮助。我希望进入OOM状态，但是OOM杀手并没有介入（pastebin.com/DvYTCcRK）。一个星期前，我遇到了同样的问题（仍然是Linux 3.7.5，我没有重新启动，只是暂停了ram）。因为我有SSD，所以没有交换文件/分区。（波动性= 60（默认值））。

— Lekensteyn