Conhecendo o kernel Linux pelo /proc (parte 5) – Recursos da memória virtual

Conhecendo o kernel Linux pelo /proc (parte 5) – Recursos da memória virtual

No post anterior vimos comportamentos relacionados ao uso de memória de virtual, como a “sobre-alocação” de memória, uso de SWAP, estouro de memória RAM e o que pode ocorrer em máquinas com uma grande quantidade de memória RAM. Neste post vamos abordar recursos disponíveis através da memória virtual, como a memória compartilhada, o Page Cache e a abstração da arquitetura NUMA.

Memória compartilhada

Apesar da memória virtual isolar a área de memória de processos distintos, existem situações onde diferentes processos precisam se comunicar e compartilhar recursos entre si. Nestes cenários o kernel oferece o recurso de memória compartilhada, que permite que uma determinada região da memória seja compartilhada entre diversos processos.

Existem diversas formas de realizar o compartilhamento de memória no Linux, no entanto, para simplificar a implementação interna do Kernel, todos os métodos acabam realizando o mapeamento de um arquivo em memória, seja de forma explícita, ou implícita através de arquivos nos filesystems do tipo “tmpfs”.

MMAP com arquivo mapeado

A forma mais simples de compartilhar memória entre processos é abrir o mesmo arquivo em dois processos e realizar o mapeamento do arquivo em memória através da chamada “mmap” com a flag MAP_SHARED.

Para mostrar como isso funciona criamos o “shared_mem_mmap.c”, que abre um arquivo cujo o nome é definido através do seu primeiro parâmetro de execução, e em seguida é mapeado em memória com a flag “MAP_SHARED”. A ideia deste exemplo é simular uma situação onde diversos processos precisam compartilhar uma mesma configuração através da memória e por isso, assim que iniciado ele entra em looping onde o usuário pode alterar a “configuração”, visualizá-la ou encerrar sua execução.

Outro ponto importante, é que logo após a visualização da “configuração” forçamos a leitura de toda área de memória somente com propósito de forçar a alocação completa e assim poder observar como ela se comporta no “/proc”.

#include <stdio.h>
#include <sys/mman.h>
#include <string.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>



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

        char *ptr, tmp;
	char option;
	struct stat st;
	int fd;
	size_t count=0;


	fd = open(argv[1],O_RDWR);
	if( fd < 0 ){
		printf("Falha ao abrir o arquivo\n");
		return 1;
	}
        stat(argv[1],&st);

        ptr=mmap(NULL,st.st_size,PROT_WRITE,MAP_SHARED,fd,0);
        if( ptr == MAP_FAILED ){
                printf("Falha ao realizar o mapeamento\n");
                return 1;
        }



	while(1){
		printf("Acoes:\n (1)Exibir configuração atual\n (2)Alterar a configuração\n (3)Encerrar\n");
		printf("Digite a opçao:");
		option= (char) getchar();
		while ((getchar()) != '\n');
		switch(option){
			case '1':
				printf("Configuração atual:\n");
                		printf("%s\n",ptr);
				for(count=0;count < st.st_size;count++){
					tmp = *(ptr+count); 
				}
				break;
			case '2':
				printf("Digite a nova configuração:\n");
                		fgets(ptr,st.st_size,stdin);
				printf("\n");
				break;
			case '3':
				printf("\nEncerrando\n");
				break;
			default :
				printf("\nInvalid Option");
		}
		if(option == '3'){
			break;
		}
	}
	


        munmap(ptr,st.st_size);
	close(fd);
}

Para realizar os testes com o nosso programa, inicialmente vamos gerar o nosso arquivo de “configuração”, denominado “file.cfg”, com 100MB através da ferramenta “dd” e em seguida vamos executá-lo em um terminal conforme os passos abaixo:

$ gcc shared_mem_mmap.c -o shared_mem_mmap.o
$ dd if=/dev/zero of=file.cfg bs=1048576 count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0,286279 s, 366 MB/s
$ free -m
              total        used        free      shared  buff/cache   available
Mem:          19947        2970       10354         667        6622       15949
Swap:          2047           0        2047
$ ./shared_mem_mmap.o file.cfg 
Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:2
Digite a nova configuração:
iniciando config

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:1
Configuração atual:
iniciando config

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:

Agora, em um segundo terminal, vamos consultar o processo “free -m” e o “/proc/PID/status” para verificar como está seu consumo de memória:

# free -m
              total        used        free      shared  buff/cache   available
Mem:          19947        2973       10237         667        6736       15945
Swap:          2047           0        2047
# cat /proc/$(pgrep shared_mem_mmap)/status | egrep 'Vm|Rss'
VmPeak:	  106908 kB
VmSize:	  106908 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	  101716 kB
VmRSS:	  101716 kB
RssAnon:	      80 kB
RssFile:	  101636 kB
RssShmem:	       0 kB
VmData:	     176 kB
VmStk:	     132 kB
VmExe:	       4 kB
VmLib:	    2112 kB
VmPTE:	     256 kB
VmSwap:	       0 kB

Na saída acima, vemos um comportamento curioso, mesmo após utilizarmos os 100MB de memória, o “free” ainda mostra aproximadamente a mesma quantidade de memória disponível (available) e utilizada (used). Isso ocorre, pois o arquivo é carregado em memória através do “Page Cache”, onde o uso de memória é computado como cache e é exibido através da coluna “buff/cache” no “free”.

Através do campo VmRSS podemos ver que nosso processo está consumindo por volta 100MB de memória RAM e através do campo RssFile podemos ver que praticamente todo este consumo se trata do arquivo mapeado em memória. Neste caso sabemos qual é o arquivo responsável por este consumo, porém, na vida real, poderíamos descobrir qual é o arquivo analisando conteúdo do “/proc/PID/smaps”, conforme exemplo abaixo:

