Aumentando o cache do SO na RAM, causando alto uso da CPU do sistema

4

Longa pergunta, então, por favor, descubra comigo: Estou tendo um problema estranho com um servidor que nunca vi antes. Em uma máquina com ~ 30G de RAM com um aplicativo que leva ~ 10G (espalhado por centenas de processos). Com o passar do tempo, o sistema operacional começa a preencher a memória RAM extra com cache e buffers (totalmente normais para o Linux). Eu já vi isso acontecer antes, sem problemas, mas nesta máquina, à medida que a quantidade de RAM vazia diminui, a CPU fica louca (100% em 8 CPUs por ~ 3 minutos) na marca de 256M. Eu estou supondo que o sistema operacional está usando toda essa CPU para embaralhar a memória para obter algum espaço livre de volta.

Pelo que eu entendo sobre gerenciamento de memória Linux, é suposto usar o máximo de espaço livre na RAM possível para cache no nível do sistema operacional, mas então passá-lo para qualquer aplicativo que precise dele quando solicitado e por experiências passadas. uma experiência traumática para a CPU. Isso acontece o tempo todo. Então, por que poderia ser diferente aqui?

Estou anexando uma pequena parte da saída do vmstat às métricas relacionadas (capturadas a cada 2 segundos). Você pode ver onde a CPU do sistema (14ª coluna, 3ª da direita) começa a ficar ocupada quando a memória livre atinge ~ 256M e fica realmente louco cerca de 30 segundos depois.

r    b   swpd  free     buff     cache     si  so  bi   bo    in     cs     us  sy   id  wa
1    0   0     293876   5022848  18797528  0   0   206  1712  20924  12845  29  9    61  1
6    0   0     285324   5022848  18797656  0   0   0    0     18795  11382  23  9    68  0
2    0   0     292320   5022848  18797916  0   0   26   2022  19933  12068  27  10   62  1
3    0   0     264492   5022848  18798196  0   0   14   0     20705  15412  30  9    61  0
3    0   0     254880   5022848  18798804  0   0   190  532   16207  9723   31  8    60  0
17   0   0     255588   5021292  18783092  0   0   24   2     13521  7471   27  42   31  0
3    0   0     288396   5020536  18771496  0   0   0    2     14277  8458   24  29   47  0
4    0   0     299560   5020180  18761296  0   0   0    448   8778   5099   21  30   49  0
2    0   0     290908   5019376  18753656  0   0   0    2     9027   5115   27  19   54  0
7    0   0     306060   5018544  18746740  0   0   38   442   8398   5134   20  17   63  0
1    0   0     317140   5018244  18744252  0   0   46   0     9707   5822   22  17   61  0
4    0   0     282268   5017748  18741836  0   0   12   2     10203  6165   26  12   62  0
1    0   0     322548   5017500  18738024  0   0   2    444   10593  6277   23  16   61  0
4    0   0     314936   5017280  18734564  0   0   6    8     9473   5680   25  15   61  0
13   0   0     316976   5017044  18731128  0   0   0    622   12481  7353   33  17   49  0
5    0   0     324952   5016908  18728552  0   0   10   222   11071  6965   22  13   65  0
2    0   0     324692   5016908  18728344  0   0   0    526   10612  6602   24  10   66  0
3    0   0     312312   5017136  18727644  0   0   156  1050  12316  7472   26  10   63  1
2    1   0     323392   5017260  18726848  0   0   66   26    11643  7152   23  13   64  0
8    1   0     318956   5017124  18723772  0   0   20   518   17042  9543   31  22   46  1
1    0   0     317816   5017124  18725428  0   0   0    2854  11704  6951   21  9    67  3
18   0   0     325136   5014492  18707212  0   0   0    32    7619   3845   16  58   27  0
46   0   0     323508   5012980  18692036  0   0   0    562   3939   917    3   92   5   0
71   0   0     299164   5009680  18675476  0   0   0    6     4696   1304   8   90   1   0
75   0   0     205364   5007744  18657228  0   0   36   340   6699   2556   18  82   0   0
75   0   0     221660   5005956  18636480  0   0   68   0     3942   943    4   95   0   0
84   0   0     223788   5004624  18618380  0   0   0    0     2843   335    3   97   1   0
44   0   0     214956   5002464  18599872  0   0   0    0     4696   1301   5   92   3   0
37   0   0     223804   4999964  18577076  0   0   0    0     3281   521    1   98   0   0
82   0   0     266888   4995768  18557264  0   0   0    1760  4595   766    4   96   1   0
91   0   0     260148   4993964  18541192  0   0   0    0     3780   866    6   94   0   0
74   0   0     279796   4990464  18524980  0   0   0    4     4096   926    4   96   0   0
44   0   0     274796   4984268  18503492  0   0   0    0     6316   2142   3   95   3   0
48   0   0     295616   4981824  18482616  0   0   0    0     2561   227    1   99   1   0

Também estou incluindo uma captura de tela da ferramenta de monitoramento para mostrar visualmente o que está acontecendo com a memória. Neste gráfico, a linha inferior (roxa) é o espaço livre real restante na RAM e toda vez que atinge 256M, causa um pico na CPU.

BTW, o swap está desabilitado nesta máquina (se você não pode dizer a partir do vmstats).

ATUALIZAÇÕES Mais informações que foram feitas:

  • Linux é 3.11.0, Ubuntu 13.10
  • Não é uma aplicação Java, é PHP / Apache
por mpeters 07.07.2014 / 23:16

1 resposta

3

Acho que a CPU é usada apenas para varrer as tabelas de páginas para encontrar quais quadros liberar. Parece alto, eu tenho um sistema com pequenas páginas, 400 GB de RAM e não mostra um comportamento tão dramático. Difícil dizer qual é a causa raiz, mas gostaria de propor uma solução alternativa. Ativar uma quantidade substancial de páginas enormes (via vm.nr_hugepages ). Isso diminuiria substancialmente o tamanho das tabelas de páginas, já que a página grande tem 2 MiB, que é 512 vezes maior que uma pequena página. Este artigo descreve uma solução para um problema semelhante .

Uma limitação é que páginas enormes não podem ser trocadas, mas parece irrelevante em sua situação.

    
por 27.07.2014 / 20:20