O servidor Linux está usando apenas 60% da memória, em seguida, trocando

Question

Eu tenho um servidor Linux que está executando o nosso sistema de backup bacula. A máquina está triturando como louca porque está ficando pesada para trocar. O problema é que ele usa apenas 60% de sua memória física!

Aqui está a saída de free -m :

free -m
             total       used       free     shared    buffers     cached
Mem:          3949       2356       1593          0          0          1
-/+ buffers/cache:       2354       1595
Swap:         7629       1804       5824

e alguns exemplos de saída de vmstat 1 :

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  2 1843536 1634512      0   4188   54   13  2524   666    2    1  1  1 89  9  0
 1 11 1845916 1640724      0    388 2700 4816 221880  4879 14409 170721  4  3 63 30  0
 0  9 1846096 1643952      0      0 4956  756 174832   804 12357 159306  3  4 63 30  0
 0 11 1846104 1643532      0      0 4916  540 174320   580 10609 139960  3  4 64 29  0
 0  4 1846084 1640272      0   2336 4080  524 140408   548 9331 118287  3  4 63 30  0
 0  8 1846104 1642096      0   1488 2940  432 102516   457 7023 82230  2  4 65 29  0
 0  5 1846104 1642268      0   1276 3704  452 126520   452 9494 119612  3  5 65 27  0
 3 12 1846104 1641528      0    328 6092  608 187776   636 8269 113059  4  3 64 29  0
 2  2 1846084 1640960      0    724 5948    0 111480     0 7751 116370  4  4 63 29  0
 0  4 1846100 1641484      0    404 4144 1476 125760  1500 10668 105358  2  3 71 25  0
 0 13 1846104 1641932      0      0 5872  828 153808   840 10518 128447  3  4 70 22  0
 0  8 1846096 1639172      0   3164 3556  556 74884   580 5082 65362  2  2 73 23  0
 1  4 1846080 1638676      0    396 4512   28 50928    44 2672 38277  2  2 80 16  0
 0  3 1846080 1628808      0   7132 2636    0 28004     8 1358 14090  0  1 78 20  0
 0  2 1844728 1618552      0  11140 7680    0 12740     8  763 2245  0  0 82 18  0
 0  2 1837764 1532056      0 101504 2952    0 95644    24  802 3817  0  1 87 12  0
 0 11 1842092 1633324      0   4416 1748 10900 143144 11024 6279 134442  3  3 70 24  0
 2  6 1846104 1642756      0      0 4768  468 78752   468 4672 60141  2  2 76 20  0
 1 12 1846104 1640792      0    236 4752  440 140712   464 7614 99593  3  5 58 34  0
 0  3 1846084 1630368      0   6316 5104    0 20336     0 1703 22424  1  1 72 26  0
 2 17 1846104 1638332      0   3168 4080 1720 211960  1744 11977 155886  3  4 65 28  0
 1 10 1846104 1640800      0    132 4488  556 126016   584 8016 106368  3  4 63 29  0
 0 14 1846104 1639740      0   2248 3436  428 114188   452 7030 92418  3  3 59 35  0
 1  6 1846096 1639504      0   1932 5500  436 141412   460 8261 112210  4  4 63 29  0
 0 10 1846104 1640164      0   3052 4028  448 147684   472 7366 109554  4  4 61 30  0
 0 10 1846100 1641040      0   2332 4952  632 147452   664 8767 118384  3  4 63 30  0
 4  8 1846084 1641092      0    664 4948  276 152264   292 6448 98813  5  5 62 28  0

Além disso, a saída do topo ordenada pelo tempo da CPU parece apoiar a teoria de que swap é o que está atrapalhando o sistema:

top - 09:05:32 up 37 days, 23:24,  1 user,  load average: 9.75, 8.24, 7.12
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.6%us,  1.4%sy,  0.0%ni, 76.1%id, 20.6%wa,  0.1%hi,  0.2%si,  0.0%st
Mem:   4044632k total,  2405628k used,  1639004k free,        0k buffers
Swap:  7812492k total,  1851852k used,  5960640k free,      436k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 4174 root      17   0 63156  176   56 S    8  0.0   2138:52  35,38 bacula-fd                                                                                                                            
 4185 root      17   0 63352  284  104 S    6  0.0   1709:25  28,29 bacula-sd                                                                                                                            
  240 root      15   0     0    0    0 D    3  0.0 831:55.19 831:55 kswapd0                                                                                                                              
 2852 root      10  -5     0    0    0 S    1  0.0 126:35.59 126:35 xfsbufd                                                                                                                              
 2849 root      10  -5     0    0    0 S    0  0.0 119:50.94 119:50 xfsbufd                                                                                                                              
 1364 root      10  -5     0    0    0 S    0  0.0 117:05.39 117:05 xfsbufd                                                                                                                              
   21 root      10  -5     0    0    0 S    1  0.0  48:03.44  48:03 events/3                                                                                                                             
 6940 postgres  16   0 43596    8    8 S    0  0.0  46:50.35  46:50 postmaster                                                                                                                           
 1342 root      10  -5     0    0    0 S    0  0.0  23:14.34  23:14 xfsdatad/4                                                                                                                           
 5415 root      17   0 1770m  108   48 S    0  0.0  15:03.74  15:03 bacula-dir                                                                                                                           
   23 root      10  -5     0    0    0 S    0  0.0  13:09.71  13:09 events/5                                                                                                                             
 5604 root      17   0 1216m  500  200 S    0  0.0  12:38.20  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  580  248 S    0  0.0  11:58.00  11:58 java

Aqui está o mesmo classificado por tamanho de imagem de memória virtual:

top - 09:08:32 up 37 days, 23:27,  1 user,  load average: 8.43, 8.26, 7.32
Tasks: 173 total,   1 running, 172 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.6%us,  3.4%sy,  0.0%ni, 62.2%id, 30.2%wa,  0.2%hi,  0.3%si,  0.0%st
Mem:   4044632k total,  2404212k used,  1640420k free,        0k buffers
Swap:  7812492k total,  1852548k used,  5959944k free,      100k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND                                                                                                                             
 5415 root      17   0 1770m   56   44 S    0  0.0  15:03.78  15:03 bacula-dir                                                                                                                           
 5604 root      17   0 1216m  492  200 S    0  0.0  12:38.30  12:38 java                                                                                                                                 
 5552 root      16   0 1194m  476  200 S    0  0.0  11:58.20  11:58 java                                                                                                                                 
 4598 root      16   0  117m   44   44 S    0  0.0   0:13.37   0:13 eventmond                                                                                                                            
 9614 gdm       16   0 93188    0    0 S    0  0.0   0:00.30   0:00 gdmgreeter                                                                                                                           
 5527 root      17   0 78716    0    0 S    0  0.0   0:00.30   0:00 gdm                                                                                                                                  
 4185 root      17   0 63352  284  104 S   20  0.0   1709:52  28,29 bacula-sd                                                                                                                            
 4174 root      17   0 63156  208   88 S   24  0.0   2139:25  35,39 bacula-fd                                                                                                                            
10849 postgres  18   0 54740  216  108 D    0  0.0   0:31.40   0:31 postmaster                                                                                                                           
 6661 postgres  17   0 49432    0    0 S    0  0.0   0:03.50   0:03 postmaster                                                                                                                           
 5507 root      15   0 47980    0    0 S    0  0.0   0:00.00   0:00 gdm                                                                                                                                  
 6940 postgres  16   0 43596   16   16 S    0  0.0  46:51.39  46:51 postmaster                                                                                                                           
 5304 postgres  16   0 40580  132   88 S    0  0.0   6:21.79   6:21 postmaster                                                                                                                           
 5301 postgres  17   0 40448   24   24 S    0  0.0   0:32.17   0:32 postmaster                                                                                                                           
11280 root      16   0 40288   28   28 S    0  0.0   0:00.11   0:00 sshd                                                                                                                                 
 5534 root      17   0 37580    0    0 S    0  0.0   0:56.18   0:56 X                                                                                                                                    
30870 root      30  15 31668   28   28 S    0  0.0   1:13.38   1:13 snmpd                                                                                                                                
 5305 postgres  17   0 30628   16   16 S    0  0.0   0:11.60   0:11 postmaster                                                                                                                           
27403 postfix   17   0 30248    0    0 S    0  0.0   0:02.76   0:02 qmgr                                                                                                                                 
10815 postfix   15   0 30208   16   16 S    0  0.0   0:00.02   0:00 pickup                                                                                                                               
 5306 postgres  16   0 29760   20   20 S    0  0.0   0:52.89   0:52 postmaster                                                                                                                           
 5302 postgres  17   0 29628   64   32 S    0  0.0   1:00.64   1:00 postmaster

Eu tentei ajustar o parâmetro swappiness kernel para valores altos e baixos, mas nada parece alterar o comportamento aqui. Eu estou em uma perda para descobrir o que está acontecendo. Como posso descobrir o que está causando isso?