# cat /proc/$(pgrep shared_mem_mmap)/smaps | egrep -B4 -i 'Rss' 
56015416f000-560154170000 r-xp 00000000 08:02 114426097                  /home/william/Documents/memory-tests/shared_mem_mmap.o
Size:                  4 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                   4 kB
--
....
--
56015507c000-56015509d000 rw-p 00000000 00:00 0                          [heap]
Size:                132 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                   4 kB
--
7f5bed860000-7f5bf3c60000 -w-s 00000000 08:02 114426317                  /home/william/Documents/memory-tests/file.cfg
Size:             102400 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:              102400 kB
--
7f5bf3c60000-7f5bf3e47000 r-xp 00000000 08:02 10223863                   /lib/x86_64-linux-gnu/libc-2.27.so
Size:               1948 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                1248 kB
--
...
--
7ffed7d27000-7ffed7d48000 rw-p 00000000 00:00 0                          [stack]
Size:                132 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                  12 kB
--
7ffed7da9000-7ffed7dac000 r--p 00000000 00:00 0                          [vvar]
Size:                 12 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                   0 kB
--
7ffed7dac000-7ffed7dae000 r-xp 00000000 00:00 0                          [vdso]
Size:                  8 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                   4 kB
--
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Size:                  4 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                   0 kB
#  cat /proc/$(pgrep shared_mem_mmap)/smaps | egrep -A20 -i 'file.cfg' 
7f5bed860000-7f5bf3c60000 -w-s 00000000 08:02 114426317                  /home/william/Documents/memory-tests/file.cfg
Size:             102400 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:              102400 kB
Pss:              102400 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:    102400 kB
Private_Dirty:         0 kB
Referenced:       102396 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
VmFlags: wr sh mr mw me ms sd 

Na execução acima, inicialmente procuramos pelo arquivo com maior consumo de memória e em seguida realizamos um novo filtro exibindo somente o estado do mapeamento deste arquivo.

De posse dos dados presentes no “smaps” podemos concluir que:

  • O “file.cfg” é o maior consumidor de memória, pois tem o maior valor de “Rss”
  • O “file.cfg” é o maior arquivo mapeado, pois tem o maior valor no campo “Size”
  • O “file.cfg” foi acessado em quase sua totalidade, já que o campo “Referenced” é muito próximo ao campo “Size”
  • O “file.cfg” deve estar sendo acessado somente por este programa, pois o campo PSS é igual ao tamanho do arquivo
  • O mapeamento do “file.cfg” é do tipo compartilhado com permissão escrita, pois possui as flags “sh” e “wr” no campo “VmFlags”

Vale explicar que o campo PSS tenta dar uma ideia de proporcionalidade do uso de memória RAM por processo quando temos uso de memória compartilhada. Ou seja, ele basicamente irá dividir o tamanho de memória mapeada pelo número de processos que a compartilham. No nosso exemplo temos apenas um processo acessando a área de memória compartilhada, por isso o PSS é igual ao tamanho da área de memória.

Agora, em um terceiro terminal, vamos executar mais um processo do “shared_mem_mmap” apontando para o mesmo arquivo de “configuração”:

$ ./shared_mem_mmap.o file.cfg
Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:1
Configuração atual:
iniciando config

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:

Neste ponto, podemos ver que, de fato, a memória esta sendo compartilhada, pois, ao selecionar a opção “Exibir a configuração” temos o mesmo conteúdo inserido no processo do primeiro terminal. Agora, só para validar o funcionamento do processo inverso, vamos alterar a “configuração” através do processo do terceiro terminal:

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:2
Digite a nova configuração:
NOVA CONFIGURACAO

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:

Agora, se visualizarmos o conteúdo no primeiro terminal, teremos a “configuração” atualizada:

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:1
Configuração atual:
NOVA CONFIGURACAO

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:

Outro ponto que podemos observar, é o valor do campo PSS no /proc/PID/smaps, que agora deve ser a metade do tamanho da memória, já que temos 2 processos compartilhando este mesmo segmento:

cat /proc/$(pgrep --oldest shared_mem_mmap)/smaps | egrep -A20 -i 'file.cfg' 
7f5bed860000-7f5bf3c60000 -w-s 00000000 08:02 114426317                  /home/william/Documents/memory-tests/file.cfg
Size:             102400 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:              102400 kB
Pss:               51202 kB
Shared_Clean:     102396 kB
Shared_Dirty:          0 kB
Private_Clean:         4 kB
Private_Dirty:         0 kB
Referenced:       102400 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
VmFlags: wr sh mr mw me ms sd 

MMAP com mapeamento anônimo

O MMAP também nos permite realizar o compartilhamento de memória através de um mapeamento anônimo, no entanto, neste caso o compartilhamento só será possível com processos filhos. Para realizar este tipo de mapeamento basta incluir a flag MAP_SHARED assim como foi feito no método anterior.

