Eu tenho um servidor legado antigo com um problema estranho com swap.
Eu sei que a partição swap é pequena, vai adicionar um arquivo de troca, mas, depois de algumas horas após a reinicialização, a situação é esta:
free -m
total used free shared buffers cached
Mem: 15922 15806 116 0 313 13345
-/+ buffers/cache: 2147 13775
Swap: 2047 2042 4
O banco de dados Oracle está instalado, mas quase sem uso. Eu gostaria de entender porque a distribuição de memória é assim. Quero dizer 13345 em cache, significa livre. Por que preencher a troca?
Um sysadmin anterior configurou o swappiness para: 3 .
Páginas enormes não são configuradas .
Eu vi alguns posts semelhantes, mas sem solução para entender. Uma resposta aqui: linux redhat 5.4 - trocar enquanto a memória é ainda disponível fala sobre numa, então eu cavei um pouco (eu sou um dba, não um administrador de sistema, então desculpe se eu sinto falta de algo).
grep NUMA=y /boot/config-'uname -r'
CONFIG_NUMA=y
CONFIG_K8_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_ACPI_NUMA=y
dmesg | grep -i numa
NUMA: Using 63 for the hash shift.
Então, a pergunta é: como eu posso entender por que esta troca de máquina?
Atualizar Com um: vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
4 0 2090852 122224 324056 13679328 320 0 498 1898 1088 3555 32 10 56 2 0
1 0 2090724 139740 324068 13680984 64 0 76 932 1028 3534 7 2 90 2 0
0 0 2090724 132416 324068 13681436 0 0 16 240 1016 3401 3 1 96 1 0
4 0 2090660 116916 324084 13683404 0 0 72 1396 1070 3617 11 9 80 1 0
0 0 2090420 126544 324084 13687008 128 0 188 1872 1068 3436 35 8 56 2 0
Atualização 3
ipcs -ma
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x61a4d538 5210113 oracle 660 4096 0
0xba8cafdc 5242883 oracle 660 4096 0
0x16621634 5308420 oracle 660 4096 0
0xc15f3dac 5373957 oracle 660 4096 0
------ Semaphore Arrays --------
key semid owner perms nsems
0x24690d60 98304 oracle 660 125
0x24690d61 131073 oracle 660 125
0x24690d62 163842 oracle 660 125
0x24690d63 196611 oracle 660 125
0x24690d64 229380 oracle 660 125
0x24690d65 262149 oracle 660 125
0x24690d66 294918 oracle 660 125
0x24690d67 327687 oracle 660 125
0x24690d68 360456 oracle 660 125
0x6285541c 491529 oracle 660 125
0x6285541d 524298 oracle 660 125
0x6285541e 557067 oracle 660 125
0x6285541f 589836 oracle 660 125
0x62855420 622605 oracle 660 125
0x62855421 655374 oracle 660 125
0x62855422 688143 oracle 660 125
0x62855423 720912 oracle 660 125
0x62855424 753681 oracle 660 125
0xaee7ccbc 884754 oracle 660 125
0xaee7ccbd 917523 oracle 660 125
0xaee7ccbe 950292 oracle 660 125
0xaee7ccbf 983061 oracle 660 125
0xaee7ccc0 1015830 oracle 660 125
0xaee7ccc1 1048599 oracle 660 125
0xaee7ccc2 1081368 oracle 660 125
0xaee7ccc3 1114137 oracle 660 125
0xaee7ccc4 1146906 oracle 660 125
0xfb4a455c 1277979 oracle 660 125
0xfb4a455d 1310748 oracle 660 125
0xfb4a455e 1343517 oracle 660 125
0xfb4a455f 1376286 oracle 660 125
0xfb4a4560 1409055 oracle 660 125
0xfb4a4561 1441824 oracle 660 125
0xfb4a4562 1474593 oracle 660 125
0xfb4a4563 1507362 oracle 660 125
0xfb4a4564 1540131 oracle 660 125
------ Message Queues --------
key msqid owner perms used-bytes messages
Se você não está experimentando muita paginação ativa (si / so in vmstat), então não é nada para se preocupar. O kernel está optando por colocar pedaços de código de programa que não estão sendo ativamente usados para trocar, de modo que ele possa manter mais arquivos do banco de dados na RAM (armazenados em cache gratuitamente).
Este é um artigo excelente que descobri sobre swap e como usá-lo nem sempre é ruim. link
Não é bom. Se você tiver alguma coisa, exceto um muito acidental si , você está basicamente fora do reino de "good swap" . E o seu sistema está fazendo isso o tempo todo. SwapIn significa que algum programa está aguardando e potencialmente significa que o usuário experimenta uma lentidão (usuário local ou remoto).
Eu sou todo sobre essa boa troca. O que significa principalmente so para extrair o material inchado da sua preciosa RAM; já que é inchado, ele fica no disco não usado por qualquer pessoa com uma atividade swap muito muito incidental.
Você acertou uma coisa engraçada com a Oracle que eu vi antes: de alguma forma, a Oracle relata sua SGA como um "cache" (se bem me lembro, porque é um anônimo mmap ). Mas sendo anônimo, não é uma memória que um sistema pode simplesmente largar a qualquer momento, portanto, não é free ! Muito pelo contrário - é muito usado. A Oracle geralmente usa também o cache real do sistema restante ao ler arquivos de dados que podem colocar muita pressão de memória no cache (comportamento padrão estúpido).
Portanto, é um dos muitos casos em que o free engana você ao pensar que todo o "cache" deve ser tratado como "livre". Essa regra geral é apenas para um servidor de arquivos apenas para leitura. (Eu acho que é por isso que os autores de free colocaram a linha que diz "cache" é "usada" acima da linha onde implica "cache" é "free".)
E não ajuste swappiness enquanto o sistema tiver 100% de troca ocupada. Isso não é sábio.
Aposto que o seu SGA não é de 2 GB, mas talvez seja mais de 10 GB ou mais. Eu acho que se você configurar o SGA para 6 GB, você verá que os swapins irão diminuir e muito menos material será empurrado para swap. Ao aumentá-lo passo a passo, você verá como a pressão aumenta.
Tags swap memory-usage linux redhat