Atualização: O sistema é totalmente de 64 bits, portanto não deve haver limitações de memória devido a problemas de 32 bits.

Update2: Como mencionei na pergunta original, eu já tentei ajustar o swappiness para todos os tipos de valores, incluindo 0. O resultado é sempre o mesmo, com aproximadamente 1,6 GB de memória restante não utilizado.

Update3: Adicionada a melhor saída às informações acima.

    

Answer 1

O desempenho do Bacula é altamente dependente do banco de dados. Provavelmente, é o postgresql que está matando seu servidor. A alta carga média e o grande percentual de tempo de CPU gasto no estado de espera mostram claramente que ele está aguardando a E / S de Disco ... E isso é o que o PostgreSQL está fazendo. Para cada arquivo em seu conjunto de backup, ele faz pelo menos uma instrução UPDATE. Não se preocupe com a troca.

Faça o ajuste da instalação do PostgreSQL. Possivelmente, dê banco de dados individual (ou mesmo tabelas) seus próprios conjuntos de discos / raid para espalhar o I / O ao redor. Você pode forçar o PostgreSQL a usar gravações assíncronas, se ainda não estiver ... Embora isso seja a integridade do banco de dados para desempenho de gravação. Aumente o máximo da memória compartilhada disponível para o PostgreSQL. Isso aliviará pelo menos um monte de leitura no banco de dados. Se você nunca fez isso, execute o comando VACCUM ANALYZE no banco de dados Bacula para dar ao otimizador de consulta algo para trabalhar.

De longe, o ponto mais fraco de Bacula são as dependências do banco de dados (e a morte cerebral de algumas delas ...) Execute um expurgo de um grande backup recente e observe quanto tempo (horas frequentemente) leva para executar algumas dúzias milhões de consultas ... Bacula gosta de poucos arquivos grandes, senão é um cachorro.

    

Answer 2

Você está ligado a E / S. Seu sistema é um pequeno bote salva-vidas, danificado em um mar tempestuoso de swells de paginação de buffer / cache / VM com até 30 metros de altura.

Uau. Apenas Uau. Você está se movendo cerca de 100Mbyte / sec para fora do seu I / O, você está com mais de 50% de tempo de CPU em espera de E / S e tem 4Gb de RAM. A contrapressão na VM deste servidor deve ser enorme. Em circunstâncias "normais", quando o sistema começa a armazenar em buffer / cache, qualquer RAM livre que você tenha será ingerida viva em menos de 40 segundos.

Seria possível publicar as configurações de /proc/sys/vm ? Isso forneceria algumas dicas sobre o que seu kernel acha que é "normal".

Esses processos postmaster também indicam que você está executando o PostgreSQL em segundo plano. Isso é normal para a sua configuração? O PostgreSQL em uma configuração padrão usará muito pouca memória RAM, mas uma vez ajustado para velocidade, ele pode consumir rapidamente de 25% a 40% da sua RAM disponível. Então eu só posso imaginar, dado o número deles na saída, você está executando algum tipo de banco de dados de produção enquanto está executando backups. Isso não é um bom presságio. Você pode dar mais algumas informações sobre o motivo de sua execução? Qual é o tamanho do parâmetro de memória compartilhada para todos os processos postmaster ? Seria possível desligar o serviço ou reconfigurar temporariamente o banco de dados para usar menos conectores / buffers enquanto os backups estão em execução? Isso ajudará a tirar um pouco da pressão da E / S já sobrecarregada e da RAM livre. Lembre-se de que cada processo postmaster consome RAM acima e além do que o banco de dados usa para o armazenamento em cache interno. Portanto, ao fazer ajustes nas configurações de memória, tenha cuidado que são "compartilhados" e quais são "por processo" .

Se você estiver usando o PostgreSQL como parte do processo de backup, tente reajustá-lo para aceitar apenas o número mínimo de conexões , e certifique-se de reduzir seus parâmetros por processo para algo razoável (apenas alguns megas cada). A desvantagem disso é que o PostgreSQL vai derramar em disco se não puder trabalhar com o conjunto de dados na RAM como quer, de modo que aumente seu disco I / O , então sintonize com cuidado.

O X11 por si só não ocupa muita memória, mas uma sessão completa de área de trabalho pode consumir vários megas. Faça o logout de todas as sessões ativas que você tiver e execute sua conexão a partir do console ou por meio do SSH.