Para mostrar como isso funciona criamos o “shared_mem_mmap_anonymous.c”, onde realizamos um mapeamento de memória anônimo de 100MB com a flag “MAP_SHARED”. A ideia deste exemplo é simular uma situação onde temos um processo pai que efetua a gerência de “configurações” e um processo filho responsável por gerar logs. Neste caso o nosso processo de log será responsável por registrar em log as “configurações” atuais a cada 5 segundos. Assim como no exemplo anterior, no momento em que é iniciado, ele entra em looping onde o usuário pode alterar a “configuração”, visualizá-la ou encerrar sua execução.

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <string.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <signal.h>



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

        char *ptr;
	char option;
	size_t size = 1024*1024*100;
	int pid;


        ptr=mmap(NULL,size,PROT_WRITE,MAP_SHARED|MAP_ANONYMOUS,-1,0);
        if( ptr == MAP_FAILED ){
                printf("Falha ao realizar o mapeamento\n");
                return 1;
        }

	pid=fork();
	if(pid>0){

		while(1){
			printf("Acoes:\n (1)Exibir configuração atual\n (2)Alterar a configuração\n (3)Encerrar\n");
			printf("Digite a opçao:");
			option= (char) getchar();
			while ((getchar()) != '\n');
			switch(option){
				case '1':
					printf("Configuração atual:\n");
       		         		printf("%s\n",ptr);
					break;
				case '2':
					printf("Digite a nova configuração:\n");
                			fgets(ptr,size,stdin);
					printf("\n");
					break;
				case '3':
					printf("\nEncerrando\n");
					kill(pid,SIGTERM);
					break;
				default :
					printf("\nInvalid Option");
			}
			if(option == '3'){
				break;
			}
		}
	}else if(pid==0){
		FILE* log;
		log = fopen("/tmp/memory.log", "w+"); 
		
		if(log==NULL){
			printf("Falha ao abrir arquivo de log\n");
			return 1;
		}  
	        
	        fprintf(log,"Iniciando Logger\n");
		fflush(log);

		while(1){
			sleep(5);
			fprintf(log,"%s\n",ptr);
			fflush(log);
		}
		fclose(log);
	}else{
		printf("Falha ao criar processo\n");
		return 1;
	}


        munmap(ptr,size);
}

Para realizar os testes com o nosso programa, inicialmente vamos executá-lo em um terminal e observar seus logs em um segundo terminal, conforme os passos abaixo:

$ free -m 
              total        used        free      shared  buff/cache   available
Mem:          19947        3087        8567         731        8293       15768
Swap:          2047           0        2047
$ ./shared_mem_mmap_anonymous.o 
Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:1
Configuração atual:

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:2
Digite a nova configuração:
nova config

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar

Agora, em um segundo terminal vamos validar a presença do processo filho, verificar se o log está funcionando corretamente e como está o uso de memória:

# free -m 
              total        used        free      shared  buff/cache   available
Mem:          19947        3086        8465         831        8394       15668
Swap:          2047           0        2047
# ps auxf | grep  mmap
william   4944  0.0  0.5 106908 103748 pts/1   S+   22:56   0:00  |   |   \_ ./shared_mem_mmap_anonymous.o
william   4945  0.0  0.0 106908    72 pts/1    S+   22:56   0:00  |   |       \_ ./shared_mem_mmap_anonymous.o
# cat /tmp/memory.log 
Iniciando Logger





nova config

nova config

nova config
# cat /proc/$(pgrep -o shared_mem_mmap)/status | egrep 'Vm|Rss'
VmPeak:	  106908 kB
VmSize:	  106908 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	  103748 kB
VmRSS:	  103748 kB
RssAnon:	      80 kB
RssFile:	    1324 kB
RssShmem:	  102344 kB
VmData:	     176 kB
VmStk:	     132 kB
VmExe:	       4 kB
VmLib:	    2112 kB
VmPTE:	     252 kB
VmSwap:	       0 kB

Através da saída acima, podemos ver que temos um processo filho sendo executado e que o log está sendo gerado corretamente no arquivo “/tmp/memory.log”. Outro ponto que podemos observar aqui, é que neste caso é possível diferenciar essa área de memória compartilhada da área de “Page Cache” utilizada pelos arquivos mapeados em memória, isso é visto no campo RssShmem no “/proc/PID/status” e no free através do campo “shared”.

Essa diferenciação de uso é possível, pois, para realizar este tipo de compartilhamento o Kernel cria um arquivo a partir do “/dev/zero” e o armazena no “tmpfs”, em um ponto de montagem restrito ao Kernel (não visível ao VFS), e que pode pode ter seu consumo monitorado através do campo “Shmem” do “/proc/meminfo” conforme os comandos abaixo:

# grep 'Shmem:' /proc/meminfo 
Shmem:           850944 kB
# cat /proc/$(pgrep --oldest shared_mem_mmap)/smaps | egrep -A20 -i 'zero'
7f90484eb000-7f904e8eb000 -w-s 00000000 00:05 161584                     /dev/zero (deleted)
Size:             102400 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:              102400 kB
Pss:              102398 kB
Shared_Clean:          0 kB
Shared_Dirty:          4 kB
Private_Clean:    102396 kB
Private_Dirty:         0 kB
Referenced:       102400 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
VmFlags: wr sh mr mw me ms sd 

SysVIPC

Outra maneira de realizar compartilhamento de memória é através do System V IPC, que é um mecanismo de comunicação interprocessos disponível na maior parte do sistemas Unix. Além de memória compartilhada ele também permite o uso de filas de mensagens e semáforos.

O SysVIPC nos permite compartilhar um determinado segmento de memória entre diversos processos. Para isso, ele fornece as chamadas “shmget” e “shmat”, que nos permitem criar e anexá-las a um determinado segmento de memória.

Para ilustrar como isso funciona criamos o “shared_mem_sysvipc.c”, onde realizamos criação de um segmento de memória identificado pelo número 334, de 100MB através do “shmget” e em seguida anexamos esse segmento através da “shmat”. Neste caso podemos iniciar diversos processos, pois como todos utilizam a mesma chave “334”, todos utilizarão o mesmo segmento de memória. Assim como no exemplo anterior, no momento que é iniciado, ele entra em looping e o usuário pode alterar a “configuração”, visualizá-la ou encerrar sua execução.

