Сбой mmap для больших отображений памяти (Centos 7, Kernel 3.10.0-862.el7.x86_64) - PullRequest
0 голосов
/ 07 октября 2018

Я пытался запустить сервер MySQL на одном из серверов, работающих под управлением CentOS 7. Если innodb_buffer_pool_size имеет значение выше 120 ГБ, распределение не выполняется.Внутренне он пытается отобразить большие буферы.Машина имеет 256 ГБ оперативной памяти.Поэтому я написал следующий тестовый код, который, как мне кажется, и MySQL тоже делает.Этот код также завершается с ошибкой около 130 ГБ

    #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);
}

Результат равен

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

при запуске free -g показывает

Перед запуском

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

Во время работы

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

Я что-то здесь не так делаю.Что может быть причиной этого, так как все еще много свободной памяти?

1 Ответ

0 голосов
/ 07 октября 2018

Это произошло из-за того, что / proc / sys / vm / overcommit_ratio было 50. Он может выделять больше, если overcommit_ratio изменено.

...