Search code examples
linux-kernelcentos7mmap

mmap fails for large memory mappings (Centos 7, Kernel 3.10.0-862.el7.x86_64)


I was trying to run MySQL server on one of servers running CentOS 7. If innodb_buffer_pool_size is set to above 120GB, allocation fails. Internally it is trying to mmap large buffers. Machine has 256 GB RAM. So I wrote following test code which I think is what MySQL is also doing. This code also fails at around 130 GB

    #define SIZE 1 * 1024 * 1024 * 1024


    int main() {
        unsigned long i, k = 0;
        void **ptr = NULL;
        char *mvptr = NULL;
        ptr = malloc(sizeof(void *) * 220);

        for(i = 0; i < 220;i++){
                ptr[i] = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1,0);
                printf("%d  : %lx\n",i, ptr[i]);
                if ((ptr[i] == (void *)-1))
                {
                        printf("error :%d\n",errno);
                        return 0;

                }
                else
                {
                     mvptr = ptr[i];
                     for(k = 0; k < SIZE; k++)
                         mvptr[k] = 'a';

                }

        }
        sleep(20);
        for(i = 0; i < 220;i++){
                munmap(ptr[i], SIZE);
        }
        free(ptr);
}

Result is

124  : 7fc8b2ada000
125  : 7fc872ada000
126  : 7fc832ada000
127  : 7fc7f2ada000
128  : 7fc7b2ada000
129  : ffffffffffffffff
error :12

while running free -g shows

Before running

              total        used        free      shared  buff/cache   available
Mem:            251           2         248           0           0         248
Swap:             3           0           3

While running

              total        used        free      shared  buff/cache   available
Mem:            251         130         120           0           0         120
Swap:             3           0           3

Am I doing something wrong here. What could be the reason for this since there is still lot of free memory?


Solution

  • This was because /proc/sys/vm/overcommit_ratio was 50. It is able to allocate higher if overcommit_ratio is modified.