【问题标题】:C - Memory map a B-TreeC - 内存映射 B 树
【发布时间】:2015-03-23 14:42:24
【问题描述】:

我正在尝试对一个巨大的文件(大约 100GB)进行内存映射,以便存储具有数十亿键值对的 B-Tree。内存太小,无法将所有数据保存在内存中,因此我尝试从磁盘映射文件,而不是使用 malloc,而是返回并增加一个指向映射区域的指针。

#define MEMORY_SIZE 300000000

unsigned char *mem_buffer;
void *start_ptr;

void *my_malloc(int size) {
    unsigned char *ptr = mem_buffer;
    mem_buffer += size;

    return ptr;
}

void *my_calloc(int size, int object_size) {
    unsigned char *ptr = mem_buffer;
    mem_buffer += (size * object_size);

    return ptr;
}

void init(const char *file_path) {
    int fd = open(file_path, O_RDWR, S_IREAD | S_IWRITE);

    if (fd < 0) {
        perror("Could not open file for memory mapping");
        exit(1);
    }

    start_ptr = mmap(NULL, MEMORY_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
    mem_buffer = (unsigned char *) start_ptr;

    if (mem_buffer == MAP_FAILED) {
        perror("Could not memory map file");
        exit(1);
    }

    printf("Successfully mapped file.\n");
}

void unmap() {
    if (munmap(start_ptr, MEMORY_SIZE) < 0) {
        perror("Could not unmap file");
        exit(1);
    }

    printf("Successfully unmapped file.\n");
}

主要方法:

int main(int argc, char **argv) {

    init(argv[1]);

    unsigned char *arr = (unsigned char *) my_malloc(6);
    arr[0] = 'H';
    arr[1] = 'E';
    arr[2] = 'L';
    arr[3] = 'L';
    arr[4] = 'O';
    arr[5] = '\0';

    unsigned char *arr2 = (unsigned char *) my_malloc(5);
    arr2[0] = 'M';
    arr2[1] = 'I';
    arr2[2] = 'A';
    arr2[3] = 'U';
    arr2[4] = '\0';

    printf("Memory mapped string1: %s\n", arr);
    printf("Memory mapped string2: %s\n", arr2);

    struct my_btree_node *root = NULL;

    insert(&root, arr, 10);
    insert(&root, arr2, 20);

    print_tree(root, 0, false);

//  cin.ignore();

    unmap();

    return EXIT_SUCCESS;
}

问题是如果请求的大小大于实际内存,我会收到Cannot allocate memoryerrno 为 12),如果请求的空间在映射区域之外,我会收到Segmentation fault。有人告诉我,可以映射大于实际内存的文件。

系统会自行管理文件,还是我只负责映射可用内存量,当访问更多空间时,我必须取消映射并映射到另一个偏移量。

谢谢

编辑

操作系统:Ubuntu 14.04 LTS x86_64

bin/washingMachine:ELF 64 位 LSB 可执行文件,x86-64,版本 1 (SYSV),动态链接(使用共享库),适用于 GNU/Linux 2.6.24,BuildID[sha1]=9dc831c97ce41b0c6a77b639121584bf76deb47d,未剥离

【问题讨论】:

  • C/C++ 不是一种语言。请更具体。
  • @dandan78 对不起。完成。
  • 注意:在 mmap() 处理文件后,您可以 close() 文件描述符。
  • @KarolyHorvath 我会尝试那里提到的解决方案,如果这能解决我的问题,我会接受可能的重复。

标签: c mmap


【解决方案1】:

首先,确保您在 64 位 CPU 上以 64 位模式运行。在 32 位 CPU 上,您的进程的地址空间只有 232 字节(4 GB)大,而且无法一次将 100 GB 放入其中 - 根本不够地址。 (此外,该地址空间的很大一部分已经被其他映射使用或被内核保留。)

其次,即使映射适合地址空间,也可能会出现问题。映射到您的进程的内存(这也包括例如您的程序的代码和数据段,以及共享库的同上)被分成 pages 单元(通常在 x86 上每个 4 KB 大),其中每个页面都需要内核中的一些元数据和MMU。这是另一个在创建巨大的内存映射时可能会耗尽的资源。

按照Mmap() an entire large file 的建议,您可以尝试使用MAP_SHARED。这可能允许内核在访问其中的页面时为映射延迟分配内存,因为它知道如果内存不足,它总是可以将页面交换到磁盘上的文件中。使用MAP_PRIVATE,内核需要在每次修改页面时分配一个新页面(因为不应进行更改),如果系统耗尽内存和交换,这将是不安全的。

当分配的内存多于物理内存时,您可能还需要将MAP_NORESERVE 传递给mmap(),或者将/proc/sys/vm/overcommit_memory(请参阅proc(5))设置为1(由于系统而有点丑陋-虽然很宽)。

在我的系统上,与您的系统类似,具有 8 GB RAM 和 8 GB 交换空间,MAP_SHARED 单独足以 mmap() 40 GB 文件。 MAP_PRIVATEMAP_NORESERVE 也可以。

如果这不起作用,那么您可能会遇到与 MMU 相关的限制。许多现代 CPU 架构都支持huge pages,这是大于默认页面大小的页面。大页面的意义在于,您需要更少的页面来映射相同数量的内存(假设映射很大),这减少了元数据的数量,并且可以使地址转换和上下文切换更有效。大页面的缺点是映射粒度降低,并且在只使用页面的一小部分时会增加浪费(内部碎片)。

顺便说一句,将MAP_SHARED 和一些带有大页面的随机文件配对不太可能起作用(以防MAP_SHARED 不足以解决问题)。该文件需要位于hugetlbfs

MAP_HUGETLB 传递给mmap() 请求使用大页面进行分配(尽管它可能只是用于匿名映射,seems 现在在许多系统上应该是自动的大页面)。您可能还需要使用/proc/sys/vm/nr_hugepages/proc/sys/vm/nr_overcommit_hugepages - 请参阅this threadDocumentation/vm/hugetlbpage.txt 内核源代码中的文件。

顺便提一下,在编写自己的内存分配器时要注意对齐问题。我希望这不是太插件,但请参阅this answer

附带说明,您从内存映射文件访问的任何内存都必须实际存在于文件中。如果文件小于映射并且您仍希望能够访问“额外”内存,您可以先使用ftruncate(2) 来增大文件。 (如果文件系统支持带有文件洞的sparse files,这实际上可能不会增加它在磁盘上的大小。)

【讨论】:

    【解决方案2】:

    在不知道您使用的操作系统的情况下,我的最佳猜测是您的操作系统不允许无限过量使用内存,或者它会将MAP_PRIVATE 映射与RLIMIT_DATA ulimit 进行比较。两者都意味着你的代码不起作用。

    您基本上告诉mmapMAP_PRIVATE 是“映射此文件,但我在映射区域中所做的任何更改,都将它们视为该程序中的本地内存分配”。在这种情况下映射文件的技巧是,如果内存不足,您允许操作系统将页面写入磁盘。因为你告诉操作系统不允许写东西,所以它不能那样做。

    解决方案是使用MAP_SHARED,但请确保您了解 mmap 的手册页以及MAP_SHARED 的作用。另外,请确保您只映射文件的大小,或者ftruncate 将文件映射到您需要的大小。

    另外,请阅读 mmap 关于长度参数的手册页。一些操作系统允许大小不是页面大小的倍数,但这非常不便携,将您的大小四舍五入到页面大小。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2016-12-08
      • 2020-11-06
      • 1970-01-01
      • 2015-08-09
      • 2013-02-17
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多