#include <stdio.h>
#include <sys/mman.h>
#include <string.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ipc.h>
#include <sys/shm.h>



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

        char *ptr, tmp;
	char option;
	int shm_id;
	size_t size = 1024*1024*100;
	size_t count;


	shm_id=shmget(334,size,IPC_CREAT|0666);

        if( shm_id < 0 ){
                printf("Falha alocacao de memoria \n");
                return 1;
        }
	
	ptr = shmat(shm_id,NULL,0);
        if( (void *) ptr < 0 ){
                printf("Falha em atachar memoria compartilhada \n");
                return 1;
        }




	while(1){
		printf("Acoes:\n (1)Exibir configuração atual\n (2)Alterar a configuração\n (3)Encerrar\n");
		printf("Digite a opçao:");
		option= (char) getchar();
		while ((getchar()) != '\n');
		switch(option){
			case '1':
				printf("Configuração atual:\n");
                		printf("%s\n",ptr);
				for(count=0;count<size;count++){
                                        tmp = *(ptr+count);
                                }

				break;
			case '2':
				printf("Digite a nova configuração:\n");
                		fgets(ptr,size-1024,stdin);
				printf("\n");
				break;
			case '3':
				printf("\nEncerrando\n");
				break;
			default :
				printf("\nInvalid Option");
		}
		if(option == '3'){
			break;
		}
	}
	


	shmdt(ptr);
	shmctl(shm_id,IPC_RMID,NULL);
}

Para realizar os testes com o nosso programa, inicialmente vamos executá-lo em um terminal e observar seus logs em um segundo terminal, conforme os passos abaixo:

$ gcc shared_mem_sysvipc.c -o shared_mem_sysvipc.o  
$ free -m
              total        used        free      shared  buff/cache   available
Mem:          19947        3747        2610        1161       13589       14679
Swap:          2047           0        2047
$ ./shared_mem_sysvipc.o 
Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:1
Configuração atual:

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:2
Digite a nova configuração:
Teste Config

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:

Agora, em um segundo terminal, vamos executar mais um processo do nosso programa e exibir o conteúdo da “configuração atual” para validar se a memória realmente está compartilhada:

$ ./shared_mem_sysvipc.o 
Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:1
Configuração atual:
Teste Config

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao: 

Com as duas instâncias do nosso programa em execução, em um terceiro terminal, vamos verificar como ficou o consumo de memória:

# free -m
              total        used        free      shared  buff/cache   available
Mem:          19947        3752        2470        1261       13724       14573
Swap:          2047           0        2047
# grep 'Shmem:' /proc/meminfo 
Shmem:           1292200 kB
# cat /proc/$(pgrep --oldest shared_mem_ )/smaps | egrep -A20 -i 'deleted'
7f3c11582000-7f3c17982000 rw-s 00000000 00:05 3440674                    /SYSV0000014e (deleted)
Size:             102400 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:              102400 kB
Pss:               51200 kB
Shared_Clean:     102396 kB
Shared_Dirty:          4 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:       102400 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
VmFlags: rd wr sh mr mw me ms sd 

Conforme podemos ver acima, neste caso também é possível identificar o uso da memória compartilhada através do campo “shared” do free e através do campo “Shmem” do “/proc/meminfo”. A principal diferença neste caso é que o arquivo não é gerado a partir do “/dev/zero”, e sim, gerado a partir de um arquivo com cuja nomeclatura é “SYSV” seguido do identificador do segmento, que no nosso caso é 334, 14e em hexadecimal.

Outro ponto importante, é que no caso do SysVIPC, existem alguns limites configuráveis através do “/proc”, que são:

  • /proc/sys/kernel/shmmax: define o tamanho máximo de um segmento de memória compartilhado
  • /proc/sys/kernel/shmall: define a quantidade máxima de memória a ser utilizada em todo o sistema por segmentos de memória compartilhados
  • /proc/sys/kernel/shmmni: define a quantidade máxima de segmentos de memória compartilhados no sistema

Na execução abaixo, vemos que, devido ao programa utilizar um segmento de 100MB de memória, se reduzirmos o limite para 90MB teremos falha na alocação de memória:

# cat /proc/sys/kernel/shmmax 
18446744073692774399
# echo 94371840 >  /proc/sys/kernel/shmmax
# ./shared_mem_sysvipc.o 
Falha alocacao de memoria 
# echo 18446744073692774399 > /proc/sys/kernel/shmmax
# ./shared_mem_sysvipc.o 
Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:3

Encerrando

POSIX

Por fim, ainda temos o compartilhamento de memória através do padrão POSIX, que consiste em abrir/criar um “pseudo” arquivo através da chamada “shm_open” e em seguida mapeá-lo em memória através da chamada “mmap” com a flag “MAP_SHARED”.

Para demonstrar seu funcionamento criamos o “shared_mem_posix.c”, que abre/cria um “pseudo” arquivo através do “shm_open” cujo o nome é definido através do seu primeiro parâmetro de execução, em seguida definimos seu tamanho através da chamada “ftruncate” e por fim realizamos o mapeamento em memória através da chamada “mmap” com a flag “MAP_SHARED”. Assim como nos exemplos anteriores, a ideia deste exemplo é simular uma situação onde diversos processos precisam compartilhar uma configuração através da memória e por isso, assim que iniciado ele entra em looping onde o usuário poderá alterar a “configuração”, visualizá-la ou encerrar sua execução.

#include <stdio.h>
#include <sys/mman.h>
#include <string.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>



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

        char *ptr, tmp;
	char option;
	size_t size = 1024*1024*100;
	size_t count;
	int fd;


	
	fd = shm_open(argv[1],O_RDWR|O_CREAT,S_IRWXU);
	if( fd <0 ){
		printf("Falha ao abrir o arquivo\n");
		return 1;
	}
	ftruncate(fd,size);

        ptr=mmap(NULL,size,PROT_WRITE,MAP_SHARED,fd,0);
        if( ptr == MAP_FAILED ){
                printf("Falha ao realizar o mapeamento\n");
                return 1;
        }



	while(1){
		printf("Acoes:\n (1)Exibir configuração atual\n (2)Alterar a configuração\n (3)Encerrar\n");
		printf("Digite a opçao:");
		option= (char) getchar();
		while ((getchar()) != '\n');
		switch(option){
			case '1':
				printf("Configuração atual:\n");
                		printf("%s\n",ptr);
				for(count=0;count<size;count++){
                                        tmp = *(ptr+count);
                                }
				break;
			case '2':
				printf("Digite a nova configuração:\n");
                		fgets(ptr,size,stdin);
				printf("\n");
				break;
			case '3':
				printf("\nEncerrando\n");
				break;
			default :
				printf("\nInvalid Option");
		}
		if(option == '3'){
			break;
		}
	}
	


        munmap(ptr,size);
	shm_unlink(argv[1]);
}