Ainda assim, não acho que seja um problema de memória. Se você é melhor que 50% de E / S, aguarde por longos períodos de tempo (e você) re postar números que tocam os anos 70), o gargalo resultante acabará por esmagar o resto do sistema. Muito parecido com Darth Vader esmaga o pescoço.

Quantos tópicos de limpeza estão configurados para? Use

cat /proc/sys/vm/nr_pdflush_threads

para descobrir e

echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf

para configurá-lo para um único segmento. Observe que o último comando faz com que seja carregado permanentemente na reinicialização. Vendo 1 ou 2, não é incomum. Se você tiver vários núcleos ou muita capacidade de fuso / barramento para E / S, você precisará fazer um bump (ligeiramente). Mais flush threads = mais atividade de E / S, mas também mais tempo de CPU gasto em espera de E / S.

É o valor padrão ou você colidiu? Se você deu um salto, você considerou diminuir o número para reduzir a quantidade de pressão nas operações de E / S? Ou você tem um grande número de fusos e canais para trabalhar, neste caso, você considerou aumentar o número de threads flush?

P.S. você deseja definir o swap para os valores mais baixos, e não os valores mais altos, para evitar a exclusão. Maior valor = 100 = troque como um louco quando se sentir bem, menor valor = 0 = tente não trocar nada.

    

Answer 3

Se você observar os blocos lidos por segundo (bi) em IO, isso diminuirá a atividade de troca em várias ordens de magnitude. Eu não acho que o uso de swap é o que está causando a sua surra de disco, eu acho que você tem algo em execução na caixa que está simplesmente causando muita atividade de disco (leituras).

Eu investigaria os aplicativos em execução e verificaria se você pode encontrar o culpado.

    

Answer 4

Veja se este link responde algumas de suas perguntas. Eu regularmente vejo a paginação do Linux (não trocando) a memória muito antes da utilização de 60%. Esta é uma parte esperada do seu ajuste de memória:

link

Mas sua falta de buffers / cache me preocupa. Isso parece muito incomum. Então estou pensando que algo mais está errado.

    

Answer 5

Você pode tentar desabilitar o swap totalmente?

swapoff /dev/hdb2

ou algo assim - pelo menos, isso irá validar que está trocando esse problema, e não outra coisa.

    

Answer 6

Por padrão, o swappiness é definido como 60.

cat / proc / sys / vm / swappiness 60

O Swappiness é um kernel usado para ajustar o quanto o kernel favorece a troca pela RAM; alta swappiness significa que o kernel irá trocar muito, e o baixo swappiness significa que o kernel tentará não usar o espaço de troca.

Podemos alterar esta edição do valor de vm.swappiness em /etc/sysctl.conf .

    

Answer 7

Você pode definir manualmente o swappinness do kernel, que você pode ver em /proc/sys/vm/swappiness ou emitir o comando sysctl vm.swappiness . O swappiness é uma configuração do kernel que determina o quanto a troca é usada.

Ao definir sudo sysctl vm.swappiness=0 , você está efetivamente desativando a partição swap. Para tornar essa alteração permanente, você pode adicionar / modificar vm.swappiness=0 in /etc/sysctl.conf . Você deve ver o que é um bom valor para você. Eu pessoalmente tenho configurado para vm.swappiness=10 , sendo 60 o valor padrão.

    

Answer 8

Outra coisa que você pode querer olhar é sua fila de execução do kernel e processos não-interrompidos (as colunas 'r' e 'b' no vmstat) são um indicador de que o sistema está saturado às vezes. Em uma nota lateral, não confunda a saturação com a utilização ... o problema real pode ser uma pilha de processo com fome contra o kernel saturado: - (

Você também pode executar 'pmap -x [PID]' para obter detalhes adicionais da memória de alguns dos processos mais consumidores. Eu te desejo sorte!

Matt

    

Answer 9

Talvez você tenha processos de curta duração que usam muita memória, depois saia antes de ter a chance de notá-los.

Isso seria consistente com o que você está vendo de qualquer maneira.

    

Answer 10

Você investigou problemas com o cache de inode? slabtop deve, pelo menos, dar-lhe um ponto de partida se você estiver correndo para algo assim.

    

Answer 11

Enquanto seu sistema é de 64 bits, o sistema pode não conseguir realmente endereçar toda a memória disponível. Esta é uma limitação do chipset. Por exemplo, a geração anterior Mac mini "suporta" 4 GB de memória RAM, mas apenas 3.3 GB é realmente endereçável.