Uso elevado de RAM de Linux por razones desconocidas


9

Después de buscar esto y solo encontrar publicaciones de personas que no interpretan la figura "en caché" correctamente, decidí hacer esta pregunta.

Tengo algunos servidores a mano, que actúan de manera extraña. Es decir, su uso de RAM es muy alto, sin razón aparente. Parece que un proceso invisible tiene mucha RAM "usada" (y quiero decir "usada").

Aquí hay alguna información:

  • todos los servidores ejecutan SLES 11
  • kernel es 3.0.76
  • todos los servidores se ejecutan como invitados en una infraestructura VMWare ESX
  • No he configurado los servidores y no tuve voz en la elección del sistema operativo ni tengo acceso a la infraestructura de virtualización
  • todos los servidores están configurados de manera similar y ejecutan el mismo conjunto de software (es un clúster y sí, lo sé, clúster virtualizado, yada yada, como dije: tenía y no tengo voz en eso)

Y algo de salida de shell:

root@good-server:# free -m
             total       used       free     shared    buffers     cached
Mem:         15953      14780       1173          0        737       8982
-/+ buffers/cache:       5059      10894
Swap:        31731          0      31731

root@good-server:# python ps_mem.py
[... all processes neatly listed ...]
---------------------------------
                          4.7 GiB
=================================

root@bad-server:# free -m
             total       used       free     shared    buffers     cached
Mem:         15953      15830        123          0        124       1335
-/+ buffers/cache:      14370       1583
Swap:        31731         15      31716

root@bad-server:# python ps_mem.py
[... all processes neatly listed ...]
---------------------------------
                          4.0 GiB
=================================

Contenido de / proc / meminfo del buen servidor

MemTotal:       16336860 kB
MemFree:          112356 kB
Buffers:          138384 kB
Cached:          1145208 kB
SwapCached:         1244 kB
Active:          4344336 kB
Inactive:        1028744 kB
Active(anon):    3706796 kB
Inactive(anon):   382724 kB
Active(file):     637540 kB
Inactive(file):   646020 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32493560 kB
SwapFree:       32477728 kB
Dirty:              1248 kB
Writeback:             0 kB
AnonPages:       4087776 kB
Mapped:            60132 kB
Shmem:               156 kB
Slab:             274968 kB
SReclaimable:     225864 kB
SUnreclaim:        49104 kB
KernelStack:        4352 kB
PageTables:        16400 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40661988 kB
Committed_AS:    6576912 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      311400 kB
VmallocChunk:   34359418748 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       73728 kB
DirectMap2M:    16703488 kB

Contenido de / proc / meminfo del servidor incorrecto

MemTotal:       16336860 kB
MemFree:         1182320 kB
Buffers:          756244 kB
Cached:          8695688 kB
SwapCached:            0 kB
Active:         13499680 kB
Inactive:         843208 kB
Active(anon):    4853460 kB
Inactive(anon):    37372 kB
Active(file):    8646220 kB
Inactive(file):   805836 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32493560 kB
SwapFree:       32493560 kB
Dirty:              1268 kB
Writeback:             0 kB
AnonPages:       4890180 kB
Mapped:            84672 kB
Shmem:               252 kB
Slab:             586084 kB
SReclaimable:     503716 kB
SUnreclaim:        82368 kB
KernelStack:        5176 kB
PageTables:        19684 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40661988 kB
Committed_AS:    6794180 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      311400 kB
VmallocChunk:   34359419468 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      112640 kB
DirectMap2M:    16664576 kB

TL; DR: si compara estos datos uno al lado del otro, estas son las principales diferencias (BADserver - GOODserver):

MemFree       -1070 MB
Cached        -7550 MB
Active        -9155 MB
Active(anon)  -1147 MB
Active(file)  -8009 MB
AnonPages     - 802 MB

Las otras diferencias son bastante pequeñas y están dentro de los límites que uno podría esperar (pero puede verlo usted mismo)

Como puede ver, en el buen servidor, el total de todas las memorias RES y SHR de todos los procesos está más o menos en línea con free -mla salida del valor "usado - / + buffers / cache", que es lo que esperaría, correcto ?

Ahora mire el servidor incorrecto: free -mel resultado de "used - / + buffers / cache" es aproximadamente 3 veces más alto de lo que podría esperar, resumiendo todo lo que pspuede mostrarle.

Esto también coincide con lo que /proc/meminfome dice.

Hasta ahora no tengo idea de cómo es eso posible. ¿Qué podría estar pasando aquí?


Ambas salidas de /proc/meminfosu reclamo son para el buen servidor? ¿Puede proporcionar una referencia de servidor incorrecta también?
Matthew Ife

¿Tiene acceso a su consola VMware vSphere o al Centro Virtual? ¿O alguna forma de ver un par de cosas relacionadas con la memoria de los invitados?
ewwhite

Publique la salida de / proc / zoneinfo
Matthew Ife

@ewwhite no, desafortunadamente no tengo absolutamente ningún acceso a nada más allá del sistema operativo en sí.
luxifer

@MatthewIfe la etiqueta de meminfo era un error tipográfico - lo corrigió ... ahora sacando contenido de zoneinfo
luxifer

Respuestas:


12

Creo que puede tener un problema de aumento de memoria de VMware . Existe la posibilidad de que el exceso de compromiso de memoria en la infraestructura de vSphere sea demasiado alto. No podrá remediar esto sin tener acceso a vSphere vCenter, pero debería poder detectar esto desde sus máquinas virtuales, suponiendo que vmtools esté instalado:

¿Puedes publicar la salida de vmware-toolbox-cmd stat balloon?

Además, se le han asignado 16 GB de RAM. Pregunte a quien tenga el control de la infraestructura si hay algún límite de RAM manual en las máquinas virtuales en cuestión.


Después de leer cómo funciona el globo en vmware linux vms, creo que esta es la causa. Sin embargo, estoy bastante impresionado de que no ofrezcan una forma desde el lado de la VM para tener en cuenta las páginas 'usadas'.
Matthew Ife

1
De hecho, esto es correcto, creo ... el buen servidor muestra "o MB" ... el mal servidor muestra "10092 MB", ¡lo cual está muy en línea con lo que estamos viendo!
luxifer

@luxifer Entonces ahora ustedes tienen que arreglarlo . Lo que significa eliminar un límite de RAM artificial en la VM o vMotioning a otro host ESXi. Consulte a su equipo de infraestructura de VMware para ver si este es un problema más extendido .
ewwhite

@ewwhite les avisaré seguro. Sin embargo, es la infraestructura de uno de nuestros clientes y normalmente deberían haberlo identificado. Desafortunadamente, no es así de grande como parecen funcionar los proveedores mundiales de servicios de TI;)
luxifer

@luxifer En serio, creo que esto puede suceder en todo tipo de organizaciones , y las personas encargadas de administrar la infraestructura de vSphere no parecen darse cuenta.
ewwhite
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.