Para realizar os testes com o nosso programa, vamos executá-lo inicialmente em um primeiro terminal, conforme os passos abaixo:

$ gcc shared_mem_posix.c -o shared_mem_posix.o -lrt
$ free -m
              total        used        free      shared  buff/cache   available
Mem:          19947        8971        1333        1410        9641        9203
Swap:          2047          65        1982
$ ./shared_mem_posix.o blog4linux
Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:2
Digite a nova configuração:
ConfigV2

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:1
Configuração atual:
ConfigV2

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:

Agora, em um segundo terminal, vamos executar mais um processo do nosso programa e exibir o conteúdo da “configuração atual” para validar se a memória realmente está compartilhada:

$ ./shared_mem_posix.o blog4linux
Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:1
Configuração atual:
ConfigV2

Acoes:
 (1)Exibir configuração atual
 (2)Alterar a configuração
 (3)Encerrar
Digite a opçao:

Em um terceiro terminal, vamos analisar o uso de memória deste meétodo de compartilhamento de memória:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:          19947        8975        1229        1510        9742        9100
Swap:          2047          65        1982
$ grep 'Shmem:' /proc/meminfo
Shmem:           1547044 kB
$ cat /proc/$(pgrep -o shared_mem_)/status | egrep 'Vm|Rss'
VmPeak:	  111172 kB
VmSize:	  111172 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	  101768 kB
VmRSS:	  101768 kB
RssAnon:	     112 kB
RssFile:	    1504 kB
RssShmem:	  100152 kB
VmData:	     212 kB
VmStk:	     132 kB
VmExe:	       4 kB
VmLib:	    2244 kB
VmPTE:	     260 kB
VmSwap:	       0 kB
$ cat /proc/$(pgrep --oldest shared_mem_ )/smaps | egrep -A20 -i 'blog4linux'
7fd420ed2000-7fd4272d2000 -w-s 00000000 00:18 679                        /dev/shm/blog4linux
Size:             102400 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:              102400 kB
Pss:               51200 kB
Shared_Clean:     102396 kB
Shared_Dirty:          4 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:       102400 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
VmFlags: wr sh mr mw me ms sd 
$ ls -lh  /proc/$(pgrep --oldest shared_mem_ )/fd
total 0
lrwx------ 1 william william 64 dez  4 01:24 0 -> /dev/pts/15
lrwx------ 1 william william 64 dez  4 01:24 1 -> /dev/pts/15
lrwx------ 1 william william 64 dez  4 01:24 2 -> /dev/pts/15
lrwx------ 1 william william 64 dez  4 01:24 3 -> /dev/shm/blog4linux
$ ls -lh  /dev/shm/blog4linux 
-rwx------ 1 william william 100M dez  4 01:17 /dev/shm/blog4linux
$ mount | grep shm
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
$ cat /dev/shm/blog4linux 
ConfigV3

Como podemos ver na saída acima, seu comportamento é bem similar ao dos métodos anteriores, onde é possível identificar o uso de memória compartilhada através de “shared” do free e do campo “Shmem” no “/proc/meminfo”. A grande diferença neste caso, é que o nosso pseudo arquivo “blog4linux”, é criado em um tmpfs que se encontra montado em “/dev/shm”, e que é visível para os usuários.

Observações:

Um ponto importante a se observar é que em todos os casos é possível ver que o “free” também mostra um aumento do consumo de memória na coluna “buffer/cache”. Isso ocorre devido a todos os métodos trabalharem utilizando arquivos carregados em memória, seja de forma implícita ou explícita, de forma que essas páginas de memória acabam sendo gerenciadas pelo “Page Cache”.

Page cache

O “Page Cache” é um recurso do Kernel destinado a “cachear” arquivos em memória de forma transparente e dinâmica, ou seja, toda vez que realizamos um mapeamento de arquivo em memória, ou que realizamos a leitura/escrita de um arquivo em disco, o Kernel irá armazenar o arquivo em memória – sempre que existir memória RAM disponível no sistema.

Esse recurso, além de evitar leituras desnecessárias em disco, também permite a escrita atrasada no disco, pois a escrita é realizada primeiramente nas páginas do “Page Cache”, as quais posteriormente serão efetivamente escritas em disco.

As páginas contendo dados ainda não escritos em disco disco são chamadas de “página sujas”, e podem ser “limpas”(escritas efetivamente em disco) de diversas formas: por tempo máximo de execução, de forma explícita por um chamada “fsync” na aplicação , pelo comando sync, ou por estar próxima dos seus limites de armazenamento de páginas sujas.

Vale lembrar que mesmo que a área utilizada alocada pelo “Page Cache” seja grande, apenas as páginas sujas realmente importam para efeitos de uso de memória, pois as páginas limpas podem ser liberadas instantaneamente caso o sistema necessite de memória.

Por ser dinâmico e ter a tendência de utilizar toda a memória disponível no sistema operacional, este recurso causava muita confusão a respeito do uso real de memória em distribuições mais antigas, onde o comando “free” não exibia a coluna “available”, de forma que muitos acreditavam que a memória disponível no sistema era exibida na coluna “free”, e que seu sistema estava constantemente no limite de memória.

Para acompanhar o consumo de memória do “Page Cache” em mais detalhes podemos inspecionar o “/proc/meminfo” conforme os comandos abaixo:

# grep 'Cached' /proc/meminfo 
Cached:          7573200 kB
# grep 'Dirty' /proc/meminfo 
Dirty:              3884 kB

No comando acima podemos ver que, apesar de termos aproximadamente 7,2GB de memória sendo utilizada para o cache, apenas 3,7MB deles são páginas sujas, o que significa que temos praticamente 7GB de memória disponível para o sistema caso seja necessário.

Para efeito de execução de testes de desempenho, o Kernel permite realizar um descarte das página limpas do cache de maneira forçada escrevendo o número “1” no “/proc/sys/vm/drop_caches”.

# grep 'Cached' /proc/meminfo 
Cached:          5586108 kB
# echo 1 > /proc/sys/vm/drop_caches 
# grep 'Cached' /proc/meminfo 
Cached:          2637628 kB

No exemplo acima vimos que após realizar o “drop_caches”, o “Page Cache” foi reduzido de aproximadamente 5,3GB para 2,6GB. A redução normalmente não é total pois temos as páginas sujas e também devido aos mecanismos de memória compartilhada utilizarem esta área de memória para armazenar seus segmentos de memória.

Somente para se ter uma ideia da diferença de desempenho entre a leitura de um arquivo em “cache” e outro sem “cache” criamos o “file_reader.c”, que apenas realiza a leitura completa de um arquivo definido por parâmetro:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

int main(int argc, char *argv[]){
	int fd;
	char buff[100];
	fd=open(argv[1],O_RDWR);
	while(read(fd,buff,100)){
	}

}

Para realizar nosso teste de desempenho, inicialmente iremos criar um arquivo de 100MB através do “dd” e seguida iremos executar o “file_reader.c” duas vezes com o comando time, sendo a segunda execução após uma limpeza do “Page Cache”, conforme mostrado nos comandos abaixo:

$ gcc file_reader.c -o file_reader.o
$ sudo su
# dd bs=1048576 count=100 if=/dev/zero of=file
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0,358191 s, 293 MB/s
# time ./file_reader.o file

real	0m0,707s
user	0m0,341s
sys	0m0,360s
# echo 1 > /proc/sys/vm/drop_caches
# time ./file_reader.o file

real	0m5,608s
user	0m0,766s
sys	0m0,973s

Na execução acima é bem claro o ganho desempenho, quando temos o cache populado: a leitura levou apenas aproximadamente 700ms, enquanto que, quando temos o cache limpo a leitura levou mais de 5 segundos, ou seja, sem o cache a leitura do arquivo levou praticamente 5 vezes mais tempo para ser realizada.

Para realizar um teste de desempenho de gravação vamos utilizar o próprio comando “dd”, criando duas vezes um arquivo de 100MB, uma vez utilizando a flag “sync” que força um fsync a cada escrita e uma segunda execução sem a flag “sync”, ou seja deixando para que o mecanismo de limpeza do “Page Cache” realize a escrita em disco posteriormente, conforme podemos ver nos comandos abaixo:

$dd bs=1048576 count=100 if=/dev/zero of=file oflag=sync
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 16,5911 s, 6,3 MB/s
$ dd bs=1048576 count=100 if=/dev/zero of=file
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0,286432 s, 366 MB/s

Nos resultados acima, também vimos um claro ganho de desempenho quando deixamos o “Page Cache” trabalhar, uma diferença de 366MB por segundo para 6MB por segundo quando forçamos a sincronia das operações de escrita e praticamente deixamos de usar o “Page Cache” para isso.

No entanto, o que muitos devem estar se perguntando é: quando não forçamos a sincronia, em quanto tempo teremos esse arquivo escrito em disco? Pois se ocorrer um crash neste período podem ocorrer perdas de dados….

A resposta é: normalmente é muito rápido, porém depende de vários fatores que vamos ver mais a frente, mas, somente a título de curiosidade podemos acompanhar (através de um segundo terminal) o campo Dirty do “/proc/meminfo” durante a criação do arquivo.

# while [ 1=1 ] ; do  grep 'Dirty' /proc/meminfo; sleep 2 ; done
Dirty:               400 kB
Dirty:               480 kB
Dirty:               548 kB
Dirty:               724 kB
Dirty:                84 kB
Dirty:            839856 kB
Dirty:            754104 kB
Dirty:            559932 kB
Dirty:            385148 kB
Dirty:            262432 kB
Dirty:            145812 kB
Dirty:               284 kB
Dirty:               272 kB
Dirty:              1376 kB
Dirty:              1544 kB
Dirty:              1944 kB
Dirty:              2084 kB
Dirty:               568 kB
$ dd bs=1048576 count=1000 if=/dev/zero of=file
1000+0 records in
1000+0 records out
1048576000 bytes (1,0 GB, 1000 MiB) copied, 13,1907 s, 79,5 MB/s

Na execução acima, vemos que tivemos um pico de aproximadamente 820MB de páginas sujas, as quais levaram aproximadamente 10 segundos para serem escritas em disco.

Atualmente o processo de gravação das páginas sujas é realizada pelo Kernel através das “worker” threads (“kworker”), no entanto em versões mais antigas existiam threads dedicadas a realizar a escrita para cada disco do sistema, denominadas “flush threads” e em versões anteriores ao kernel 2.6.32 a thread responsável pela gravação era a “pdflush”.

Apesar das mudanças de implementação ao longo do tempo, o mecanismo de limpeza se manteve similar, essas threads trabalham em turnos cujo o intervalo é definido em centésimos de segundos através do “/proc/sys/vm/dirty_writeback_centisecs”. As páginas elegíveis para limpeza em cada turno são definidas a partir do “/proc/sys/vm/dirty_expire_centisecs”, onde é definido a partir de quanto tempo de vida uma página esta elegível a ser limpa.

