servidor sem memória

Question

o servidor está ficando sem memória e chega ao ponto em que começa a matar o processo, a memória total do PSS memória utilizada a partir da memória residente) consumida pelo topo usando aplicativos é menor do que a memória total no sistema, eu quero descobrir onde esse uso de memória extra está acontecendo? qualquer idéia, abaixo, é a saída de meminfo, smem, free -m,

alguma sugestão será muito apreciada ???

cat /proc/meminfo

MemTotal:        5976008 kB
MemFree:          138768 kB
Buffers:            2292 kB
Cached:            57444 kB
SwapCached:        85980 kB
Active:           324332 kB
Inactive:         121836 kB
Active(anon):     309264 kB
Inactive(anon):    77992 kB
Active(file):      15068 kB
Inactive(file):    43844 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       8159224 kB
SwapFree:        6836184 kB
Dirty:               572 kB
Writeback:             0 kB
AnonPages:        372160 kB
Mapped:            13976 kB
Shmem:               472 kB
Slab:             328216 kB
SReclaimable:      92544 kB
SUnreclaim:       235672 kB
KernelStack:        4824 kB
PageTables:        14732 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8159224 kB
Committed_AS:    4940480 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      102424 kB
VmallocChunk:   34359584392 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        6384 kB
DirectMap2M:     2080768 kB
DirectMap1G:     4194304 kB

SMEM usage:

30971 root     python /usr/local/scripts/s     2432      660      860     1204
23296 root     /usr/bin/spamd -d -c -m5 -H    58296     1460     1564     1868
 2763 ufc      csrv -c /home/ufc/ufclient/   116000    12768    12792    13084
55819 root     /usr/bin/python /bin/smem          0    22356    22988    24364
 2101 root     clamd                         189228    41224    41280    41700
32914 root     /opt/safesquid/safesquid/sa   831120     5808   138619   271844


[root@server sysadmin]# free -m
             total       used       free     shared    buffers     cached
Mem:          5835       5695        140          0          1         19
-/+ buffers/cache:       5674        161
Swap:         7967       1315       6652

ATUALIZAÇÃO:

O servidor está de volta normal agora, mas o uso de memória é exponencial e continua subindo até depois de 7 horas que o aplicativo é morto

Out of memory: Kill process 14585 (safesquid) score 81 or sacrifice child
Killed process 16141, UID 500, (python) total-vm:79284kB, anon-rss:2656kB, file-rss:680kB



 top - 21:58:16 up 16 days, 11:10,  1 user,  load average: 0.46, 0.74,
    0.78 Tasks: 243 total,   1 running, 242 sleeping,   0 stopped,   0 zombie Cpu(s):  5.7%us,  5.8%sy,  0.0%ni, 88.3%id,  0.1%wa,  0.0%hi, 
    0.1%si,  0.0%st Mem:   5976008k total,  5830648k used,   145360k free,    35724k buffers Swap:  8159224k total,   445384k used,  7713840k free,  3684540k cached


PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND  
4960 ssquid    20   0 1000m 534m 3068 S 20.6  9.2  90:19.40 safesquid  
2101 clamav    20   0 4153m  85m 1672 S  2.0  1.5 536:42.26 clamd 
23333 root      20   0  244m  50m 1940 S  0.0  0.9   2:10.84 spamd  
2763 ufc       20   0 1628m  32m  25m S  1.0  0.5 399:12.74 csrv 
61303 root      20   0 97876 4380 3304 S  0.0  0.1   0:00.28 sshd 
23296 root 20   0  227m 3424  928 S  0.0  0.1   0:07.87 spamd

a caixa está executando o espaço de regras, o proxy clam e o proxy safesquid.

No gráfico de memória, a grande queda é quando o aplicativo foi morto, e eu reiniciei o serviço safesquid ...

    

Answer 1

@David Schwartz: Tenho certeza que o assassino da OOM do kernel mata o processo. E sim, precisamos saber qual processo está sendo morto.

Tenho certeza que o processo que está sendo morto está se comportando de alguma forma (ou travando), como resultado, ele está usando a maior parte da memória disponível, no ponto em que o assassino da OOM do kernel decide finalizá-lo. Por exemplo, esse tipo de comportamento era desenfreado (no meu caso) há uma década atrás, quando o mozilla / firefox era mais propenso a vazar memória do que é agora. Ele usaria mais e mais e de repente desaparecia ... você entendeu.

    

Answer 2

Bem, aqui está o resumo:

Qualquer que seja o processo que está sendo morto, provavelmente tem um vazamento de memória. Seu gráfico certamente faz com que pareça o caso. Você deve se concentrar na linha roxa mais do que o amarelo. O amarelo também é memória livre .

Quanto aos processos que não usam a memória total, não está claro o que você está dizendo, já que você não me contou quanto está na máquina. No entanto, uma certa quantidade de memória é sempre usada pelo kernel e coisas como a tabela de páginas . a memória completa de hardware não está disponível para os aplicativos.

No seu caso, você tem 5.7G de memória total show e isso significa que você provavelmente tem 6G instalado. Uma explicação exaustiva do meminfo pode ajudá-lo, mas o resumo é que a sua grande queda vem de um aplicativo de vazamento de memória que precisa ser corrigido ou, pelo menos, reiniciado regularmente.