Outro ponto importante, é que mesmo fora do seu “turno”, as threads de limpeza podem ser iniciadas, caso a quantidade de páginas a sujas atinja os valores dos parâmetros “/proc/vm/sys/dirty_background_ratio” ou “/proc/vm/sys/dirty_background_bytes”, onde podemos definir uma porcentagem máxima de páginas sujas em relação a memória disponível ou uma quantidade (absoluta) máxima de páginas sujas em bytes respectivamente.

Para ilustrar o funcionamento do processo de limpeza vamos manter um looping monitorando o estado das páginas sujas, conforme o comando abaixo:

# cat /proc/sys/vm/dirty_writeback_centisecs
500
# cat /proc/sys/vm/dirty_expire_centisecs 
300
# cat /proc/sys/vm/dirty_background_ratio 
10
# while [ 1=1 ] ; do  grep 'Dirty' /proc/meminfo; sleep 2 ; done
Dirty:              1820 kB
Dirty:              2380 kB
Dirty:               136 kB
Dirty:               236 kB
Dirty:               480 kB
Dirty:              1824 kB
Dirty:              2096 kB
Dirty:               352 kB
Dirty:               860 kB
Dirty:              1028 kB
Dirty:               880 kB
Dirty:              2252 kB
Dirty:               180 kB
Dirty:               364 kB
Dirty:               700 kB
Dirty:               384 kB
Dirty:               520 kB
Dirty:               720 kB
Dirty:              1368 kB
Dirty:              2388 kB
Dirty:               144 kB

Conforme vimos acima, com a configuração atual, a quantidade de páginas sujas é constantemente alterada, mantendo-se sempre abaixo de 3MB.

Agora se alterarmos o “dirty_writeback_centisecs” para zero, desabilitando o mecanismo de writeback, veja o que ocorre:

Dirty:              1880 kB
Dirty:              2872 kB
Dirty:              4344 kB
Dirty:              4620 kB
Dirty:              4812 kB
Dirty:              5720 kB
Dirty:              5772 kB
Dirty:              5984 kB
Dirty:              6136 kB
Dirty:              6176 kB
Dirty:              6400 kB
Dirty:              6756 kB
Dirty:              6820 kB
Dirty:              7324 kB
Dirty:              8560 kB
Dirty:              9528 kB
Dirty:             10628 kB
Dirty:             11328 kB
Dirty:             13320 kB
Dirty:             13540 kB
Dirty:             14480 kB
Dirty:             14648 kB
Dirty:             14920 kB
Dirty:             15744 kB
Dirty:             15784 kB
Dirty:             16292 kB
Dirty:             16532 kB
Dirty:             16584 kB
Dirty:             17000 kB
Dirty:             17132 kB
Dirty:             17900 kB
Dirty:             18696 kB
Dirty:             18824 kB
Dirty:             19728 kB
Dirty:             19768 kB
Dirty:             20016 kB
Dirty:             20848 kB
Dirty:             21100 kB
Dirty:             21600 kB
Dirty:             35400 kB
Dirty:             35492 kB
Dirty:             36292 kB
Dirty:             36612 kB
Dirty:             37160 kB
Dirty:             37940 kB
Dirty:             38092 kB
Dirty:             38628 kB
Dirty:             39556 kB
Dirty:             39804 kB
Dirty:             40028 kB
...

Neste cenário temos a quantidade de páginas sujas aumentando constantemente, porém caso executarmos o comando sync em um terminal, vejamos o que ocorre:

Dirty:             42452 kB
Dirty:             42480 kB
Dirty:             42600 kB
Dirty:                60 kB // Momento onde foi executado o sync
Dirty:               304 kB
Dirty:                 8 kB
Dirty:               112 kB
Dirty:               668 kB
Dirty:                88 kB
Dirty:               472 kB
Dirty:               532 kB
Dirty:               748 kB
Dirty:              2272 kB
Dirty:              2388 kB
Dirty:              2508 kB
Dirty:              2536 kB
Dirty:              2604 kB
Dirty:              4044 kB

Na saída acima, fica evidente que mesmo com o processo de writeback desativado, ainda é possível realizar a limpeza das páginas sujas através de chamadas de sync no sistema.

Outro ponto importante, é que mesmo com o writeback desabilitado (definido para zero), caso o número de páginas sujas atinja o percentual do “dirty_background_ratio” ou o valor absoluto em “dirty_background_bytes”, o kernel irá iniciar o processo de limpeza, conforme podemos ver na demonstração abaixo:

# cat /proc/sys/vm/dirty_writeback_centisecs
0
# echo 10362880 > /proc/sys/vm/dirty_background_bytes 
# while [ 1=1 ] ; do  grep 'Dirty' /proc/meminfo; sleep 2 ; done
Dirty:             20336 kB
Dirty:             21368 kB
Dirty:             22088 kB
Dirty:              6916 kB
Dirty:              7980 kB
Dirty:              8228 kB
Dirty:              8396 kB
Dirty:              8452 kB
Dirty:              8568 kB
Dirty:              9012 kB
Dirty:             10044 kB
Dirty:              5232 kB
Dirty:              5488 kB
Dirty:              6008 kB
Dirty:              6676 kB
Dirty:              7532 kB
Dirty:              8348 kB
Dirty:              9140 kB
Dirty:              9892 kB
Dirty:             10704 kB
Dirty:             10412 kB
Dirty:             11240 kB
Dirty:             11976 kB
Dirty:              1976 kB
Dirty:              4200 kB
Dirty:              4408 kB
Dirty:              4480 kB
Dirty:              4624 kB
Dirty:              5568 kB
Dirty:              6580 kB
Dirty:              7124 kB
Dirty:              7968 kB
Dirty:              9592 kB
Dirty:              8568 kB
Dirty:             11016 kB
Dirty:             11224 kB
Dirty:              3196 kB
Dirty:              3460 kB

A execução acima, mostra que, ao definir o “dirty_background_bytes” para aproximandamente 10MB, toda vez que o número de paginas sujas ultrapassar esse limite, o processo de limpeza será ativado e essa quantidade de páginas será reduzida imediatamente.

Quando a quantidade de páginas sujas for muito grande, e as threads de sincronia não conseguirem dar conta da gravação, as páginas sujas poderão se acumular até um teto definido através dos parâmetros “/proc/sys/vm/dirty_ratio” ou “/proc/sys/vm/dirty_bytes”, onde definimos uma porcentagem máxima de páginas sujas em relação a memória disponível ou uma quantidade absoluta máxima de páginas sujas em bytes respectivamente e ao atingir este teto, todas as novas operações de IO serão bloqueadas até que as páginas sejam sejam escritas em disco causando uma percepção de “congelamento” momentâneo da máquina.

Devido a isso, principalmente em máquinas com grande quantidade de memória RAM, é recomendável que se mantenha o “dirty_background_ratio” com valores baixos, para evitar acúmulo de páginas sujas, e que o “diry_ratio” também seja baixo, pois caso o valor seja muito alto e aconteça de se alcançar esse limite, a máquina pode passar algum tempo congelada efetuando as operações dedicadas a escrita de páginas sujas. Imagine uma máquina de 2TB de RAM com 1TB de RAM disponível, caso o dirty_ratio seja 20 e esse limite seja atingido, teremos por volta de 200GB de dados a serem escritos em disco.

Uma boa prática em máquinas com muita memória RAM, é definir estes parâmetros através de tamanhos absolutos (“dirty_background_bytes” e “dirty_bytes”), já que em alguns casos 1% já pode ser considerado um valor alto.

NUMA

A arquitura NUMA (Non-Uniform Memory Access) consiste de um hardware onde temos diversos agrupamentos de CPUs e memórias, denominadas células, interconectados por barramentos. A principal questão nesta arquitetura é que o tempo de acesso a memória varia de acordo com a “distância” entre a o processador e a memória.

O Linux utiliza a nomenclatura “node” para se referir a uma célula de processador e memória, e trata cada “node” de forma independente quando está realizando a alocação física de memória, ou seja, cada node terá seu endereçamento, controle de páginas livres, páginas em uso e tudo que é necessário para a alocação e liberação de memória.

Para otimizar o desempenho, o Kernel sempre dá preferência pela alocação de memória física no mesmo “node” do processador que se encontra executando o programa e durante as trocas de contexto o escalonador de tarefas tende a manter o processo no mesmo processador, sempre evitando o acesso a memória de outros nodes.

Graças ao uso do conceito de memória virtual o Kernel consegue abstrair todo esse mecanismo, de forma que, para a aplicação, isso se torna completamente transparente.

Para checar se sua máquina utiliza arquitetura NUMA basta consultar a quantidade nodes no sistema, o que pode ser feito de diversas formas:

# lscpu | grep -i numa
NUMA node(s):        1
NUMA node0 CPU(s):   0-3
# cat /sys/devices/system/node/online
0
# cat /proc/zoneinfo  | grep Node
Node 0, zone      DMA
Node 0, zone    DMA32
Node 0, zone   Normal
Node 0, zone  Movable
Node 0, zone   Device

Na saída acima fica claro que a máquina em questão não utiliza NUMA, pois temos apenas um “node” disponível.

Ainda assim é possível visualizar as estatísticas referente a NUMA desse “node” através do “/proc/zoneinfo” conforme o comando abaixo:

# cat /proc/zoneinfo  | grep -A 30 Normal | grep numa 
      numa_hit     319270577
      numa_miss    0
      numa_foreign 0
      numa_interleave 45129
      numa_local   319270577
      numa_other   0

No comando acima estamos exibindo a estatística de NUMA da zona “normal” (veremos mais sobre as zonas no próximo post), e conforme esperado, temos 100% (numa_local=numa_hit e numa_foreign=0 ) das alocações acontecendo no próprio node e nenhuma alocação vinda de outro “node” (numa_miss=0).

Próximos passos

No próximo post iremos encerrar o tema de memória explicando como o Kernel realiza o gerenciamento da memória física e o que podemos observar através do “/proc”.

 

Líder em Treinamento e serviços de Consultoria, Suporte e Implantação para o mundo open source. Conheça nossas soluções:

CURSOSCONSULTORIA

Anterior 4Linux: Empresa Líder em Treinamentos de Software Open Source
Próxima A evolução das plataformas de computação para Big Data

About author

william.welter
william.welter 5 posts

Formado em ciência da computação, com as certificações LPIC-3, LPI DevOps Tools Engineer, LFCS, LFCE, ZCE-PHP5.3, ZFCA, PP9A, desenvolvedor PHP e C, com foco em Linux e software livre. Atualmente é gerente e líder técnico do time de consultoria e suporte na 4Linux, a qual atua principalmente com ferramentas DevOps, containers, cloud, monitoramento e sistemas de missão critica.

View all posts by this author →

Você pode gostar também

Infraestrutura TI

Integrando seu chat com o Rocket Omnichannel

Já falamos anteriormente sobre o Rocket Chat e sua funcionalidade do Omnichannel, onde poderíamos centralizar contatos vindos de diferentes plataformas de comunicação em um único meio de atendimento. Existem funcionalidades

Infraestrutura TI

Gerenciamento de filas assíncronas com Celery e Redis

O Celery é uma fila de tarefas assíncrona de trabalho, implementada em python, com base na passagem de mensagens distribuídas. Está focado na operação em tempo real, mas também oferece

Cloud

Jogando no Linux

Jogar é um excelente passatempo. Pessoas de todos os cantos do mundo se reúnem em grupos, seja para atirar, pilotar, construir, ou simplesmente socializar enquanto salvamos alguns reféns em perigo